2019 - Robot Télécom Strasbourg

Partagez votre expérience en expliquant comment vous travailler sur votre robot.
Share your experience by explaining how you work on your robot.
Post Reply
User avatar
Augustin.B
Posts: 28
Joined: Thu 15 Nov 2018, 16:00

2019 - Robot Télécom Strasbourg

Post by Augustin.B » Sun 02 Jun 2019, 16:13

Salut à tous!

Comme beaucoup d'asso étudiantes, Robot Télécom Strasbourg souffre d'un problème de passation et de transmission des savoirs, c'est pour ça que bien que nous participons à la coupe depuis 94, c'est pour nous, l'équipe actuelle, notre première participation.

A la suite de cette semaine riche en évènements et en rencontres, j'aimerai déjà remercier Planètes Science, et leur bénévoles pour leur boulot de fou, tout était super organisé, tout le monde était souriant et là pour nous aider quand il le fallait.

J'aimerai aussi remercier toutes les équipes, c'était fantastique de découvrir tant de gens géniaux et de robots différents et originaux. L'atmosphère de partage à la coupe était différente de tout ce que nous avons connu partout ailleurs, et nous en ressortons avec l'impression d'avoir appris autant en quelques jours avec vous tous, que nous l'aurions fait en plus de trois mois.

Je vais parler de notre robot maintenant, car on parle moins souvent de pourquoi un projet à échoué et je pense que d'autres équipes pourraient apprendre de nos nombreuses erreurs, particulèrement celles qui font une première participation.
J'en profite aussi pour dire que au cours de l'été et jusqu'a la fin de l'année nous allons bosser sur pas mal d'articles pour présenter les aspects de nos travaux qui peuvent être repris (notamment le travail énorme fourni par Jonathan, le respo asservissement), si vous voulez rester au courant, je vous enjoue à nous suivre sur Twitter @RobotTelecom.


Voici donc notre robot : Le Jamais Testé

Image

I] La mécanique

On va commencer par la méca parceque c'est l'aspect le plus important, c'est la base de la pyramide qui mène à un robot qui fait de bon matchs.
C'est un robot deux roues, avec un bras 4 axes pourvu d'une ventouse, jusque là rien de bien compliqué.

Pour nous c'était la première fois qu'on utilisait un logiciel de CAO pour faire des pièces usinées et de l'assemblage, pire, il a fallu des mois pour se former à l'utilisation des machines de fraisage (nous n'avons par d'aide exterieurs pour la réalisation des pièces).

Image

Voila l'essentiel de la base, deux moteurs, avec une transmission pour gagner de la place, et des roues folles codeuses.

Déjà j'ai fait une erreur au niveau du choix des moteurs, et elle est évidente quand on voit leur taille et qu'on a un peu d'expérience, pas besoin de moteurs à 27kg/cm de coupe, et 15A en pic pour pousser une base de 2kg à peine, en plus, ayant une faible vitesse, on est obligé d'ajouter la multiplication de vitesse.
Cela gène la conception de la base puisque leur encombrement rend toute la conception plus compliquée, l'idée était de faire une base pouvant être utilisée comme robot secondaire l'année prochaine, cela a laissé peu de place une fois les cables routés.

Tout les pièces méca pour la tenue de l'axe et les roues folles ont très bien fonctionné, on a validé une technique intéressante pour les clubs qui ne peuvent pas facilement usiner de métal par eux même qui est l'utilisation de pièces composites en impression 3D/Fibre de verre (G10 ou PCB) qui peut être usiné sur des machines très légères, ces pièces sont très précises et extrèmement résistantes.
Le désavantage c'est le poids trop léger de la base, beaucoup d'équipes utilisent des pièces en métal pour la lester et avoir une meilleure adhérance et donc vitesse.

La second grosse erreur et dans le choix de positionnement et du nombre des roues folles, pour moi maintenant il est impératif qu'une base deux roues n'ai que 3 points de contacts avec le sol, à causes d'imprecisions dans le réglage des roues folles, c'était quasiment impossible d'avoir une base qui n'était pas bancale.

