22 réponses à ce sujet

[Bobox]

Voilà mon premier 'robot', Aroll :

 

 

Rien de bien compliqué, c'est principalement un robot d'apprentissage.

 

Coté matériel, pas de soudure et que du démontable :

• Une base actobotics.
• 2 moteur 12V sous-alimenté avec encodeurs
• Une batterie USB 5V
• Un pont en H, LD293 pour le control des moteur.
• Un BeagleBoneBlack pour le sofware.

 

Coté software :

• Ubuntu 16-04 avec les overlay necessaire au PWM et au controle GPIO
• ROS : Robot operating system
• 2x node ROS de lecture des encodeurs et conversion en vitesse
• 2x node ROS de controle des moteur, avec PID
• 1 node ROS de conversion de commande de déplacement en vitesse moteur gauche et droite.

Le controle se fait a travers le wifi par un node ROS de teleoperation, pour l'instant au clavier

 

Ce robot joue son rôle éducatif pour moi, en particulier pour les environnement de développement de beaglebone et ROS.

 

Prochaines étapes :

1. Evaluation de sa position, et controleur pour atteindre une position proposée par l'utilisateur
2. Ajout de détécteur de distance infrarouge, et detection d'obstacle.
3. Controlleur pour contourner les obstacles.
4. Utilisation des librairies de reconstruction d'environment (SLAM)

Et après cela, ce sera une photos finale et le démontage pour attaquer un deuxième type de robot.

 

[Path]

Salut Bobox,

ROS !! Bien joué. !! T'en penses quoi au final. Tu gardes pour la suite ?

[Bobox]

Ah oui, y a pas photos, si tu as la puissance necessaire pour le faire tourner ( en gros si tu peux faire tourner une ubuntu), alors pour moi c'est devenu incontournable.

 

Çà te résoud beaucoup de problème spécifique à la robotique sans rien avoir a faire, en particulier tous les problèmes de software qui tourne en parallèle, de communication entre  modules, de debug.

Ensuite il y a tellement de package existant que dès que tu as fait les nodes pour tes moteurs et sensors tu as directement acces a plein d'algo devenu 'standard'.

 

Après je suis peut-etre un peu biasé puisque c'est plus ou moins à cause de ROS que je me suis remis à la robotique.

[macerobotics]

Salut Bobox,

 

Je suis intéressé par ROS, est-ce que tu as des tutoriels à recommander ?

[Bobox]

Pour apprendre ROS j'ai principalement suivi le livre d'O'Reilly :
Programming Robots with ROS : http://shop.oreilly.com/product/0636920024736.do

 

Le site de ROS  est vraiment bien fait, il contient :

• Des tutoriels : http://wiki.ros.org/fr/ROS/Tutorials
• Un wiki ou chaque package est documente : http://wiki.ros.org/
• Un site de questions reponse tres actifs : RosAnswers : http://answers.ros.org/questions/

Pour ma part j'ai trouve qu'un livre m’était nécessaire pour pouvoir appréhender l'ensemble des concepts de base, avant de me lancer et d'utiliser toutes les ressources web a disposition.

 

[macerobotics]

Salut,

 

Merci pour les infos.

[R1D1]

Joli boulot !

Une question : les noeuds que tu as codé, ce sont les noeuds de contrôle bas-niveau. Du coup, tu as la Beaglebone qui commande directement ton pont en H ? Pas d'étage supplémentaire avec un microprocesseur ?

[Bobox]

Oui ce sont les nœuds de contrôle bas niveau, a part le nœud de conversion de commande du robot en vitesse gauche/droite.

 

Le beaglebone drive directement le pont en H, et analyse directement les fils des encodeurs du moteur.

 

Mais cela n'est pour l'instant pas fait de manière optimal, parce que le pont en H est censé être drive cote electronique avec du 5V et les sorties du beagleBone sont en 3.3v, il me manque quelques transistors.

Du cout j'ai pour l'instant une puissance moteur très très faible . Mais ca me suffit pour debugger le software.

Pour la suite je pense qu’utiliser une carte de contrôle de moteur est plus optimal, mais la je voulais tout faire pour rencontrer les problèmes et mieux comprendre le fonctionnement sous-jacent du contrôle de moteurs.

 

