samedi 5 janvier 2013

La première pile de verres !


Voilà, c'est fait ! Après plusieurs versions mécanique, après quelques heures de programmation et de réglages, voici la première pile de verres réalisée en mode autonome !
Puisque j'étais à l'ENSIM ELEC, j'en ai profité pour valider l'empilage à partir des coordonnées réelles (sur table donc) et j'ai aussi testé le système de déballage de cadeaux !

Voici la vidéo :

Il y a encore pleins de choses à améliorer mais ça fait super plaisir de voir que ça fonctionne très bien !

Oleg 2013 : Le résumé


Pour ce début d'année, l'organisation Planète Sciences demande à toutes les équipes de présenter leur projet sur une page internet. Toutes ces pages seront ensuite mises à disposition à l'issu de la coupe de Robotique (mai 2013) afin que les équipes puissent avoir plus d'infos sur les équipes qu'ils auraient pu rencontrer.
Vous trouverez donc ci-dessous le résumé d'Oleg :
- L'objectif de l'équipe
- Le concept
- La stratégie 2013
 
 
Oleg, un robot à base Lego qui participe à la coupe de France de robotique !

Les objectifs de l'équipe :

L'objectif principal est de montrer que l'on peut faire des choses efficaces avec peu de budget.
Pour cela, nous devons donc :
- avoir quelque chose qui fonctionne à tous les coups (fiabilité)
- avoir quelque chose qui n'est pas très coûteux
- réaliser des actions payantes (classement final)

Le concept Oleg :

Le concept est très simple : acheter quelque chose du commerce, qui fonctionne, facile à utiliser, à construire et qui ne coûte pas trop cher.

Nous avons donc acheter 2 boîtes Lego Mindstorms pour disposer de tout un système programmable avec quelques moteurs et capteurs. (coût : 2x250 €) Nous programmons avec le logiciel fourni (développé par Texas Instruments). Il a le défaut d'être lent lorsque cela devient compliqué mais il est très visuel et ne requiert aucune compétence !

La boîte Lego Mindstorms et la démonstration de la connectique
Interface du logiciel de programmation

Pour permettre au robot de se localiser correctement sur la table de jeu, nous avons investi dans deux capteurs de rotation Lego que nous utilisons pour les roues codeuses. (coût 2x60 €)

Le tout est assemblé non pas avec des legos mais avec des plaques de polycarbonate transparentes de 8 mm d'épaisseur. Cela permet de voir ce qu'il se passe à l'intérieur du robot, c'est facile à usiner et pas trop cher. Pour donner un ordre d'idée la plaque achetée en 2012 (1m sur 1m20 coût 70€) a permis de faire deux robots en 2012 et un en 2013 !

Les robots Oleg et Olaf de 2012


Il faut rajouter a ces quelques 700€, l'achat de quelques outils(Perceuse, Forêts, Scie, Tarauds, ...) et quelques élèments de visserie pour l'assemblage si on ne les possède pas.


La stratégie 2013 :

Nous avons choisi de ne pas s'occuper des cerises car le cumul des actions (aspirer, trier & lancer) fait que cette action est trop compliquée pour nous.
La funny action n'est pas prioritaire, elle sera faite selon le temps disponible et la place restante dans le robot.
Les deux actions principales sont :
- L'empilage des verres
- L'activation des cadeaux / souffler les bougies (un seul et même actionneur)
Le robot principal pourra réaliser ces trois actions.
Si nous avons le temps et si on nous prête une autre boîte Lego Mindstorms, nous fabriquerons un robot secondaire qui ne s'occupera que des bougies ou des cadeaux.

 
 
Empilage des verres
 
Déballage d'un cadeau
 

mardi 1 janvier 2013

Bonne année 2013 !

Toute l'équipe d'Oleg vous souhaite une très bonne année 2013 !

Ici l'année commence très bien ici avec un gros orteil cassé ! Déplacer une table de 40 kg avec le plus alcoolisé des invités fut une très mauvaise idée ...


Mais j'ai une bonne nouvelle, mes réglages sur l'odométrie sont quasi parfait (pour des lego) ! Pour preuve ci-dessous le parcours réalisé ce soir par le robot. Le robot part du point X:1350 Y:375 (comme s'il partait du côté rouge de la table, côté cadeaux) puis se déplace vers le point 1300;1300 puis 900;1300 et enfin le dernier point 900;300. Ces points ne correspondent à rien d'autre que les dimensions de ma table de cuisine.
Le reste de la courbe, jusqu'aux coordonnées 1450;250 est obtenu en déplaçant le robot manuellement jusqu'à un repère physique que j'ai mis sur la table.


 
 

Le but était donc d'observer la trajectoire vue par le robot et de vérifier, après plusieurs rotations et lignes plus ou moins droites, que les coordonnées vues par le robot étaient proches des coordonnées réelles.
En conclusion, après un trajet toutes directions confondues de 3220 mm, le robot s'est retrouvé décalé de moins de 5 mm en X et en Y ! C'est peut être 10 fois mieux que l'an dernier !

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