La dernière erreur, qui nous a coûté plus d'une journée de travail, c'est les roues folles codeuses, on a utilisé des capteurs magnétiques sans contact (les AMS AS5601 pour les curieux) ceux-ci communiquent en I2C, nous n'avons pas utilisé de CRC, ni de gestion d'erreur, et ce n'est qu'après la fin de la coupe qu'on a compris que nos mesures ultra bruités venaient d'erreurs de transmission (on le transmettait dans des cables de 20cm passant à côté des drivers). Autre leçon, L'I2C est designé pour se propager dans des traces de PCB de chip à chip, pas dans des fils.
Cela, couplé au fait qu'on avait pas d'encodeur moteurs, nous a forcé à redesigner une partie de la base à la coupe pour y mettre des moteurs pololu avec encodeurs très anciens, ça nous a permis de récupérer un mouvement qui fonctionne (pourri, mais suffisant pour les matchs).

Pour ce qui est des aspects de cette méca qui ont très bien fonctionné, c'est en demi teinte aussi :
Image
On a entièrement développé nos embouts et connecteurs pneumatiques nous même pour les adapter à des ventouses qu'on a eu en échantillon gratuit, quand je vois l'efficacité des systèmes pneumatiques "clé en main" qu'on peu trouver en chine, j'y vois maintenant un gâchis de deux semaines de travail, pareil pour les engrenages de la base, qui m'ont pris un temps fou a correctement dimensionner et calibrer pour un bon fonctionnement alors qu'on peut directement designer avec des pièces toutes faites.



II] Electronique et intégration mécatronique

De base, j'ai designé les volumes sans prendre en compte le routage des fils, on était en retard et on s'est dis que ça passerai, ce qui est une très mauvaise idée :

Image

Clairement, quand on dois brancher un raspberry pi à un lidar, un bras robot, une carte pompe, une carte teensy 3.6, et en plus avoir la puissance dans les fils, le bouton d'arrêt d'urgence, les switchs stratégie et les divers cables usb, le tout dans une boite de 4x15x20cm, c'est compliqué.
Bizarrement ce n'est pas ça qui a causé des problèmes, mais c'est clairement loin d'être une solution idéale ou clean.

Nous avons eu exactement 2 avaries électroniques sur la coupe:

La première c'est avec notre bras robot Dynamixel, la carte d'alimentation fournie par Robotis ne possède pas d'isolation galvanique (isolation entre les masses de l'USB, et de l'alim moteurs), les concepteurs se sont dit que mettre une diode sur l'alim suffit à protéger contre un utilisateur qui branche une alim a l'envers, dans un système embarqué comme le notre c'est faux, le 12V remonte direct sur la masse de l'USB et détruit tout ce qui se trouve en amont, on a eu de la chance c'était qu'un dongle USB, et on avait une rechange.

La seconde c'est une fois que nous avons remplacé nos moteurs, on a ajouté les fils encodeurs, et lors d'un tests ils se sont coincé dans les moteurs, ce qui a causé un court circuit et les a détruit rapidement, c'est ça qui a mis un terme à notre coupe.

Ce qu'on dois retenir de ça c'est faire très attention à son cablage et a ses choix de connecteurs, il faut éviter à tout prix de devoir avoir à faire des modifs lors de la coupe, et prévoir ses cartes ou son intégration pour être facilement réparable ou changé et modifiée, ce qui n'est pas si compliquée quand on y réfléchi un peu à l'avance.


Pour ce qui est du système électronique en général, il s'agissait d'une carte Teensy 3.6 faisant tourner l'asserv, communicant avec une raspberry pi avec debian qui controle la stratégie, le bras dynamixel, et le lidar. Rien de bien compliqué en somme, et pourtant on a aussi été bloqué pour plusieurs raisons.

III] Programmation

