Projets:Lab:2013:Couperobotique2014
Contents
About
Après la première participation (mouvementée) de l'Electrolab à la coupe de France de robotique l'équipe 2013 a décidé de remettre le couvert en 2014.
Page de Planète Sciences dédié à la coupe de Robotique
Le thème de l'année : Prehistobot
La table:
Et pour le reglement c'est ici:
Projets:Lab:2013:Couperobotique2014:reglement
Dates organisation
- 28 Septembre 2013 : Présentation du règlement 14H-17H à la cité des sciences et de l'industrie
- TBD (Novembre) : Date limite d'inscription
- TBD (Janvier) : Dossier technique
- TBD (Avril) : Rendre le poster
- 28 au 31 Mai 2014 : mai 2013 : Le concours à la La Ferté-Bernard
L’équipe
- Pilou [usinage, suivi de projet, administratif]
- Stéphane(Raoul) [asserv, meca, elec, dev]
- 3dsman [design/previz, elec, dev]
- Jojo [design bras ventouse/impression 3D]
Nos objectifs
1)Mettre en place une base de robot avec asservissement. (encore plus que l'année dernière :p)
2)Réfléchir une architecture limitant le câblage (qui a posé de gros problème en 2013)
3)Définir une architecture modulaire pour faciliter le développement parallèle des éléments du robot, leur maintenance et permettre des upgrades localisées.
4)Communiquer plus efficacement vers l’extérieur (notamment sur la ML du lab et sur le wiki)
5)S’amuser et apprendre
Avancement
Motorisation
On a trouvé quelques petits moteurs que nous avons pu tester. Ils ronronnent niquel, n'ont pas de jeu perceptible et après simulation de leur comportement par Stéphane devraient nous donner toute satisfaction en permettant des accélérations théorique de 1m/ss (en restant dans des voltages/ampérages pépère pour les moteurs) pour un robot de 7kg avec des vitesses de 2m/s en pointe.
Cela devrais nous faire faire un sacré gap par rapport a l'année dernière et nous permettre de faire un asservissement digne de ce nom (enfin en tout cas cette année on a plus d'excuses de ce coté la :))
retour d’expérience:
Rien a dire de ce coté la! Maxon est connu pour sa qualité, ça n'est pas pour rien. Les moteurs ont fonctionné impeccablement. Il faut par contre faire très attention aux (trop fines) pins d'alim qui sont vraiment facile a casser...
Contrôleur principal
- Carte frdmkl25z de chez freescale
- 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP
Capteurs
Dans le but de limiter les fils et de se conformer à la recherche de modularité définie dans nos objectifs, nous travaillons actuellement à l'utilisation d'un bus rs485 pour la communication capteurs/contrôleur principal.
Après quelques tests sur des versions dip des circuits nous avons pu confirmer notre architecture de bus pour cette année et nous nous lançons donc en phase de conception des cartes sur cette base:
- chaque capteur embarquera un microcontrôleur Atmega pour faire des prétraitements en local et gérer la communication sur le bus. Un avantage important ce cette solution sera de faciliter l’amélioration des capteurs par l'ajout de fonctions logicielles dans les firmwares des microcontrôleurs sans avoir à toucher au matériel.
- Nous utiliserons le circuit SN65HVD3082EDR comme driver de bus.
- Le bus est composé de 4 fils (gnd, +5v logique et 2 fils de plus pour le différentiel du rs485)
- Les deux circuits seront utilisés en version tqfp pour réduire la taille des capteurs
- Les capteurs/actionneurs ayant besoin de plus de puissance (moteur, servos, solénoïdes,...) seront alimentés par un câble de puissance supplémentaire fournissant +5V, +12V et GND
Le choix des Atmega a été motivé par la taille et la multiplicité des configuration de cette famille qui nous permettra d'avoir des capteurs très différents dans leurs fonctionnalités et leur taille tout en conservant des librairies communes (notamment celles de communication sur le bus).
nous nous dirigeons tout particulièrement sur la série atmega48/88/168 (le brochage des 3 est le même) pour sa facilité de programmation (on peut les programmer avec un arduino en 5mn), sa taille réduite (32 broches en tqfp), son faible cout et le nombre de librairies développées sur ces modèles
Certaines pattes des Atmega sont réservées pour des fonctions génériques installées sur toutes les cartes capteur (programmation in-circuit, 2 leds d'information et les pins indispensables à la communication rs485)
Projets:Lab:2013:Couperobotique2014:Carte Generique
Projets:Lab:2013:Couperobotique2014:Carte Servos
Projets:Lab:2013:Couperobotique2014:Carte Capteurs Ultrason
Projets:Lab:2013:Couperobotique2014:Carte Moteurs CC
retour d’expérience:
La structure modulaire à base de cartes embarquant un petit microcontrôleur est définitivement validée! C'est un modèle redoutablement efficace des lors que le bus est fiable.
Cette structure a parfaitement remplie ses objectifs de développement parallèle, modifications locales et de souplesse d'utilisation (les pins d'une carte se sont dessoudés en emportant des pistes entre deux matchs il nous a fallu 10mn pour changer la carte par du spare et la reprogrammer).
Le choix des atmegas est mitigé: l'avantage de leur tarif faible et de leur faible encombrement ne compense pas leurs fonctions de debug très limitées. Cela a posé de gros problème principalement pendant la phase de développement du protocole de com rs485...
Pour la suite nous envisageons la même structure de cartes sur bus 485 mais à base de microcontrôleurs arm M0.
Les leds de signalisation ont été très pratiques pour le debug et la signalisation pendant les test et en cours de match (vraiment cool cette led rouge qui s'allume sur le capteur ultrason quand il repère un truc :)).
C'est le genre de détail qui vous sauve la vie sur place (c'est grâce à ces leds que nous avons par exemple détecté le problème d'alim signalé plus bas)
Les drivers rs485 n'ont eux pas posé de problème (nous avons quand même du patcher toutes les carte pour leur ajouter une résistance de pull up sur une des pins :p)
La connectique de chez gotronic était cette année plutôt fiable. Seuls les raccords fil à fil et les connecteurs sur les encodeurs ont été limite probablement pour cause de pince de sertissage peu adapté et de fils trop fins (ils avaient tendance a se casser au niveau du connecteur).
Sans avoir testé nous conseillerions tout de même d'utiliser les connecteurs de CUI pour les encodeurs (ils sont visiblement plus adapté à leur produit qu'un truc fait main)
Asservissement
encodeurs
Cette année, contrairement a l'année passée nous nous dirigeons vers des codeurs sur des roues indépendantes situées dans l'axe des roues moteur.
Raoul nous a trouvé des petits encodeurs capacitifs a un prix très intéressant les AMT102-V de chez cui inc.
Après de petits test rapides ils nous semblent être plutôt adapté a notre utilisation, nous referons des tests plus complets et précis afin de confirmer mais ce premier essai est plutôt encourageant.
Avec 1024 cycle/tour ils atteignent une précision qui devrais nous permettre d'avoir une finesse de mesure théorique de l'ordre du 10eme de mm.
retour d’expérience:
Apres avoir fait rouler le robot il nous est apparu que ces encodeur sont parfaitement adapté a une utilisation a la coupe.
En plus de leur tarif raisonnable (voir faible pour ce genre de matériel) ils offrent une précision et une fiabilité tout a fait correcte.
Nous les conseillons aux équipes a budget réduit qui ne veulent pas transiger sur la qualité de leur asservissement.
Attention: avec ce niveau de précision des encodeurs la mécanique des roues codeuses deviens critique (les petites erreurs de mesures que nous avons pu repéré étaient principalement dues a notre mécanique un peu faible au niveau de la fixation des bras des codeurs)
contrôle moteur
Nous partons sur une carte commune pour les 2 capteurs, basé sur le modèle de notre carte capteur générique, qui gèrerait directement un asservissement en vitesse des deux moteurs.
Elle communiquerais avec le bus général pour renvoyer des informations de vitesse/position et recevoir ses consignes de vitesse.
La carte est gravée, soudée et les premiers tests sont en cours... pour le moment plutôt concluants. Raoul nous a déjà sortit un petit code pour faire la pwm en soft et nous obtenons des rampes (simples) d’accélération sur les moteurs :)
la présentation de cette carte sera mise a jour au fur et a mesure des avancées dans sa page dédiée: Projets:Lab:2013:Couperobotique2014:Carte_Asservissement
retour d'experience:
La carte d'asservissement sur le bus a finalement été remplacée par un shield pour la frdm (les problemes de debuggage de la librairie de com rs485 nous ayants poussé a jouer la securité).$
Cette carte, prévue à la base pour etre arduino compatible (par secu) et faite un peu rapidement a du etre patchée pour corriger quelques erreurs mais son fonctionnement n'a finalement posé aucun probleme lors de la coupe
Elle est basée sur les meme drivers de moteur que pour la carte originale et qui nous ont aussi donné toute satisfaction (en meme temps vu la qualité de nos moteurs et la vitesse finale du robot on ne les solicitaient pas vraiment :p)
Mécanique
Nous avons bien avancé dans la construction d'un bloc moteur/encodeurs/roues qui nous permettra de tester les encodeurs en condition proche de la réalité et d'avoir de quoi se mettre sous la dent dès qu'on aura l’électronique de commande.
Après découverte des roues banebot nous avons décidé de partir dessus, il nous a fallu refaire le design du bloc ce qui a été l'occasion de le simplifier pour l'usinage (ou la fabrication pas impression 3d).
Le bloc moteur est donc au final constitué de 5 pieces en alu, 2 roues codeuses usinées en plastique, 4 pieces imprimées à la reprap et 4 roulements à bille.
Cette année nous nous concentrerons sur une base roulante réutilisable donc la priorité sera clairement donnée a la motorisation et à son contrôle.
retour d'experience:
La base mecanique etait tout a fait fonctionnelle et les seuls problemes rencontrés (non bloquants) ont été dans le design des bras des encodeurs.
Fixés sur un seul roulement ils avaient un jeu tangenciel un peu trop important et un changement de roulement nous a fait gagné un facteur 2 de precision sur un des deux encodeurs ce qui laisse présager une belle amelioration en supprimant totalement ce jeu.
Ce bloc a donc été redesigné avec deux roulements mais non testé (la solution en place fonctionnais et le temps manquait pour changer cette partie).
Il faudra l'essayer en condition réelles pour voir les gains.
Nous pouvons aussi envisager des blocs alu beaucoup plus fins et donc moins cher, moins lourd et plus simple d'usinage, ceux ci ayant été clairement surdimenssionné par manque de connaissance de ce materiau.
Alimentation
Le robot de cette année devrais tourner sur 2 batteries nimh 9.6v mises en parallèle.
- Raoul est entrain de nous développer une carte d'alim maison (boost 12V,5A) pour les moteurs qui devrait être plus efficace que les dc/dc chinois de l'année dernière qui nous ont causé quelques désagréments...
- La carte alim des moteurs est en cours de test/debuggage, elle ne tiens pas sa tension en cas de charge importante alors que le composant est prevu pour.
Peut etre un probleme de CEM non prevu ou une erreur dans les calculs (particulièrement tricky sur le composant utilisé) des valeurs des composants annexes...
retour d’expérience:
L'alim boost a finalement été abandonnée, trop de bug incompréhensibles et peu de connaissance sur le debuggage de ce type d’électronique.
Nous nous somme rabattu sur un DC/DC pour le 12v et des DC/DC de modélisme pour l'alim logique 5V et la puissance des servos.
Le courant a finalement été fournis par 2 batteries plomb 12V placées en parallèle placées au ras du sol pour abaisser le centre de gravité et améliorer la stabilité du robot.
Cette solution bien que peu économe en place nous a été salvatrice puisque suite a un problème (encore) avec le DC/DC 12V nous avons du le shunter et mettre la carte de puissance moteur directement sur les batteries.
Il faut vraiment que nous trouvions une alim digne de ce nom!!!
Les DC/DC de modélisme ont par contre totalement remplis leur rôle, il est possible que nous réutilisions ce type de matériel pour d'autres robot...
