Difference between revisions of "Projets:Lab:2013:Couperobotique2014"

From Electrolab
Jump to: navigation, search
(Objectif)
 
(29 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
[http://www.planete-sciences.org/robot/index.php?section=pages&pageid=79 Page de Planète Sciences dédié à la coupe de Robotique]
 
[http://www.planete-sciences.org/robot/index.php?section=pages&pageid=79 Page de Planète Sciences dédié à la coupe de Robotique]
 +
 +
 +
Le thème de l'année : Prehistobot
 +
 +
La table:
 +
 +
[[File:Table_cc.png‎]]
 +
 +
Et pour le reglement c'est ici:
 +
 +
[[Projets:Lab:2013:Couperobotique2014:reglement]]
  
 
= Dates organisation=
 
= Dates organisation=
Line 19: Line 30:
 
*Stéphane(Raoul) [asserv, meca, elec, dev]
 
*Stéphane(Raoul) [asserv, meca, elec, dev]
 
*3dsman [design/previz, elec, dev]
 
*3dsman [design/previz, elec, dev]
 +
*Jojo [design bras ventouse/impression 3D]
  
= Objectif =
+
= Nos objectifs =
 
   
 
   
 
1)Mettre en place une base de robot avec asservissement. (encore plus que l'année dernière :p)
 
1)Mettre en place une base de robot avec asservissement. (encore plus que l'année dernière :p)
Line 30: Line 42:
 
4)Communiquer plus efficacement vers l’extérieur (notamment sur la ML du lab et sur le wiki)
 
4)Communiquer plus efficacement vers l’extérieur (notamment sur la ML du lab et sur le wiki)
  
= Les actions =
+
5)S’amuser et apprendre
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.
 
  
[[File:Table_cc.png‎]]
+
=Avancement=
  
Et voici le fichier blender:
+
==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.
  
[http://3dsman.free.fr/table_cdr2014.zip table_cdr2014.zip]
+
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 :))
  
  
'''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.'''
+
'''retour d’expérience:'''
  
==La fresque==
+
Rien a dire de ce coté la!
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
+
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...
  
Les dessins seront fournis par les équipes et doivent mesurer entre 8x10cm et 10x16cm et 1cm d’épaisseur max
+
==Contrôleur principal==
  
3 pts par dessin accroché en fin de partie
+
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KL25Z Carte frdmkl25z de chez freescale]
 +
**48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP
  
6 pts max
+
==Capteurs==
==La conquête du feu==
+
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.
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.
+
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
  
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.
+
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).
  
1 pts par feu posé sur le sol dans le bon sens
+
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
  
2 pts par feu posé sur un foyer dans le bon sens
+
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)
  
32 pts max
+
[[Projets:Lab:2013:Couperobotique2014:Carte Generique]]
==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).
+
[[Projets:Lab:2013:Couperobotique2014:Carte Servos]]
  
1 pts par fruit comestible posé dans le panier
+
[[Projets:Lab:2013:Couperobotique2014:Carte Capteurs Ultrason]]
  
-2 pts par fruit toxique resté dans le panier en fin de partie
+
[[Projets:Lab:2013:Couperobotique2014:Carte Moteurs CC]]
  
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.
+
'''retour d’expérience:'''
  
2 pts par balle accrochée en fin de partie
+
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.
  
3 pts pour les deux equipes pour chaque mammouth touché par les 2 couleurs (action de cooperation)
+
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).
  
12+6 pts max
+
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...
==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
+
Pour la suite nous envisageons la même structure de cartes sur bus 485 mais à base de microcontrôleurs arm M0.
  
6 pts si le filet est bien placé sur un des deux mammouth
+
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 :)).
=Avancement=
+
  
==Motorisation==
+
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)
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==
+
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)
  
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KL25Z Carte frdmkl25z de chez freescale]
+
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).
**48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 80LQFP
+
  
==Capteurs==
+
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)
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.
+
 
+
Si ce choix est confirmé par les essais chaque capteur embarquera un microcontrôleur pour faire des prétraitements en local et gérer la communication sur le bus. Un intérêt supplémentaire 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.
+
 
+
Dans un premier temps nous allons faire des tests de communication rs485 en utilisant des ATMEGA48 (et 88) pour le contrôle et le circuit SN65HVD3082EDR comme driver de bus.
+
Le choix des atmega48/88 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).
+
 
+
[[Projets:Lab:2013:Couperobotique2014:Carte Generique]]
+
 
+
[[Projets:Lab:2013:Couperobotique2014:Carte Servos]]
+
  
 
==Asservissement==
 
==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.
 
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.
  
Line 126: Line 123:
 
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.
 
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.
  
Nous réfléchissons encore a gérer les encodeurs comme des capteurs (avec microcontrôleur et bus rs485) ou a les considérer comme des capteurs a pars (il faut des transferts très rapides et synchronisée). Une solution intermédiaire serait de leur dédier un bus rs485 spécifique.
+
'''retour d’expérience:'''
  
Sans pour autant exclure totalement les options citées juste au dessus des calculs de disponibilité du bur rs effectué par Stéphane nous laissent a penser que les informations encodeurs devraient pouvoir parfaitement s'inclure dans le bus général sans provoquer de latence.
+
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.
  
Une option étudiée serait de mettre en place 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.
+
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.
 
Elle communiquerais avec le bus général pour renvoyer des informations de vitesse/position et recevoir ses consignes de vitesse.
  
Le schématique de cette carte est prêt, il faut encore qu'on la fasse vérifier par des yeux d’électroniciens expérimentés <mode lechecul>on a l’embarras du choix au lab</mode lechecul>
+
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:
 
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]]
 
[[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==
 
==Mécanique==
Nous avons bien avancé dans le design d'un bloc moteur/encodeurs/roues que pilou vas mettre en CAO et usiner et 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.
+
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.
 +
 
 +
[[File: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.
 
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==
 
==Alimentation==
* Raoul est entrain de nous développer une carte d'alim maison qui devrait être plus efficace que les dc/dc chinois de l'année dernière qui nous ont causé quelques désagréments...
+
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.
  
==Obligation réglement==
+
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.
  
*en attente
+
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!!!
  
==DONE==
+
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...
*'''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[DONE]
+
*'''Elec'''
+
**Test des encodeurs
+
**Test de la communication sur bus rs485
+
**Design de la carte d'asserv
+
**Design d'une carte de contrôle de servomoteurs
+
==WIP==
+
*'''Méca'''
+
**Refaire le draft du bloc moteur sous CAO puis FAO[EN COURS par Pilou]
+
*'''Elec'''
+
**Vérification de la carte d'asserv
+
**Vérification de la carte de contrôle de servomoteurs
+
*'''Dev'''
+
**Écriture d'un protocole de com pour le bus rs485[EN COURS par Raoul]
+
==TODO LIST==
+
*'''Méca'''
+
**Voir quels matières usiner => vérifier/approvisionner outils de coupe
+
**Design du mécanisme du bras ventouse
+
*'''Elec'''
+
**Gravure et test de la carte d'alim de raoul
+
*'''Dev'''
+
**IA
+

Latest revision as of 10:54, 25 June 2014

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


Le thème de l'année : Prehistobot

La table:

Table cc.png

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

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.

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