Participants : Guillaume, Luc, Mathieu, Théophile, Thibaut

24 au 28 mai 2017

Règlement : http://www.coupederobotique.fr/wp-content/uploads/2017/03/C2017_Rules_FR_2.1.pdf

Description des robots

Tous les fichiers (blender, circuits, code du GUI et des robots) sont sur https://git.eleves.ens.fr/hackens/coupe2017

https://youtu.be/8Q8-2TaKp28

Mission : récupérer les cylindres de diamètre 63mm et hauteur 100mm.

Le robot est un cylindre de dimensions maximales pour le règlement de cette année (diamètre ~220mm), construit autour d'un couloir interne accomodant les cylindres. Il comporte une entrée par l'avant du robot, un couloir horizontal où les cylindres sont attrappés par une chenille/pince puis basculés horizontalement. Ils sont ensuite stockés horizontaux dans une pile verticale s'étendant jusqu'au sommet du robot.

Support en MDF, deux plaques de MDF 6mm horizontales quasi-identiques séparées de 10cm, et plaques de MDF 3mm verticales comme support.

Coque faire de panneaux transparents, maintenus ensemble par des petites pièces imprimées en 3D, et glissée sur la structure. Clipsée sur la planche de MDF supérieure ainsi que sur le haut du couloir vertical.

La partie antérieure du couloir inférieur (niveau sol) est entourée par une chenille d'un côté, et une pushbar sur ressorts de l'autre côté.

La partie postérieure du couloir inférieur est entourée par une plaque de MDF 3mm d'un côté, et d'un ascenseur de l'autre côté. L'ascenseur permet de faire monter les cylindres dans la pile verticale. Deux goupilles mobiles sortant de la plaque de MDF opposée permettent ensuite de bloquer les cylindres de la pile.

Tous les actionneurs se situent à l'étage inférieur.

Une servo à l'avant permet d'actionner une demi-pince formée par la dernière roue de la chenille

La transmission du servo à la barre se fait via une bielle en mecano. Ça a très bien fonctionné.

La roue postérieure de la chenille entraîne la chenille. Penser à vérifier que toutes les roues tournent librement, même si elles ne sont pas forcément montées sur roulements. Quelques rondelles permettent de séparer les roues des montants. Les chenilles LEGO sont élastiques : l'espacement entre deux crans n'est pas constant et ça limite la force de traction.

Pour garder le couloir à cylindres libre de tout obstacle, on a dû déporter l'actionneur de la chenille à côté de la roue d'entraînement. Attention aux servos à rotation continue, c'est un peu galère à contrôler (ils ne s'arrêtent pas juste en désactivant leur pin de contrôle) et ça va pas très vite. Pour transmettre le moment du servo à l'axe de la chenille on a utilisé un morceau de courroie d'imprimante 3D. Attention à faire exactement le bon pas sur les roues dentées, à refermer proprement la courroie, et à tenir la roue dentée du servo des deux côtés (sinon la vis de fixation à l'axe du servo force beaucoup)

Les cylindres arrivés au bout du couloir et basculés par une butée supérieure sont ensuite soulevés par une pièce mobile (en bleu) fixée par deux pièces fixes (en jaune), et entraînée par un élastique tendu entre une roue (en jaune) actionnée par un servo, et un roulement à bille fixé sur l'axe rouge visible en bas de l'assemblage.

L'assemblage a fini par fonctionner, après plusieurs ajustements au design (initialement la pièce avait du mal à arriver jusqu'en bas. En rétrospective on aurait peut-être dû placer le servo d'entraînement plus haut (au-dessus de la plaque horizontale de MDF).

Un microrupteur détecte la position haute de l'assemblage.

Une fois soulevés, les cylindres sont maintenus en place par un mécanisme de verrouillage.

En rétrospective, nous aurions pu utiliser directement les bras de servos comme goupille, ça aurait été plus simple (mais peut-être plus difficilement réglable)

La pièce bleue mobile est fixée aux deux vis grises, et poussée par les deux servos. Le tout est fixé aux pièces jaunes. La longueur des vis est réglable grâce à des écrous prisonniers de la pièce bleue. Des ressorts autour des vis maintiennent la normalement non verrouillée.

Problème : les servos consomment en permanence une fois verrouillés. Solution : faire en sorte que les bras des servos se bloquent dans les coins de la pièce une fois verrouillés.

Comme d'habitude, on utilise des steppers et des roues robotshop pour motoriser les robots. À noter que si on perd la petite clé Allen permettant de visser la “set screw” des moyeux hexagonaux des roues, on peut repercer et tarauder le trou de la “set screw”.

Les supports de fixation avaient l'air un peu fragiles, et les roues avaient tendance à pencher un peu parfois, mais ça a tenu jusqu'au bout sans problème et avec peu de jeu.

On a aussi placé deux billes folles sous le robot (non représentées ici). Malheureusement le design permettait très peu de possibilités, aussi on les a placés du côté gauche uniquement, très (trop ?) près du moteur gauche. À noter que les petites billes folles (diamètre de perçage 12mm si je me souviens bien) marchent très bien. On a percé la planche inférieure sur 2mm d'épaisseur avant de les coller en place.

Magnifique pièces imprimées en 3D, qui a bien marché à tous les coups même si on a eu un peu peur de la solidité de l'axe du servo. Propulsion à l'aide d'élastiques. Note : les élastiques ça casse facilement.

Une à l'avant du couloir, une à l'arrière

On a collé un petit microrupteur, ça a marché très bien à tous les coups

Un bout de fil de fer plié en “U” qui entoure une microrupteur et que l'on retire avec une ficelle

On a utilisé un radar avec des pins VCC, GND, TRIG, ECHO, qu'on a branché directement au FPGA. C'est beaucoup plus pratique que l'interface I2C qu'on avait en 2015. Bon après sans FPGA ça se serait compliqué un peu… Mais du coup on pouvait sampler le radar à >50Hz, faire du filtrage, une bascule de Schmitt, etc…

On a utilisé plusieurs systèmes pour contrôler le petit robot

C'est génial parce que ça se connecte au wifi, on peut se ssh dessus, on peut lancer/tester des programmes facilement, debugger, etc…

Il ne faut juste pas oublier de prendre le routeur de la cave, ou de lui apprendre à se connecter au wifi d'un portable, sinon c'est compliqué le jour J. Même si on prend le routeur, c'est pratique qu'il se connecte au wifi d'un portable, pour s'y connecter sur les tables de test.

On a également fixé un petit écran tactile directement sur le rpi, ça a pris un peu de temps pour coder un GUI correct (en SDL) mais c'est bien pratique pour debugger (on l'utilisait pour contrôler/tester les servos et les capteurs essentiellement, et pour choisir la couleur de départ etc…). Quand on sera en finale (lol) ce sera pratique pour choisir la stratégie en fonction des adversaires. À noter également que le présentateur de la webtv a débuggé notre robot en direct en lisant le log qui s'affichait sur l'écran de la rpi.

