Une bibliothèque de robotique open source

L'endroit pour parler de logiciel, programmation et algorithme.
Place to discuss on software, programming and algorithms.
Post Reply
astralien3000
Posts: 9
Joined: Thu 21 Jul 2016, 18:04

Une bibliothèque de robotique open source

Post by astralien3000 » Mon 24 Oct 2016, 17:46

Bonjour !

Je viens ici pour vous présenter Aversive++, une bibliothèque C++ open source qui a pour but de faciliter la programmation de robots sur microcontrôleurs.

Les fonctionnalités qui sont présentes :
- Des classes facilitant l'asservissement de robots à 2 roues (les plus nombreux à la coupe)
- Des classes "stream", comme dans la lib standard C++, mais qui fonctionnent sur microcontrôleurs
- Des conteneurs standards (Listes, Piles, Tas, Queues...), sans allocation dynamique
- Un simulateur simple de robots à 2 roues, pour tester vos asserv/déplacements.
- Un système de build vers plusieurs familles de microcontrôleurs (STM32F4, ATMega, principalement)
- On peut utiliser la lib Arduino (sans l'IDE) pour les Arduino UNO et MEGA
- On peut utiliser la lib STM32CubeF4 pour toute la famille des STM32F4

Les fonctionnalités qui sont presque présentes (c'est à dire implémentées, et fonctionnelles, mais non "nettoyées") :
- Une bibliothèque de cinématique inverse, qui est assez légère pour tourner sur un AVR !
Il y a une Démonstration, en réponse à une bibliothèque similaire, mais qui ne peux pas tourner sur un microcontrôleur.
Le principe est de pouvoir exporter des armatures blender, qui modélisent le robot, vers du code C++.

Et il y a d'autres fonctionnalités prévues :
- Du path finding à base d'A*
- De la fusion de données à l'aide de filtre à particules

La bibliothèque peut être compilée pour :
- Linux
- AVR : ATMega328p, ATMegaxx0_1, Arduino UNO/MEGA
- STM32 : STM32F4xx
D'autres plateformes peuvent être ajoutés, selon la demande.

Donc voila, si vous n'avez pas de base de code, que vous voulez coder en C++ et que vous cherchez une bibliothèque qui facilite un peu le travail, pensez à Aversive++ ^^ ! Si en revanche, vous avez déjà une base de code on peut peut être mettre du code en commun ? Personnellement je serai ravi de contribuer à une mise en commun de code pour la coupe ou des robots en général.

D'ailleurs Aversive++ est fait pour ça : Chaque fonctionnalité est découpée en modules les plus indépendants possible, pour pouvoir être utilisés ailleurs, sans avoir à installer tout le projet Aversive++. Vous êtes même libres du choix de la chaine de compilation ! La licence est BSD-3-Clauses pour la plupart des modules, donc c'est quasiment de l'openbar pour réutiliser le code.

Voila, j'espère vous avoir intéressé, merci de m'avoir lu !

Je suis ouvert à toute remarque/question !

User avatar
Kryss
Posts: 103
Joined: Mon 06 Jun 2011, 16:27

Re: Une bibliothèque de robotique open source

Post by Kryss » Fri 28 Oct 2016, 10:54

Ça a l'air intéressant.
Après, je suppose que ça s'adresse à un public débutant, et pour ce public il faudrait énormément de documentation je pense.

Belle volonté que de vouloir construire une base en tout cas.
OMyBot - Tant qu'ça roule, c'est cool !

astralien3000
Posts: 9
Joined: Thu 21 Jul 2016, 18:04

Re: Une bibliothèque de robotique open source

Post by astralien3000 » Sun 30 Oct 2016, 16:51

Merci ! ^^

Ça ne s'adresse pas spécialement qu'à des débutants (Même s'ils font partie du public cible ^^). Il y a d'ailleurs des notions assez avancées de robotique dans le projet. J'essaie en effet que ça soit accessible, mais pas simpliste. Il faut avoir un comportement par défaut simple, mais pouvoir configurer à volonté.

Le but ultime de la bibliothèque sera de fournir des algorithmes assez avancés (recherche de chemin, cinématique inverse, filtres de Kalman/à particules, des algo d'IA, ...), qui tournent normalement (si ce n'est "facilement") sur des Linux embarqués, mais de rendre possible leur exécution sur microcontrôleur. J'ai déjà montré l'exemple de la cinématique inverse, qui peut tourner sur AVR, mais il y a aussi un robot utilisant Aversive++ qui exécutait un algo de recherche de chemin (A*, pour le nommer) sur seulement 1Ko de RAM.

Mais de toute façon, tu a raison, que ce soir pour un public débutant ou non, il faut avoir une documentation solide. Et j'avoue avoir un peu de mal sur ce point :roll: . J'ai une partie de l'API qui est super bien documentée (merci à un de mes coéquipiers, pour le coup), et quelques bouts de docs accompagnés d'exemple dans quelques recoins, mais c'est dur d'avoir une belle grande doc facile d'accès, même pour les débutants.

arno
PMI
Posts: 685
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Une bibliothèque de robotique open source

Post by arno » Sat 05 Nov 2016, 17:00

astralien3000 wrote:Le but ultime de la bibliothèque sera de fournir des algorithmes assez avancés (recherche de chemin, cinématique inverse, filtres de Kalman/à particules, des algo d'IA, ...), qui tournent normalement (si ce n'est "facilement") sur des Linux embarqués, mais de rendre possible leur exécution sur microcontrôleur. J'ai déjà montré l'exemple de la cinématique inverse, qui peut tourner sur AVR, mais il y a aussi un robot utilisant Aversive++ qui exécutait un algo de recherche de chemin (A*, pour le nommer) sur seulement 1Ko de RAM.
Je rebondis sur la partie filtrage de Kalman. Autant il est "facile" de faire une implémentation générique lorsque c'est pour tourner sur PC, il me parait très difficile de le faire pour une cible embarquée type AVR de façon générique, dès que l'on cherche un minimum de performances (filtrage >= 100Hz ou état un peu conséquent).

Je pose la question car le dernier filtre que j'ai codé (EKF) à du être écrit de façon dédiée afin de tenir les 1ms de temps d'execution qui m'étaient alloué. Pourtant le système était relativement simple (3 états, 2 sorties, 0 entrées, modèle de prédiction linéaire, modele de mesures non linéaires).
En particulier dans les équations, j'ai utilisé le fait qu'une inversion de matrice à une solution analytique simple en dimension 2 ou 3, et qu'il n'est pas utile de faire une décomposition LU ou autre pour la résoudre. Dans le même genre, il y a l'utilisation de matrices particulière (diagonales, triangulaires, creuses...) pour éviter de calculer ce qui est déjà connu à zéro et gagner du temps d'execution, sachant que la plupart des systèmes sont écrits sous forme canonique, il y a beaucoup à gagner.

Je dois maintenant m'attaquer à un nouveau problème bien plus important (centrale inertielle complète 6DOF, avec fusion de mesures d'accelero/gyro/magnéto/balises RF), pour lesquels je crains justement de passer plus de temps à tout optimiser à la main pour que ça fonctionne qu'à réussir à poser le problème et le valider en simulation...

Vu que tu sembles y avoir déjà réfléchi, quelle est ta vision sur cette question des performances ?

Merci et bon courage pour le développement.

astralien3000
Posts: 9
Joined: Thu 21 Jul 2016, 18:04

Re: Une bibliothèque de robotique open source

Post by astralien3000 » Tue 08 Nov 2016, 13:39

Salut arno,

Alors je suis pas un expert en filtre de Kalman, car je n'en ai codé qu'un simple en python.

Mais vu mon expérience, et ce que tu m'en dis, je pensait appliquer la même technique que celle que j'ai utilisé pour la cinématique inverse.
La cinématique inverse demande aussi des opérations sur les matrices à très haute fréquence (pour donner une idée, pour un bras à 3 servomoteurs, j'ai besoin de calculer 30 matrices jacobiennes (en moyenne) par "frame d'animation", et si on veut une animation du bras à 20Hz, ça fait déjà 600 calculs de jacobiennes, par secondes pour un seul bras).

Pour optimiser chaque itération, je réalise le maximum de calculs à la compilation. Pour cela, je récupère le modèle du robot (URDF, Blender, autre), fais les calcules et les optimisations possibles avec un programme (codé en python), et génère du code C/C++ prêt à être intégré dans le code du robot. Cela permet d'avoir une algorithme "générique" (la conversion du modèle en code C/C++) tout en permettant de grandes optimisations.

D'ailleurs si tu veux travailler avec moi ou me donner des conseils quand je m’attellerai au filtre de kalman, tu es le bienvenu !

arno
PMI
Posts: 685
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Une bibliothèque de robotique open source

Post by arno » Wed 09 Nov 2016, 23:28

Salut Astralien,

Merci pour le retour !
astralien3000 wrote:Alors je suis pas un expert en filtre de Kalman, car je n'en ai codé qu'un simple en python.
Je suis loin d'être expert non plus. J'ai la théorie depuis un moment (trop longtemps?:D) et de la pratique que depuis peu...
astralien3000 wrote:La cinématique inverse demande aussi des opérations sur les matrices à très haute fréquence (pour donner une idée, pour un bras à 3 servomoteurs, j'ai besoin de calculer 30 matrices jacobiennes (en moyenne) par "frame d'animation", et si on veut une animation du bras à 20Hz, ça fait déjà 600 calculs de jacobiennes, par secondes pour un seul bras).
Dans le cas où tu parles bien de performances obtenus avec un AVR 8 bits à 16MHz (le ATMega2560 de ta vidéo), je suis vraiment surpris que tu puisses monter aussi haut ! Tu as réussi à attiser ma curiosité ;) (au point où je pense refaire mes mesures de temps d'éxecution de mon EKF, car tu m'as mis le doute ! :lol:)
astralien3000 wrote:Pour optimiser chaque itération, je réalise le maximum de calculs à la compilation. Pour cela, je récupère le modèle du robot (URDF, Blender, autre), fais les calcules et les optimisations possibles avec un programme (codé en python), et génère du code C/C++ prêt à être intégré dans le code du robot. Cela permet d'avoir une algorithme "générique" (la conversion du modèle en code C/C++) tout en permettant de grandes optimisations.
J'ai donc cherché dans Aversive++ cette lib (j'étais passé au dessus au premier coup, car GitHub la donne en python et que je cherchais du C++, et que tu as omis la description), et cherché un modèle .blend pour faire un test (je ne maitrise pas du tout l'outil, donc j'ai trouvé ça : https://cloud.blender.org/p/gallery/582 ... 32c63b1bd6).

Avec ce fichier sauvé sous le nom "arm.blend", la commande que j'ai tapée pour générer le code CPP est : "ik/bin/blend2cpp arm.blend Armature_001/forearm/endpoint".

Le fichier généré contient effectivement un tas de calculs déjà optimisés. Faut que je déterre un court de cinématique inverse pour comprendre les maths derrière, mais là tu ne peux rien pour moi !

Par contre, je suis supris que tu ais fait tous les calculs en flottants double précision ? C'est plutôt lourd pour des micro-controlleurs. J'ai plutôt l'habitude de voir les gens essayer de rester sur des simple précision si l'application le permet. En plus, il est assez facile de trouver des processeurs avec support hard de la simple précision (STM32F4 par exemple), alors qu'en double précision c'est très rare (chez STM, seul le STM32F7 l'a sur quelques modèles).
astralien3000 wrote:D'ailleurs si tu veux travailler avec moi ou me donner des conseils quand je m’attellerai au filtre de kalman, tu es le bienvenu !
Depuis les premiers messages, il se peux que j'ai une application qui se présente pour une cinématique inverse (bras sur un robot pour la coupe de France). Y'a encore rien de fait (c'est une idée d'hier...), mais si ça se confirme, je repasserais surement par là pour essayer avec cette bibliothèque.
Pour le reste, c'est difficile d'être partout, et je ne voudrais pas m'éparpiller plus que je ne le suis déjà, mais si j'arrive à une application de filtre de Kalman suffisement générique, je tacherais de le partager.
N'hésites pas à me rappeler à toi si tu attaques ce sujet avant moi, je ne sais pas encore à quel moment je pourrais m'y mettre (faut déjà réussir à récupérer les données brutes avant de commencer à les filtrer :D )

astralien3000
Posts: 9
Joined: Thu 21 Jul 2016, 18:04

Re: Une bibliothèque de robotique open source

Post by astralien3000 » Thu 10 Nov 2016, 03:04

Dans le cas où tu parles bien de performances obtenus avec un AVR 8 bits à 16MHz (le ATMega2560 de ta vidéo), je suis vraiment surpris que tu puisses monter aussi haut ! Tu as réussi à attiser ma curiosité ;) (au point où je pense refaire mes mesures de temps d'éxecution de mon EKF, car tu m'as mis le doute ! :lol:)
Oups, la donnée de 600 itérations par seconde, c'est le besoin pour une patte de mon robot, pas la fréquence atteinte sur un AVR. Tu a bien fait d'avoir un doute.
J'ai réalisé un test :
https://github.com/xenomorphales/buggyb ... t/embed-ik
Que j'ai compilé pour Arduino Mega 2560 (il n'est pas compilable tel-quel, j'ai dû oublié de pusher la dernière version...)

Le résultat est : 5000 itérations en 43 secondes => 115 itérations par secondes.
C'est plus réaliste... Désolé pour le faux espoir !

Mais ça reste quand même raisonnable !
En effet, on peut donc atteindre en moyennes 3-4 positions différentes par secondes (pour mon exemple, d'autres bras peuvent se comporter différemment, en mieux ou en moins bien), ce qui peut être suffisant pour un bras robotique. En diminuant la précision, on peut même atteindre plus de positions par secondes (passer d'une précision de 1mm à 2mm peut pas mal diminuer le nombre d'itérations requises pour atteindre une position).
Par contre pour un robot à pattes, on est pas bon... Il faut du matériel plus puissant (j'ai bon espoir avec de l'ARM Cortex-M4, comme tu l'a souligné)

Il faudrait que je fasse un bench avec différente architecture, différents paramètres, etc... ça serait bien utile.
J'ai donc cherché dans Aversive++ cette lib (j'étais passé au dessus au premier coup, car GitHub la donne en python et que je cherchais du C++
La première version de la lib était en C++ (j'utilisais les templates et la métaprogrammation pour faire les optimisations).
Mais le code était difficile à maintenir, et le python, avec sa bibliothèque sympy, permettais beaucoup plus d'optimisations.
Par contre, je suis supris que tu ais fait tous les calculs en flottants double précision ? C'est plutôt lourd pour des micro-controlleurs. J'ai plutôt l'habitude de voir les gens essayer de rester sur des simple précision si l'application le permet. En plus, il est assez facile de trouver des processeurs avec support hard de la simple précision (STM32F4 par exemple), alors qu'en double précision c'est très rare (chez STM, seul le STM32F7 l'a sur quelques modèles).
Sur AVR, le type double est identique au type float, donc ça ne changeait rien. Mais en effet sur ARM ça va changer la donne, donc il faut que je fasse attention à ça lors de mes tests, merci !
(je ne maitrise pas du tout l'outil, donc j'ai trouvé ça : https://cloud.blender.org/p/gallery/582 ... 32c63b1bd6).

Avec ce fichier sauvé sous le nom "arm.blend", la commande que j'ai tapée pour générer le code CPP est : "ik/bin/blend2cpp arm.blend Armature_001/forearm/endpoint".
J'ai rapidement regardé le fichier, je viens de voir que la sortie C++ propose 3 angles (q0, q1 et q2) pour le bras alors que l'armature actuelle devrait en proposer 6 (vu que les bones de l'armature ne sont pas contraints). Il y a donc un bug dans mon algo...
Je vais revoir tout ça rapidement ! Rien de bien méchant normalement.
Depuis les premiers messages, il se peux que j'ai une application qui se présente pour une cinématique inverse (bras sur un robot pour la coupe de France). Y'a encore rien de fait (c'est une idée d'hier...), mais si ça se confirme, je repasserais surement par là pour essayer avec cette bibliothèque.
N'hésite pas à me demander de l'aide si ça ne fonctionne pas comme prévu. Comme je n'ai pas beaucoup d'utilisateurs, je peux me permettre de faire un peu de support. En plus ça peut me permettre de débugger la lib !

arno
PMI
Posts: 685
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Une bibliothèque de robotique open source

Post by arno » Fri 11 Nov 2016, 01:47

astralien3000 wrote:Le résultat est : 5000 itérations en 43 secondes => 115 itérations par secondes.
C'est plus réaliste... Désolé pour le faux espoir !
Ok. Ca me surprends déjà un peu moins, mais ca reste déjà assez balaise pour un proc 8 bits !
astralien3000 wrote:Sur AVR, le type double est identique au type float, donc ça ne changeait rien. Mais en effet sur ARM ça va changer la donne, donc il faut que je fasse attention à ça lors de mes tests, merci !
N'étant pas habitué aux AVR, je viens de découvrir qu'ils ont codé les double sur 4 octets ! Le standard C est infect sur les définitions de types, et ca reste possible tout en restant dans le standard...
Par contre, si tu veux garder le maximum d'inter-opérabilité avec les autres platformes, il faut effectivement mieux tout passer en "float".
Une autre chose à faire attention, c'est les fonctions mathématiques, donc il existe des variantes. Sur une plateforme avec FPU simple précision, le simple fait d'appeller la fonction "sin" va passer les calculs sur le CPU (car elle fonctionne en double), alors qu'appeller la fonction "sinf" va passer par la FPU comme espéré (car elle fonctionne sur des float). Et en terme de vitesse, c'est le jour et la nuit...
astralien3000 wrote:N'hésite pas à me demander de l'aide si ça ne fonctionne pas comme prévu. Comme je n'ai pas beaucoup d'utilisateurs, je peux me permettre de faire un peu de support. En plus ça peut me permettre de débugger la lib !
Je n'en suis pas encore là, y'a juste eu une idée de "faire un bras" qui a été lancé, suivant ce qu'on met comme actionneurs (et donc le nombre de degrés de libertés), la cinématique inverse peut être directe ou nécessiter des calculs...
En tous cas, je surveille ;)

Post Reply