[BrianTee]

En ce qui concerne le contrôle, Matt Reimer a utilisé un contrôleur de moteur PWM 12V standard pour piloter les deux solénoïdes de son tracteur autonome. PWM sur un solénoïde pour diriger dans une direction, et l'autre pour diriger dans l'autre direction, je suppose.

Je ne me souviens pas du bloc de vannes utilisé par Matt.

Mais ne faut-il pas aussi contrôler la ligne de détection de charge pour obtenir un débit réel pour commencer ?

 

[CQuick]

Je prévois de faire mes tests sur un ancien tracteur à centre ouvert afin de pouvoir mettre la recherche en attente pendant un certain temps jusqu'à ce que j'aie au moins un système de guidage automatique fonctionnel utilisant des composants moins chers

 

[BrianTee]

Si vous avez une bobine de rechange, il peut être judicieux d'utiliser une vanne proportionnelle standard, 3 positions, les 4 orifices bloqués au centre. Fonctionne également sur les anciens systèmes à centre ouvert, placés en parallèle avec l'Orbitrol. Ceux-ci sont assez peu coûteux (650 £).

Les systèmes CCLS ont besoin d'une vanne pré-compensée avec P connecté à LS dans toutes les positions autres que le centre. C'est une pièce assez rare, je pense, j'ai parlé à mon fournisseur hydraulique local et même eux ne savaient pas par où commencer ! Une solution de fortune possible serait d'utiliser une électrovanne séparée qui se déclenche en tandem avec la vanne proportionnelle et connecte P à LS lorsqu'elle est active.

Je prévois de faire mes tests sur un ancien tracteur à centre ouvert afin de pouvoir mettre la recherche en veilleuse pendant un certain temps jusqu'à ce que j'aie au moins un système de guidage automatique fonctionnel utilisant des composants moins chers

De ce que je comprends, la ligne de détection de charge peut également aller dans les deux sens. Certains détectent une fuite, tandis que d'autres détectent la pression. Les deux finissent par fournir un signal d'alimentation pour augmenter la pression.

 

[torriem]

Je ne sais rien sur la ligne de détection de charge. Matt n'a jamais rien dit à ce sujet dans ses vidéos. D'après ses écrits sur le forum diydrones, il semble qu'il utilise simplement ce contrôleur de moteur PWM avec rétroaction intégrée qu'il tire d'un capteur d'angle de roue. Son schéma ne montre que deux fils contrôlant l'électrovanne de direction : 12 V pour chaque solénoïde. L'électrovanne de direction qu'il utilise est fabriquée par Outback.

 

[BrianTee]

S'il utilise une vanne Outback, alors oui, tout ce qui est compliqué se fait là-dedans.

Tableau de geek ! Rien de tel que de voir une image de ce qui se passe avec les paramètres.....

 

[CQuick]

Tests initiaux ! Impossible d'obtenir quoi que ce soit d'utile de AOG, j'ai donc envoyé des données 'fictives' depuis l'arduino. Le tout est complètement non réglé, comme vous pouvez le voir, mais le concept fonctionne ! Notez que dans la vidéo, j'ai dit '30 degrés' alors que je voulais dire 30 % ; où 0 % est à gauche et 100 % est à droite.

Prochaines étapes :

GUI - Ajouter des curseurs pour le réglage des paramètres, par exemple le plancher PWM (valeur PWM minimale pour l'activation de la vanne)
Paramètres de réglage tels que les poids d'entrée et de sortie (et peut-être ajuster les fonctions d'appartenance, les règles, etc. du système flou)
Supprimer l'arduino - pour un système plus rationalisé. Seulement là parce que je n'ai pas eu le temps de coder tout ça en Python
Capteur de mouvement de direction - Désengagement automatique lors de la détection du mouvement du volant. Pourrait éventuellement le faire dans le code où il détecte quand il 'combat' l'opérateur, bien qu'il faudra une programmation minutieuse pour éviter le désengagement lors d'un choc, etc.

Dans l'ensemble, je considère cela comme un premier test réussi !

 

[BrianTee]

J'ai téléchargé la dernière version d'AgOpen avec le code Arduino sous contrôle. Cela devrait fonctionner. Vous devez être à moins de 3 ou 4 mètres de ABLine et avoir un cap raisonnable.

J'espère que cela fonctionnera pour vous.

Le code Arduino est très différent dans celui-ci. Il utilise des caps calculés en fonction de la distance par rapport à la ligne, par opposition à une distance seule et PID. C'est une étrange version de PID à anticipation, l'erreur de cap étant le contrôle. De cette façon, l'erreur devrait être considérablement réduite en suivant un cap changeant plutôt qu'en essayant de viser une ligne. J'aimerais avoir plus de temps pour jouer avec ça.

