245 réponses à ce sujet

[Serveurperso]

La station de charge c'était plus urgent que tout. Maintenant fini le branchement manuel du robot tout les soirs. et j'ai poussé la mise en veille à 4 minutes c'est plus confortable que les 50 secondes d'avant.

 

En parallèle avec le tangent bug qui est pas mal commencé, j'ai envie de créer une carte PIC32MX voir MZ dédié localisation monte carlos.
Avec en entrée une bascule pour passer du mode exploration (génération de la carte) au mode localisation monte carlos sur cette même carte.

 

En mode exploration (learning) ça génière une grille d'occupation dans la mémoire du PIC32 à l'aide du positionnement odométrique aproximatif mais très correct sur un aller retour d'appart (on le vois bien sur la petite carte du site qu'il est possible de faire générer très précise des chiottes à la chambre en s'y prenant bien)

 

En mode localisation monte carlos on récupère les coordonées absolue de cette petite carte.

Du coup on a du positionnement absolu, avec une petite erreur répétable (la carte odométrique initiale)

Du coup il peux revenir en charge

Du coup ça devient encore plus intéressant d'avoir le path planning tangent bug:)

 

ça fait comme du SLAM mais sans mathématique ultra gourmandes en CPU (EKF ICP et autres)

ça me permet de rester sur du microcontrôleur en C bas niveau ultra fiable bien pépère qui boot en 0 secondes et conso rien

[Serveurperso]

Hop j'ai ajouté une centrale inertielle MPU9250 sur le PIC32 du robot en SPI ! (bye bye l'I2C tout moisi)

J'utilise donc des intégrations de vitesse angulaire du gyroscope Z de l'IMU en remplacement total de l'axe Theta fourni par l'odometrie.

Échantillonnage à 500Hz et correction du bias du gyro Z lors des mises en veille. ça donne une erreur d'odometrie incroyablement faible grâce a l'assistance du gyro.

 

[arobasseb]

Hop j'ai ajouté une centrale inertielle MPU9250 sur le PIC32 du robot en SPI ! (bye bye l'I2C tout moisi)
 

 

Tu peux expliquer ce que tu reproche à l'I2C ? Je n'ai jamais utilisé le SPI et l'I2C me parait simple.

[Serveurperso]

Pour moi l'I2C c'est terminé sur PIC32

Le seul défaut du SPI c'est le nombre d'I/O nécessaire, pour tout le reste c'est beaucoup mieux dont ce qui m'intéresse : Meilleures implémentations du protocole sur toutes les puces utilisées avec le framework Arduino autre qu'AVR.

Protocole plus maitrisé car plus bas niveau qui consomme moins de CPU

 

D'ailleurs pour communiquer avec le second PIC32 dédié à la localisation monte carlo je pense faire un bus parallèle 8 bits:)

[Serveurperso]

Nouvelles : Mesure du courant (monitoring charge/décharge en live)

Et le gros : j'ai créé un algo ultra léger de localisation en absolu X-Y-Theta grace au données Lidar, le tout embarqué dans l'unique PIC32 du robot !!! Il s'agit d'un "correcteur odométrie à haute robustesse" qui asservie l'odométrie sur des cloison droites et perpendiculaires.


Je vais ouvrir un autre post dédiée à cette technique de localisation Odometrie (+ Gyroscope optionnel) + Lidar.

Impossible de le faire foirer l'algo contrairement a beaucoup d'algo SLAM, la tolérance à l'erreur (ex: patine des roues) X-Y est de 500mm et Theta de 10/20 degrés dans mon cas !

La répétabilité est très très inferieur à 1 degrés pour Theta et inferieur au millimètre pour X et Y !!!
La précision est inferieur à 1 degrés et inferieur au centimètre robot en mouvement.
Et je suis certain que ma méthode fonctionne avec du poor man lidar ou du lidar très bruité 

Les seuls pré-requit sont d'avoir quelques lignes approximativement droites approximativement à 90 degrés les uns des autres et de faire quelques mesure afin de définir des ancres virtuelles, et de démarrer l'algo à un emplacement défini (0, 0, 0) qui ne pourra plus jamais se décaler à l'usage.  
 
Aucun problème de fermeture de boucles donc:) c'est de la localisation parfaite au millimètre !
Démo sur le site, ou la carte fini toujours pas ressembler à celle ci : et très peut de pixels bougent (pas de "drift") :

[R1D1]

Un collègue vient de me montrer ce site : http://letsrobot.tv/robot/90073095

Il y a des dizaines de robots, ça peut vous servir d'inspiration

[Serveurperso]

Ah oui ça a l'air rigolo si ils donnent accès a des robots, ça rame faut que j'essai de chez moi !!!

 

En attendant, en pause repas sur mon smartphone, j'ai colorisé mes ancres correctrices pour qu'elles ressortent sur carte du site

 

 

[Oliver17]

LOL excellent le lien R1D1, je viens d'y faire un tour, sacré bordel ^^

[Serveurperso]

C'est mieux comme ça :

 

 

Rigolo le lien ils donnent une API pour y connecter son robot

 

"Let's Robott is a user telepresence network. Anyone can connect their bought or custom made robot and allow users all over the world to interact with it."

 

 