Pour les encodeurs sur le beaglebone il y a nativement une puce de comptage pour les encodeurs en quadrature, mais je ne l'ai pas utilise dans ce montage parce que ma ubuntu 16.04 utilise un noyau linux 4.4, et le driver pour cette puce QEP n'est pas fonctionnel avec ce noyau, donc je le fais avec des event sur les GPIO de manière classique.

[Bobox]

Petit update de mon cher Aroll.

 

Il a reçu l'ajout d'une petite carte de contrôle moteur, en lieu et place du LM293 connecte à la main. Et ça va tout de suite mieux.

Je me suis aussi fait quelque connecteurs USB-> fils pour mes batteries de téléphone, et je peux maintenant les mettre en série pour obtenir du 10v. Les moteurs semblent apprécier

 

Coté software, j'ai un peu retravailler ma libraire python pour gérer le PWM du beaglebone, et j'ai rajouté un noeud ROS pour l'estimation de position.

 

Petite démonstration de l’intérêt de ROS, avec directement sur le laptop un outil de visualisation de l'orientation publié par mon estimateur.

Et on voit très bien que ca marche pas du tout :

 

 

A priori j'ai des soucis avec la lecture des encodeurs, ce que j'ai confirmé avec des lectures faites avec les moteurs an 10v, et il me manque des ticks.

 

[Mike118]

Ton problème est en lien avec cette discussion ici

Si tu n'as pas envie de rentrer trop dans le bas niveau le composant cité en SPI sera très bien pour toi

Si tu décides de résoudre le problème en ajoutant un micro-contrôleur tu as des éléments de réponses ici .

 

Après en regardant ton estimateur , si tu étais pas certain qu'il te manquait des tick je t'aurais conseillé de vérifier les paramètres " diamètre de roue " et " entraxe entre les roue " que tu as du donner à ton estimateur.

[Bobox]

Oui je rate des events, qui du coup peuvent me faire compter en arriere par erreur, ca n'aide pas.

 

Je n'ai pas l'intention d'utilisé un microcontrolleur externe, parce que le microprocesseur du beaglebone contient un module dédié aux encodeurs en quadrature.

Une fois configuré tu n'as plus qu'à lire un node du filesystem pour savoir le compte actuel.

Mais je ne l'ai pas encore activé parce que le driver de ce module là n'est pas au point avec le noyau Linux que j'utilise (4.4). Je vais être obligé d'y remettre les mains si je veux avancé de ce coté.
Mais sinon j'ai de quoi faire dans d'autre directions, comme l'ajout des détecteurs de distance.

[Bobox]

J'ai donc modifé le node ROS de gestion des encodeurs :

• Je l'ai passé en C, les appels des callbacks sur event étant beaucoup plus rapide.
• Je regarde que les front montant sur une pin et regarde la valeur de l'autre pour la direction, comme proposé dans le fil pointé par mike118
• J'ai implémenté un vote majoritaire sur 7 fronts, pour lisser les erreurs de lectures.

Avec toute ces modifications ça se passe beaucoup mieux, l'estimation de position est bien meilleur :

 

 

Prochaines étapes :

• Ajout de capteur de distance pour détecter et éviter les obstacles
• Connection d'un contrôleur PS2 pour donner les ordres
• Ajout d'une caméra pour reconnaitre des endroits particulier, marque des genre de QCODE

[Gyro49]

Bonjour,

 

Pour l'ajout de la caméra avec reconnaissance QRCODE, c'est le moment exacte

https://boutique.ed-...agazine-13.html

mais aussi

https://boutique.ed-...gazine-195.html

 

Bonne vacances à toutes et à tous

[maximusk]

C'est sympa de voir des gens utiliser la beaglebone, ça change d'arduino et raspberry. C'est dommage que ce soit aussi compliqué d'en faire quelque chose...

[Bobox]

Je pense qu'il y a plusieurs raisons qui font que cela parait, et est un peu plus compliqué :

 

C'est le mélange d'un arduino, et d'un raspberry. Ca a autant de GPIO/PWM/ADC qu'un arduino et c'est plus puissant qu'un raspberry, avec plus d'UART de SPI et d'I2c.

Du coup le mélange des deux est plus compliqué que chacun séparé.
Si tu te sers du beaglebone comme un raspberry pi, qui ne fait donc pas de pwm/adc, juste i2x/spi/uart/usb/gpio pour communiqué, c'est pas beaucoup plus compliqué que le raspberry.
Si tu te sers du beaglebone comme un arduino, c'est effectivement beaucoup plus compliqué puisque ce n'est pas un micro-controleur, mais un vrai processeur avec un os complet.