Votre test est excellent.

 

[CQuick]

Désolé Brian, je n'ai pas réussi à faire fonctionner ça non plus, ça n'affiche même pas les données de l'arduino dans la fenêtre de configuration. Mais ne vous inquiétez pas, je vais le laisser de côté pendant quelques mois, jusqu'après les examens/les récoltes, et juste affiner ce que j'ai, peut-être faire fabriquer quelques cartes. J'espère pouvoir reprendre les tests en automne et en hiver. Merci pour tout le travail et les efforts que vous avez fournis !

Mon code est sur Github si quelqu'un veut y jeter un coup d'œil (essayez de ne pas trop rire !)
https://github.com/charlesquick/FuzzySteer

 

[torriem]

EDIT : Voici un lien qui décrit l'idée générale et la compare un peu à PID : https://en.wikipedia.org/wiki/Fuzzy_control_system Donc, si je comprends bien votre code, la sortie PWM pour la vanne de direction provient actuellement du Pi, de Python, et l'angle de direction provient de l'arduino, correct ? L'arduino transmet les informations de la tablette, combinées à la lecture du capteur d'angle de direction, au Pi via la seconde liaison série, qui effectue ensuite les calculs de contrôle flou pour déterminer l'angle de direction souhaité, puis sort la PWM vers la carte de commande du moteur. Donc, si vous aviez un moyen de faire une entrée analogique sur le Pi, vous pourriez éliminer complètement l'arduino. Ai-je bien compris ? Le code Python du Pi est-il suffisamment en temps réel pour fonctionner de manière fiable ?

 

[CQuick]

Torriem,
Oui, vous avez tout à fait raison. Je n'ai utilisé l'Arduino que parce que j'étais à court de temps et qu'il était plus facile d'utiliser le code série existant de Brian et d'utiliser l'ADC de l'Arduino. Le Pi devrait certainement être assez rapide pour gérer les calculs en temps réel, ce qui est facilité par le fait que le code R s'exécute dans un thread séparé. Le système met quelques secondes à se charger initialement, mais après cela, il semble assez rapide. Si vous le souhaitez, je peux effectuer quelques tests pour déterminer exactement la vitesse.

Modifier :

Vous vous demandez peut-être comment déchiffrer le fichier .fis :

Les entrées distance, delta et vitesse sont classées dans les fonctions d'appartenance pertinentes, comme défini dans les 3 sections [input]. Par exemple, distance = -323, delta = 52, vitesse = 6 seront triées comme suit :

la distance ne relève que de la fonction d'appartenance 'neg_low', à un degré d'environ 0,3
le delta est 'pos_zero' à un degré de 0,5 et 'pos_low' à un très petit degré
la vitesse est de 0,6 'low' et 0,4 'med'