Architecture :

• Le programme qui contrôle le robot en match (./raspi) est indépendant, prend en argument la couleur de jeu, fait quelques tests (positionnement de l'ascenseur notamment) et se lance dès que la tirette est retirée. Si la tirette n'est pas présente, le programme se lance immédiatement
• ./raspi donne son log en output. On a utilisé un flux custom qui affiche l'heure (en ms depuis le lancement du programme) pour chaque ligne de log
• ./raspi essaye de se connecter avec un FIFO unix au GUI, et s'il y arrive, il envoie sa position à chaque fois qu'elle change, sous forme d'un message “Google Protocol Buffers”
• ./gui est lancé automatiquement au démarrage de la raspi, et s'affiche immédiatement. Un programme est chargé de relancer ./gui si on le ferme. ./gui permet de contrôler les servos, steppers, voir l'état des capteurs, puller automatiquement le code du git (et faire make automatiquement), choisir la couleur de l'équipe et lancer ./raspi.
• Une fois ./raspi lancé, ./gui ouvre une FIFO pour afficher en temps réel la position du robot, et affiche l'output de ./raspi dans une petite console. Il y a également un bouton abort sur l'écran.

Une Arduino nano est branchée sur le raspi avec un cable usb court. Cette arduino est branchée à une carte contrôlant les servos, et une carte contrôlant les capteurs. Le raspberry envoie des instructions en serial à l'arduino, et est également capable de la reflasher. L'arduino répond également en serial à la raspi. Certaines commandes permettent d'actionner plusieurs servos en séquence (par exemple actionner un servo jusqu'à ce qu'un capteur se déclencheà.

Cette arduino est également responsable de lancer la fusée au bout de 90 secondes. Pour cela, nous avons implémenté une fonction delay2 et modifié toutes les boucles bloquantes pour vérifier un timer. On aurait peut-être dû utiliser un timer interrupt mais on ne savait pas comment faire et il n'y avait pas internet dans le hall des expos.

Voir le howto sur le papilio duo. En gros c'est une carte avec un fpga d'un côté, et un arduino de l'autre, qui partage une dizaine de ports.

L'arduino est branché en serial sur la raspi, qui lui envoie des ordres synchrones ou asynchrones. L'arduino envoie ensuite via un registre à décalage les ordres au fpga, qui les exécute (essentiellement les ordres consistent à générer une suite d'impulsions pour les steppers, en effectuant une rampe d'accélération et de décélération pour effectuer une distance fixe).

Dans l'état actuel, le robot peut uniquement avancer en ligne droite ou tourner sur place.

On a eu plein de problèmes parce que le registre à décalage se… décalait. Prévoir un code correcteur d'erreurs robuste au décalage ? Ou alors vérifier les timings du FPGA (le diviseur en un tick d'horloge c'est très limite)

Le fpga est également responsable de vérifier l'état du radar avec une bascule de schmitt, et de se mettre en pause s'il voit un obstacle. Ça aurait été mieux de faire une petite rampe de décélération quand on voit un obstacle pour éviter de glisser.

Bref avec tout ça on est assez précis, et on peut aller assez vite.

TODO