​Le beaglebone est aussi moins grand public que le raspberry, c'est plus orienté "professionnel". C'est plus confidentiel, il y a une communauté moins grande. Il y a pas mal de moyen de trouver de l'aide pour le  beaglebone mais il n'y a pas toute la quantité de libraririe/logiciel et d'exemple d'utilisation qui existe pour le raspberry.

Par contre il contient des features plus "pointues", comme le module pour encodeur en quadrature, et surtout les deux unité de travail tant réelle (PRU), Elles sont en parallèle du processeur principale et peuvent avoir un accès priviligiés aux IO (acces en 5ns = 200MHz), tout en communiquant avec l'OS principale. Par contre il faut quasiment faire de l'assembleur pour les utiliser

 

Le beaglebone est plus orienté "embarqué" , là où le raspberry est "PC miniature". Bien sûr la frontière est floue.

Il est aussi un peu plus cher et moins bien distribué

 

En tout cas je m'amuse bien avec.

Et si des gens se posent des questions où veulent de l'aide avec le beaglebone, je suis tout ouvert à apporter mon expérience.

[maximusk]

C'est sur qu'au niveau matériel, la beaglebone tabasse, mais niveau soft, ils n'ont développé aucune lib pour utiliser le matos dispo sur la carte, et à chaque MàJ du noyau, toutes les explications qu'on peut trouver sur le net deviennent obsolètes.

Pour l'instant je galère rien qu'a utiliser les PWM avec, toutes les explications que j'ai trouvé ne correspondant pas au noyau installé sur la mienne et étant dans l'incapacité de compiler le noyau.

[Bobox]

C'est justement là ou la communauté manque.

Le support du beaglebone s'occupe dejà de donner toutes les features accessible sous linux avec les noyaux successif. Mais les librairies pour un usage 'facile' que ce soit en C ou en Python ne suivent pas effectivement.

 

Je me fais effectivement mes propres librairies au fur et à mesure, je me recompile les overlays, mais j'ai pas besoin de recompiler le noyau.

Tu as installé quel image dessus ?  Et c'est avec quel version du noyau que tu as des soucis ?

[maximusk]

J'ai une debian (celle du site beagleboard avec LXDE), avec le noyau 4.4 TI. Toutes les commandes que j'ai trouvé pour activer les PWM, EQEP, et autres périphériques ne fonctionnent pas car tous les chemins sont différents, et à vrai dire, je suis loin d'avoir compris le fonctionnement du device tree et des overlays.

[Bobox]

Effectivement avec le noyau 4.+ le mecanisme d'overlay de Linux a été réorganisé un peu, ce qui fait que beaucoup de librarys ne marche pas car elles utilisent les anciens chemins. Et pour le QEP, en 4.4 le driver linux ne marche pas encore (il ne marche qu'en 4.1 ou avant), donc pour l'instant c'est mort en 4.4.

 

Si tu en as la possibilité le plus simple est peut-etre de reprendre une image avec un kernel 3.8, qui est celui que supporte toutes les librairies.

Je crois que c'est un 3.8 qui est installé avec la debian wheezy par défaut.

 

Sinon je peux te proposer le code que j'utilise, ce n'est pas encore une librairy universelle, mais ca fonctionne pour les pins PWM1A et PWM1B avec le noyau 4.4

Par contre il suppose que tu as installé les overlays de bb.org-overlays fournit par RobertCNelson ( le gars de chez TI offciellement en charge du support externe du BBB):

https://github.com/b...bb.org-overlays

J'ai suivi le contenu du readme et ca se passe bien.

 

Pour mon code, pour l'instant je n'ai pas mis dans un répository différent ma librairie Python et mon code ROS pour le Aroll, je le ferai si tu commences a t'en servir :

https://github.com/Bobox214/Aroll

 

Dans le repertoire beaglebone tu fais :

python setup.py install

Et tu as le mini-test dans le sous-repertoire tests.

Ce n'est pas encore super documénté, ni très propre sur les messages d'erreur, mais pareil, si tu te mets a l'utiliser je suis prêt a faire les efforts pour la rendre plus facile d'utilisation.

 

 

[maximusk]

OK, je vais tester avec Wheezy.