La section [rules] se présente comme suit : SI (antécédent 1) ET (antécédent 2) ET (antécédent 3) ALORS (conséquent 1). Zéro signifie non défini (donc la vitesse n'est pas évaluée dans la plupart des règles)

c'est-à-dire 1 1 0, 9 (1) : 1 équivaut à distance, delta, vitesse, sortie, poids (toujours 1), type d'évaluation (1 = ET, 2 = OU). Cela se traduit donc par SI (la distance est neg_hi) ET (le delta est neg_hi) ALORS (la sortie est pos_hi).

Évaluez toutes ces règles aux degrés d'appartenance que nous avons calculés précédemment, puis prenez le centre de la sortie et votre valeur de direction apparaît.

J'espère que cela vous aidera à comprendre ce que j'ai fait Si vous recherchez Fuzzy Logic sur YouTube, il existe également quelques bonnes vidéos sur le sujet.

 

[BrianTee]

Je crois que le pi lui-même ferait l'affaire. Surtout si vous y exécutiez freeRTOS. Un environnement bien meilleur, plus rapide et plus polyvalent que l'Arduino.

Je dirais que si le pi n'est pas capable de faire ça, ce n'est pas de sa faute, mais de la technique utilisée. Absolument, sortez l'arduino.

Je vois un MCP3008 dans votre très proche avenir

 

[CQuick]

J'utilise définitivement le MCP3008, j'en ai déjà commandé quelques-uns
Je vais continuer à utiliser Unix sur le Pi, car il est également utilisé comme récepteur de correction NTRIP, et je n'aime vraiment pas l'idée de le porter sur RTOS. Le Pi 3 a 4 cœurs, donc en supposant que mon application utilisera bien le multithreading à l'avenir, il n'y aura pas beaucoup de différence entre l'utilisation de Raspbian lite ou RTOS ?

 

[BrianTee]

J'utilise définitivement le MCP3008, j'en ai déjà commandé Je vais continuer à utiliser Unix sur le Pi, car il est également utilisé comme récepteur de correction NTRIP, et je n'aime vraiment pas l'idée de le porter sur RTOS. Le Pi 3 a 4 cœurs, donc en supposant que mon application utilisera bien le multithreading à l'avenir, il n'y aura pas beaucoup de différence entre l'utilisation de Raspbian lite ou RTOS ?

Compte tenu de la lenteur de l'autoguidage, cela ne posera aucun problème. Et comme il s'agit d'une application si spéciale, vous pouvez désactiver de nombreuses choses que Raspbian fait en arrière-plan.

 

[torriem]

Vite, vous pourriez essayer d'exécuter AOG sur le pi lui-même via une couche d'émulation système qemu et wine. Je serais vraiment curieux de voir à quel point cela fonctionne bien. https://github.com/AlbrechtL/RPi-QEMU-x86-wine. Vous n'avez pas besoin d'implémenter une machine virtuelle x86 complète. qmemu peut simplement émuler le processeur et transmettre les appels système au noyau Pi réel. J'avais l'habitude d'utiliser ça tout le temps sur mon ordinateur portable PowerPC pour exécuter des binaires x86 linux.

 

[BrianTee]

Il y a beaucoup de choses qui peuvent être désactivées dans AOG. Minimisez les graphiques et de nombreuses "options de confort" d'affichage.

 

[CQuick]

Je vais essayer !

 

[torriem]

Il existe une société propriétaire qui fabrique une couche d'émulation similaire à Qemu qui prétend exécuter Wine à partir d'un arbre Debian x86, avec un pass-through OpenGL complet. https://eltechs.com/run-wine-on-raspberry-pi/. Produit commercial ici.

 

[Henrique12]

Bonjour, après avoir fait fonctionner mon AOG, je suis maintenant avec l'autoguidage.

Je l'ai testé à la maison et ça marche. Ensuite, je suis allé au tracteur.
La première fois que je l'ai utilisé, ce n'était pas la dernière version, j'ai vu qu'il y avait des changements dans l'autoguidage dans la nouvelle version.

Après un certain temps à ajuster les PID et la vitesse du moteur au niveau du contrôleur, je suis parvenu à le faire "fonctionner". À des vitesses assez faibles (~4-5 km/h), ça allait la plupart du temps. Parfois, c'était plus instable, je pense à cause du GPS. J'utilise un ublox M8N, le même que j'utilise dans mon "drone", ça marche très bien là-bas, mais je pense que ce n'est pas du tout suffisant pour cette application.
À des vitesses plus élevées, il commence à osciller et diverge complètement.

Voici ma première question, y a-t-il une mise à l'échelle de la sortie avec la vitesse ? Réduction de la sortie à des vitesses plus élevées.

Un autre problème que j'ai est d'ajuster les PID, je comprends assez bien le P, le I et le D, du moins leurs fonctions mathématiques. Mais j'avais du mal à l'appliquer dans la vraie vie. Je pense que le fait que le GPS ne soit pas bon rendait les choses encore plus difficiles.

Test n° 2 !
J'ai accès pendant quelques jours à un EMLID REACH RTK, je n'ai pas eu l'occasion de le tester dans le tracteur. Mais je l'ai en quelque sorte testé dans la voiture et ça semble fonctionner beaucoup mieux maintenant. J'ai utilisé la nouvelle version d'AOG cette fois.
Je pense que ce week-end, je pourrai tester le RTK dans le tracteur, donc je recherche vraiment des conseils pour régler les PID.

Une autre question que j'ai, je ne suis pas sûr que cela appartienne ici ou au fil de discussion AOG : Il y a une vidéo avec une IMU, est-ce que ça fonctionne déjà ? Là où j'habite, cela fera une différence de pouvoir l'utiliser. Mais pour le moment, ce n'est pas très important.

 

[torriem]

L'ublox M8N fait-il la correction WAAS dès la sortie de la boîte ? Sans au moins WAAS, je ne pense pas que ce serait assez précis pour la direction. Le RTK est définitivement la solution.

 

[8582]

Ne perdez pas de temps avec le m8n, pas assez précis pour cette application. J'ai essayé de rendre mon tracteur tondeuse autonome avec le pixhawk et il avait trop de déviation, ce qui rendait le réglage PID pratiquement impossible. Sans oublier qu'il a roulé sur l'un des arbustes de la femme.