Projets:Lab:2013:Couperobotique2014

From Electrolab
Revision as of 12:01, 11 June 2014 by 3dsman (Talk | contribs)

Jump to: navigation, search

About

Logo coupe de france de robotique.jpg

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

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

Le règlement

Thème : Prehistobot

le terrain fait comme l'année dernière 2mx3m, les zones de départ sont placé dans deux coins et les couleurs des équipes seront le jaune et le rouge.

Table cc.png

Et voici le fichier blender:

table_cdr2014.zip

Attention ce modèle est une version temporaire basée sur le pré-règlement distribué lors de la rentrée de la robotique. Des éléments de jeu peuvent changer.

Contraintes

  • La contrainte de dimension a été revue a la hausse cette année. on a maintenant droit a 120cm de circonférence non déployé et 150cm déployé.

Les actions

La fresque

Le robot doit accrocher des dessins embarqués au démarrage sur une surface verticale placée entre les 2 mammouths et recouverte de bandes de scratch

Les dessins seront fournis par les équipes et doivent mesurer entre 8x10cm et 10x16cm et 1cm d’épaisseur max

3 pts par dessin accroché en fin de partie

6 pts max

La conquête du feu

Des feux, matérialisés par des triangles avec une face rouge et l'autre jaune, sont disposés sur le terrain.

Il y en a 6 posé directement sur le sol, 4 posés verticalement sur les bords du terrain dans des "torches" fixes et 6 dans deux torches mobiles soit 16 en tout.

Ces feux doivent être posés sur des "foyers" disposés dans 2 coins du terrain et un au centre. La couleur de la face visible de chaque feu permet de compter les points en fin de partie.

1 pts par feu posé sur le sol dans le bon sens

2 pts par feu posé sur un foyer dans le bon sens

32 pts max

La cueillette

Il y a 4 arbres sur les cotés du terrain avec, suspendus au bout de ficelles, chacun 5 fruits comestibles (en violet) et un toxique (en noir).

l'objectif est de récupérer ces fruits (des bouchons de liège) et les déposer dans le panier de récolte de son équipe (situés sous les mammouths).

1 pts par fruit comestible posé dans le panier

-2 pts par fruit toxique resté dans le panier en fin de partie

20 pts max

La chasse

Deux mammouths sont placés sur les bord du terrain.

Il nous faudra tirer des balles de ping-pong préchargées dans les robots sur des zones de scratch placé au centre des mammouths.

Chaque robot peut embarquer jusqu’à 6 balles.

2 pts par balle accrochée en fin de partie

3 pts pour les deux equipes pour chaque mammouth touché par les 2 couleurs (action de cooperation)

12+6 pts max

La funny action

Il faut dans les 5 secondes qui suivent le match lancer un filet (fournis par les equipes) pour attraper un des deux mammouth.

Si le filet reste accroché au mammouth la funny action est considérée comme valide

6 pts si le filet est bien placé sur un des deux mammouth

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 :))

Contrôleur principal

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 Capteur Couleur

Projets:Lab:2013:Couperobotique2014:Carte Alimentation Basse Puissance


retour d’expérience:

La structure modulaire à base de cartes embarquant un petit microcontrôleur est définitivement validée! C'est une 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).

Le choix des atmegas est mitigé: l'avantage de leur tarif faible et de leur faible encombrement ne compensse 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 était cette année plutôt fiable. Seuls les raccords fil a 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.

Bloc moteur.JPG

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...

DONE

  • Méca
    • design d'un bloc moteur/encodeurs/roues pour pouvoir tester les cartes de contrôle des qu'elles seront disponibles
      • Draft fait sous Blender
      • Draft refait sous Blender (modification pour utiliser les roues banebots)
      • usinage du bloc moteur en alu (dufour,charlyrobot,perceuse à colonne)
      • pieces prototype faites à la reprap
      • Impression des pièces finales à la reprap
      • Mise en place des roues sur la structure
  • Elec
    • Test des encodeurs
    • Test de la communication sur bus rs485
    • Réalisation des cartes capteurs
      • Design d'une carte de capteurs ultrason
      • Gravure et soudure de deux carte capteur ultrason pour tests
      • Test des cartes capteur ultrason réussi
    • Réalisation des cartes actuateurs
      • Design, routage, gravure et soudure d'une carte de contrôle de servomoteurs
      • Test de la partie communication de la carte (elle sert de master pour les tests du protocole)
    • Réalisation de la carte d'asserv
      • Soudure des composants de la carte d'asserv
      • premiers test positifs, les deux moteurs sont contrôlable en pwm
    • Réalisation des cartes d'alim
      • Design et Gravure de la carte d'alim moteurs de raoul
      • Soudure des composants de la carte d'alim moteurs

WIP

  • Méca
  • Elec
    • Test complet de la carte d'asserv (reste a vérifier les entrées encodeurs en quadrature et switches) [EN COURS par Raoul & 3dsman]
    • Debuggage de la carte d'alim moteurs [EN COURS par Raoul & 3dsman]
  • Dev
    • Écriture d'un protocole de com pour le bus rs485 [EN COURS par Raoul]
    • Écriture d'une base de firmware de carte asserv pour le pilotage des moteurs [EN COURS par Raoul]
    • Dev de la carte capteur ultrason [EN COURS par 3dsman]

TODO LIST

  • Méca
    • CAO du bras ventouse complet
    • Finition du bloc moteur
      • design et usinage du plateau de la base
    • étude d’intégration des éléments entre eux
  • Elec
    • Design de la carte d'alim 5/12V
    • caractérisation et design des cartes du bras ventouse
  • Dev
    • Écriture de la librs485 des atmega
    • programmation de la carte servo
    • programmation des fonctions de déplacement dans la carte asserv