[Leon]

C'est une chambre d'étudiant, chez toi?

 

Leon.

[Serveurperso]

Si on veux, en plus cher, occupé par un plus vieux et avec un salaire

[Serveurperso]

Je suis a la défense:) une chambre d'étudiant ici c'est pas 37m²

[Leon]

Le quartier de la défense, je connais, j'y ai travaillé quelques années.

Mais j'avoue que je n'ai jamais songé à y habiter, ça n'est pas pour moi.

 

En tout cas, tu as un bel appartement de geek avec cet écran géant et ce robot! 

 

Leon.

[Serveurperso]

Vu que j'aime bien remplir mon thread j'ajoute la dernière modif "tuning à la con" elle est belle la carte dynamique comme ça

 

 

[Serveurperso]

Nouvelle caméra ultra sensible (0.000005 Lux) en infrarouge du coup on vois bien le laser du lidar:)

 

Et la servo pince ! reste à design un bloc adaptateur de fixation à l'imprimante 3D

[ashira]

Super la camera! T'as une référence si c'est pas indiscret ?

[Serveurperso]

Yes c'est http://shop.runcam.com/runcam-night-eagle-astro/

out of stock j'ai pris la dernière:)

[Bobox]

Impressionant les resultat de l'algo de localisation, est-ce que c'est novateur au point d'en faire un papier à publier ?

[Serveurperso]

Je pense que oui car je n'ai pas trouvé d'algo de SLAM ni de quelconque système correcteur d'odométrie par rapport à des mesures de distances embeddable sur un microcontrolleur !

 

c'est juste "une page de code en C" et ça pourrait être le point de départ d'une technique de SLAM plus évoluée (qui se débrouille toute seule pour générer les balises de repérage)

avec cette technique on part du principe qu'on exploite des lignes toutes droites + toutes perpendiculaires les unes des autres, et donc il n'y a même pas besoin de faire de RDP (Ramer Douglas Peucker) et encore moins de ransac (random sample consensus) pour détecter les lignes et générer les balises de repérage afin de faire du SLAM ! La majorité des maisons ont des murs et qui sont perpendiculaires, c'est le pré-requit pour mon algo simple et cartésien:)

 

Je pense qu'en créant une table de sinus pour migrer le code de rotation-translation des points lidar en arithmétique entière il pourrait fonctionner avec un RPLIDAR sur AVR 8 bits 16MHz

tout le reste, c'est déjà de l'arithmétique entière optimisée à bloc:)

 

[R1D1]

Je pense que oui car je n'ai pas trouvé d'algo de SLAM ni de quelconque système correcteur d'odométrie par rapport à des mesures de distances embeddable sur un microcontrolleur !
 
c'est juste "une page de code en C" et ça pourrait être le point de départ d'une technique de SLAM plus évoluée (qui se débrouille toute seule pour générer les balises de repérage)
avec cette technique on part du principe qu'on exploite des lignes toutes droites + toutes perpendiculaires les unes des autres, et donc il n'y a même pas besoin de faire de RDP (Ramer Douglas Peucker) et encore moins de ransac (random sample consensus) pour détecter les lignes et générer les balises de repérage afin de faire du SLAM ! La majorité des maisons ont des murs et qui sont perpendiculaires, c'est le pré-requit pour mon algo simple et cartésien:)
 
Je pense qu'en créant une table de sinus pour migrer le code de rotation-translation des points lidar en arithmétique entière il pourrait fonctionner avec un RPLIDAR sur AVR 8 bits 16MHz
tout le reste, c'est déjà de l'arithmétique entière optimisée à bloc:)

Je ne sais pas s'il existe des implémentations sur microcontrôleur, mais ce que tu décris est exactement ce que fait un algo de SLAM actuel, c'est-à-dire mesurer un déplacement du robot par odométrie, et corriger l'erreur par une observation de l'environnement.
Dans l'observation, plutôt que de chercher n'importe quel profil d'obstacle (donc de comparer l'observation à une carte), ta méthode cherche des "patterns" spécifiques : des profils d'obstacle droits et/ou présentant un angle à 90°. Tu rajoutes donc une information supplémentaire, qui dans ton cas particulier améliore la performance, mais réduit potentiellement les environnements d'application. Si la plupart des maisons ont des murs droits et perpendiculaires les uns aux autres, certaines ont également des formes moins standards (angles non-droits, arrondis) mais également des meubles qui peuvent rendre ton hypothèse invalide.
Notons également que cette hypothèse dépend de la hauteur à laquelle ton Lidar mesure le profil d'obstacle. Par exemple, une table basse peut apparaître comme quatre poteaux ou comme une obstacle plein selon le positionnement du capteur.

Pour finir, prenons l'exemple de ces maisons de lotissement toutes construites sur le même modèle. En concentrant ta localisation sur les parois droites et en négligeant les autres patterns, la probabilité que tu sois dans une maison ou l'autre est uniforme : quand le robot démarre, il ne peut pas savoir s'il est dans l'une ou l'autre maison. Il faut alors soit lui donner sa position initiale, soit ne pas le déplacer entre deux sessions.