Nous sommes venu à la coupe sans évitemment fonctionnel, notre capteur pour répondre à ce besoin est le Lidar rotatif de robotis, le LDS-01.
Nous n'avions pas d'expert sur son utilisation, juste du code fourni par un professeur, on pensait l'intégration facile puisqu'il s'agit d'un "simple lidar USB".
Bien sûr, rien n'est simple à la coupe, et faire fonctionner en multithreading un lidar, un bras, et une strat sur python sur une raspberry pi avec debian et tout sauf simple, et malgré l'aide de la debug team (big up à eux qui sont resté à notre stand plus de 2 heures pour nous aider à régler le problème et comprendre le Multi-Threading), cela n'a pas fonctionné à temps.


IV] Conclusion

Je pense qu'a la vue de notre robot et de ce qu'on a réalisé, on peut voir qu'on a été très ambitieux, trop ambitieux même. On a voulu utiliser trop de solutions un peu exotiques, ou non fiabilisés, et au final cela ne gagne pas le coupe.

Nous avons tous compris maintenant que le maître mot, c'est la fiabilité, il vaut mieux un robot qui fait 5 point a chaque matchs qu'un robot qui en fait 100 sur un match, ou pire, qui ne fonctionne pas du tout.

TL;DR
  • Les moteurs DC 25mm sont largement suffisants pour propulser une petit base (~2kg)
  • Les petites batteries lipo 1800mAh 12V sont plus que suffisant pour des petites bases
  • Il est très important de lester la base si on veut une bonne adhérence et atteindre des bonnes vitesses
  • Chercher les solutions mécaniques les plus simples, utiliser des pièces toutes faites et réserver l'impression 3D pour des choses simples
  • Limiter les points de contacts avec le sol à 3 pour une base deux roues
  • Placer des codeurs sur les moteurs et avoir des roues codeuses au cas où
  • Prévoir le routage des fils à l'avance, utiliser un connecteur différent par type de signal, et bien sûr un connecteur différent pour la puissance
  • Utiliser un framework de programmation simple (style arduino) pour rendre la passation simple d'année en année, le code arduino a beau être peu optimisé, on peu trouver de bonnes libs et aller très loin avec!
Et le plus important: il vaut mieux avoir une base avec mouvement et évitemment basiques et fonctionnel mais qui ne fait pas d'actions, qu'une base avec de supers actionneurs qui ne bouge pas!
Ce n'est pas une perte de temps de passer 4 our 5 mois juste à fiabiliser ces systèmes, au contraire!
Il faut le dire, la partie amusante de la coupe c'est la stratégie et l'optimisation des matchs, certes c'est fun de devoir régler des problèmes d'élec ou de code inattendus, mais ça l'est encore plus de pouvoir enfin s'amuser avec le nouveau jouet qu'on a mis un an à faire.


Ces conseils on les a appris à la dure lors de la coupe, et certains ont été donnés par des équipes, merci à eux, et on espère revenir l'année prochaine avec un robot du feu de dieu!

Voilà, merci si vous avez lu ce post beaucoup trop long, j'espère qu'il pourra venir en aide à de nouvelles équipes.
Encore une fois, on va continuer à mieux résumer toutes ces pensées, et murir nos idées, et on reviendra avec une version update de ce post sous forme d'article sur notre site!

User avatar
Nirgal
Posts: 269
Joined: Mon 25 Oct 2010, 20:05
Contact:

Re: 2019 - Robot Télécom Strasbourg

Post by Nirgal » Mon 03 Jun 2019, 09:43

Bravo pour ce retour d'expérience...
Tu décris toutes les erreurs légitimes par lesquelles il faut passer la première année pour aborder une deuxième année pleine de promesses.

RDV l'an prochain, où vous serez dans le TOP 16 !

Grâce à :
- un câblage propre
- une base roulante qui roule dès septembre
- un évitement opérationnel avant décembre
- des actionneurs simples et en nombre limités
- des recalages réguliers contre les bordures
- des matchs logs pour sortir plein d'informations utiles aux débogages
Nirgal
Robot-ESEO

User avatar
Manta
Posts: 55
Joined: Sat 03 Oct 2015, 10:37
Contact:

Re: 2019 - Robot Télécom Strasbourg

Post by Manta » Mon 03 Jun 2019, 17:18

