mercredi 26 décembre 2012

Avancement fin décembre

Bonnes fêtes de fin d'année à tous !

J'espere que le Père Noël vous a tous gâté et que vous n'avez pas déjà vidé vos boîtes de chocolat !
Du côté d'Oleg, il n'a rien reçu d'autre qu'une guirlande électrique qu'il devrait porter en mai prochain.

En terme d'avancement, je profite d'une petite semaine de vacances pour avancer sur le robot principal :

Réglages & Corrections sur l'odométrie :
(Rappel : L'odométrie c'est ce qui permet au robot , à partir des roues folles, de se localiser sur le terrain)
L'an dernier le robot était très répétable d'un match à l'autre mais il fallait plusieurs 'tests' avant d'être sûr des trajectoires demandées au robot. Le problème provient du fait que l'entraxe des roues motrices n'est pas l'entraxe des roues folles et n'est pas au centre du robot non plus. Même si le robot est très bien réglé en terme de détermination du cap et de la distance parcourue, dès qu'il réalise un enchainement de courbes, de lignes droites et/ou de rotation sur lui-même, il y a un décalage entre les coordonnées supposées et les coordonnées réelles du robot.
C'était toujours le même décalage, il me suffisait donc de rentrer les valeurs de ces décalages dans le calcul de l'odométrie pour qu'il n'y en ait plus. Ainsi je n'aurais plus besoin de tester quarante fois chaque programme ! Mais pourquoi ne l'ai-je pas fais l'an dernier ?!

- Programmation de l'asservissement en PID :
(Rappel : Le PID ; Proportionnel Intégral Dérivé ; est un calcul qui permet d'atteindre le résultat demandé suite à une demande)
 
L'an dernier j'avais programmé le mode Avance tel qu'il est présenté ci-dessus. C'est à dire que j'utilisais le bloc "Avancer" du logiciel NXT, le robot tournait donc plus ou moins suivant que 'AlphaRC' (Ecart entre cap du robot et cap de la cible ) était plus ou moins élevé. C'était donc très facile à utiliser.
P : Malheureusement l'utilisation que j'en faisais ne représentait que le P (Proportionnel) de PID. Je déterminais le coefficient de sorte que le cap du robot arrive rapidement au plus près du cap de la cible, mais sans que cela ne fasse faire de zig zag au robot.
I : J'avais donc toujours un écart en régime établi (ligne droite). Cet écart est corrigé par le I (Intégral) qui rajoute un coefficient en fonction de l'écart AlphaRC qu'il y avait au précédent calcul.
D : Et enfin il y a le terme Dérivé qui nous permettra d'augmenter le coefficient P (vitesse d'atteinte de la consigne). Cela se traduira par un dépassement du cap cible et c'est le coefficient Dérivé qui attenuera ce dépassement.

Je profite de reprogrammer l'asservissement pour me séparer du bloc "Avancer" car celui-ci n'utilise pas à 100% la vitesse des moteurs. Je présenterais ce programme lorsqu'il sera testé et validé.
D'ici là, si vous avez des questions sur l'asservissement PID, voici deux pages très complètes :
- RCVA
- Telecom Robotic

- Montage du système d'empilage de verres :

Comme le dit si bien ma fille : "ça marche pas !". He bien non cela ne fonctionne pas, enfin, pas comme je le souhaite. Le système à un seul actionneur empile trois verres sans aucun soucis. Malheureusement dès qu'il faut en soulever trois pour les déposer sur un quatrième, le système glisse et les verres redescendent. A quatre verres soulevés et au delà c'est encore pire.
Il me fallait donc faire un choix :
- me contenter de piles de trois (objectif initial) et rester avec un seul actionneur
- faire évoluer le système avec plusieurs actionneurs pour empiler quatre verres ou plus

... Revenons à l'origine du projet :
Objectifs d'OLEG : Simplicité & Efficacité :
Faire qu'Oleg soit un robot efficace par rapport à son coût, au nombre de membres dans l'équipe, et bien entendu par rapport au nombre de points marqués ! Le but principal est de montrer qu'on peut faire quelque chose d'efficace avec peu si on s'y prend correctement !
J'ai deux briques Lego, soit je fais un robot avec 1+3=4 actionneurs, soit je fais deux robots avec 1 seul actionneur dans chacun de ces deux robots. Les deux cas ont les avantages et inconvenients en terme de simplicité.

En terme d'efficacité, si je fais deux robots, le premier empilerait les verres (deux colonnes de 3 donc : 48 points) et le second activerait les 4 bougies blanches (36pts) = 84 pts. L'intérêt serait d'avoir plus de chances de ne pas rencontrer l'adversaire. Par contre ensuite il ne se passe plus grand chose.
Si je fais un seul robot, il me faudrait activer les 4 bougies blanches en plus d'empiler les verres. Empiler 4 verres (au lieu de 3) + une tour de 2 ne donne que 4 points de plus (52 points). Par contre empiler 5 verres (60 points) permettrait d'atteindre (avec les 4 bougies) 96 points. Le robot est capable de plus de choses mais combien de temps aura-t-il pour réaliser toutes les actions ?

En bref, j'ai beaucoup réfléchi et je vais utiliser mes deux briques dans un seul robot ! Le défi est désormais d'empiler 5 verres sur le buffet puis d'activer les 4 bougies blanches en moins de 90 secondes. Quand c'est trop simple et/ou trop court on s'ennuie...

Le nouveau système d'empilage n'est pas encore terminé, je vous posterais une vidéo j'espere très rapidement.

mercredi 12 décembre 2012

La compétition sera rude ...

Oh oui elle sera rude !

Je ne sais pas si c'est parce que nous fêterons le 20ème anniversaire de la coupe de France de Robotique ou bien si c'est toujours ainsi mais je trouve qu'il y a beaucoup d'équipes qui exposent leurs avancées. Et certaines équipes ont un robot qui est très avancé !

Voici les vidéos qui ont retenu mon attention :

- Cubot : Des anciens d'Ingénieurs2000 (comme moi !)


- Robotic System : Tout n'est pas prêt mais c'est propre et le robot a du potentiel !


- S.M.A.R.T. : Parce qu'il commence à être habitué du top 16 et parce qu'il fait tout cela tout seul (à confirmer) !


- Igrebot : Parce qu'ils ont fait pas mal de tests et parce qu'ils ont une Ultimaker (imprimante 3D) ! Esperons qu'ils l'exploiteront à fond pour faire un superbe engin !
http://www.youtube.com/user/igrebot


Hummmmmm !! S'ils sont bien tous au rendez vous, ça sera génial !!

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é !

dimanche 2 décembre 2012

Avancement début décembre

Avancement début Décembre :

Les roues folles sont installées !

Intégration des roues folles sur codeur de rotation entre les roues motrices

Vue de dos

Vue de face

Il me reste à régler les coefficients et tester la précision du déplacement pour valider tout cela.

Ensuite il va me falloir m'attaquer à l'actionneur principal, chargé d'empiler les verres. Cela sera plus compliqué !