vendredi 7 décembre 2012

Premier test de Déplacement sur table

La programmation du déplacement d'Oleg :
 
L'an dernier, j'avais passé beaucoup de temps à expliquer comment :
 
Beaucoup d'équipes, dont le robot est équipé de roues folles, utilisent la même façon de calculer les coordonnées du robot. Par contre la façon de se déplacer du point A au point B d'Oleg est assez particulière. La plupart des robots se déplacent par des lignes droites et des rotations sur eux-mêmes. Oleg se déplace par "point de passage", chaque point étant validé lorsque le robot est à une distance inférieure à la précision d'approche demandée. Il arrive robot de faire des rotations lorsque la diffèrence entre le cap du robot et le cap à prendre est supèrieur à un angle défini (dans mon cas 60°). De cette façon, Oleg va un peu plus vite jusqu'au point B et il arrive toujours jusqu'au point de passage même si quelque chose le bouscule dans sa course.
 
 
 
Le premier test sur Table :
 
J'ai donc repris le principe cette année (quel gain de temps !) et, après quelques essais et règlages sur ma table de salon, Oleg se déplace du point A au point B. Mais une table de 1m de long ce n'est pas le top, le décalage après 1m n'est pas évident à mesurer et donc la correction n'est pas optimale.
 
Le top c'est donc de faire un essai sur table grandeur nature. Quoi de mieux donc que d'aller faire un tour à l'ENSIM ELEC ? Pas de rester sur ma table de salon en tout cas ...
Si dessous vous pouvez retrouver le parcours que le robot 'pense' avoir réaliser (il enregistre dans un fichier txt ses coordonnées et d'autres paramètres). Il me faut le comparer au parcours qu'il a réellement effectué (coordonnées réelles) pour voir si les paramètres sont corrects ou non.
 
Le parcours programmé était le suivant :
- Initialisation contre le buffet puis contre le bord côté rouge et côté cadeaux
- Déplacement jusqu'au point X=-850 Y=400
- Déplacement jusqu'au point X=-600 Y=800
- Déplacement jusqu'au point X=1200 Y=800
 
 
 
Globalement le robot devait contourner les verres pour rapporter les 4 verres du milieu dans la zone rouge. Je tiens à préciser que ce n'est pas la stratégie que j'utiliserais ...
Premier constat : Je n'ai pas bien intégré que le robot n'a pas une rotation instantanée lorsqu'il change de cap, c'est pourquoi l'entraxe des roues (la ligne blanche) ne passe pas par l'axe des verres.
Deuxième constat : Dans sa première ligne droite le robot doit éviter les verres, en réalité il a emporté le dernier verre de la ligne droite. J'ai tout d'abord cru que le calcul du cap n'était pas correct mais ce graphique m'a montré un autre problème, certainement plus important qu'une simple correction. Le problème est visible au début de la ligne blanche, sachant que le robot fait 30cm de large, le point de départ ne devrait pas être aussi proche du buffet ! A mon avis, l'entraxe des roues folles n'est pas au même point que l'entraxe des roues motrices.
Troisième et dernier constat : Malgré ces deux constats, le robot a plusieurs fois rapporté au moins 4 verres (juste en les poussant), toujours de la même manière, avec le même comportement et sans aucuns problèmes particuliers !

 

Complément d'info sur la programmation d'Oleg :
 
Comme l'an dernier, la table est symétrique. L'an dernier, le point d'origine (X=0 et Y=0) était dans un angle de la table, j'avais donc un programme par couleur. L'avantage était que j'ajustais les coordonnées de passage pour chaque couleur pour pallier aux imprécisions du déplacement. Le gros désavantage était que cela prenait beaucoup de place dans la brique programmable, beaucoup beaucoup !
 
Donc cette année, vous pouvez le voir sur le graphique, l'axe vertical Y est au centre de la table sur l'axe de symétrie. Ainsi, les coordonnées de passage, quelque soit la couleur, seront toujours les mêmes, je n'aurais qu'à faire varier Y en le mulipliant par 1 ou -1 suivant la couleur sélectionnée au démarrage. Mais pour cela, il va falloir qu'il n'y ait pas d'écarts entre le comportement du robot, qu'il démarre côté bleu ou côté rouge ! Et ça je ne l'ai pas encore vérifié !

2 commentaires:

  1. Salut !

    C'est beau de pouvoir faire ça avec des légos ! Avant de participer à la coupe il y a 3 ans, je n'aurais jamais pensé voir ça un jour !

    J'aimerais quelques précisions sur ton article. 1 - Tu dis :
    "De cette façon, Oleg va un peu plus vite jusqu'au point B et il arrive toujours jusqu'au point de passage même si quelque chose le bouscule dans sa course."
    C'est dans le cas ou les roues folles ne glissent pas bien sur ? Ou tu as un autre système, type boussole/accéléromètre/gyroscope, pour détecter un glissement ?

    2 - Vas-tu te fier uniquement à l'odométrie cette année ou auras-tu d'autres capteurs pour te repérer sur le terrain ? (A moins que ce soit top secret ;-) )

    Merci d'avance !

    RépondreSupprimer
    Réponses
    1. 1- Oui c'est bien dans le cas où les roues folles ne glissent pas car je n'ai qu'elles. Et compte tenu de mon experience de l'an dernier et des essais de cette année, soit le glissement est négligeable, soit elles glissent tout le temps de la même manière car c'est très répétable.

      2- L'an dernier je voulais tester la cam pour le secondaire et je n'avais rien fais avec ... Donc cette année je n'ai rien de top secret mais je n'ai pas envie de présenter quelque chose qui ne verra pas le jour. Donc cette année je ne me fie qu'à l'odométrie (ça ça marche déjà). Mais peut être (surement) que j'utiliserais un capteur ultra son pour la détection des verres : J'ai peur que mon système cherche à empiler des verres inexistants ! (J'ai la phobie des actions dans le vent ^^)

      Concernant les legos je ne pensais pas non plus réussir à faire tout ça il y a encore un an ;-)

      Supprimer