Super post ! c'est vrai qu'on publie beaucoup d'expérience qui fonctionne, mais pas trop celle qui ne fonctionne pas.

Je dirai que concernant la partie bille porteuse tu fais des conclusions un peu hâtives. Nous utilisons 4 billes porteuses et 2 roues de propulsions. On place les billes porteuses légèrement plus haut que les roues motrices ce qui donne à notre robot un peu l'air d'un cheval à bascule. Donc ça donne 6 points de contact (sans parler des codeurs), mais on en utilise que 4 simultanément.

Cette solution fonctionne vraiment bien, peut être que 3 points aussi, mais je n'ai pas de retour sur ça.
Champions de France 2018, 3ème à EUROBOT 2018 :D

2017 à 2018 : Robotech Legends
2012 à 2016 : Robotech Montpellier

Suivez l'actualité de Robotech Legends :

Image Image Image Image

User avatar
baptiste_c
Posts: 148
Joined: Mon 20 May 2013, 15:09

Re: 2019 - Robot Télécom Strasbourg

Post by baptiste_c » Mon 03 Jun 2019, 19:03

Je plussoie. Notre robot est en légère bascule avant arrière suivant le sens d'avance. Ca te permet d'augmenter la garde au sol à l'avant et donc de mieux tolérer les imperfections de la table !
Baptiste
Supaero 2011 - 2014
A.I.G.R.I.S. 2015 - ...
Prix de l'innovation 2016
Vice-champion de France et 3ème à Eurobot 2017
Vice-champion de France 2019

User avatar
romain_cvra
PMI
Posts: 1230
Joined: Sat 30 Jun 2007, 16:17
Location: suisse
Contact:

Re: 2019 - Robot Télécom Strasbourg

Post by romain_cvra » Mon 03 Jun 2019, 23:12

Très chouette ton poste Bravo! Faudrait plus d'équipe qui publie comme cela!

D'accord avec les autre des points d'appuis à l’avant et a l’arrière ne pose pas de problème pour autant qu'il aie un petit peu jeux.
Site web : http://www.cvra.ch.
Le code source : GitHub
Visualisation CAO 3D de nos robots : GrabCAD

User avatar
oG
Posts: 57
Joined: Fri 02 Jun 2006, 11:28
Location: Bordeaux(33)
Contact:

Re: 2019 - Robot Télécom Strasbourg

Post by oG » Tue 04 Jun 2019, 19:08

Augustin.B wrote:
Sun 02 Jun 2019, 16:13
Bien sûr, rien n'est simple à la coupe, et faire fonctionner en multithreading un lidar, un bras, et une strat sur python sur une raspberry pi avec debian et tout sauf simple, et malgré l'aide de la debug team (big up à eux qui sont resté à notre stand plus de 2 heures pour nous aider à régler le problème et comprendre le Multi-Threading), cela n'a pas fonctionné à temps.
L'année prochaine passez nous voir plus tôt ! 😜
Augustin.B wrote:
Sun 02 Jun 2019, 16:13
Nous avons tous compris maintenant que le maître mot, c'est la fiabilité, il vaut mieux un robot qui fait 5 point a chaque matchs qu'un robot qui en fait 100 sur un match, ou pire, qui ne fonctionne pas du tout.
Y'a des équipes qui mettent bien plus d'une participation à arriver à cette conclusion. La mise en pratique est complexe, même avec une dizaine de participations derrière nous, on ajoute toujours l'élément de trop qui fait perdre plus de temps qu'il ne peut rapporter de points.

Pour ton problème d'appuis, le mieux est de mettre les codeurs sur amortisseurs pour être sûr qu'ils touchent. Ne pas se perdre est de loin le plus important !

User avatar
Augustin.B
Posts: 28
Joined: Thu 15 Nov 2018, 16:00

Re: 2019 - Robot Télécom Strasbourg

Post by Augustin.B » Wed 05 Jun 2019, 11:01

Merci à tous pour vos réponses, et les conseils/remarques que vous avez ajouté :)

Post Reply