Projets:Lab:2013:Couperobotique2014

From Electrolab
Revision as of 09:50, 22 September 2013 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
  • 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]

Objectif

1)Mettre en place une base de robot avec asservissement. (encore plus que l'année derniere :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.

Les actions

Thème : Prehistobot

Pour le moment pas plus d'infos, ça devrais arriver fin septembre

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 1g (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.

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

Asservissement

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.

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.

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.


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.

Elle communiquerais avec le bus général pour renvoyer des informations de vitesse/position et recevoir ses consignes de vitesse.

la carte en question: Projets:Lab:2013:Couperobotique2014:Carte_Asservissement

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.

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.

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

Obligation réglement

  • en attente


DONE

  • Elec
    • Test des encodeurs

WIP

  • Elec
    • Test de la communication sur bus rs485 (écriture d'un protocole de com adapté a notre utilisation)

TODO LIST

  • 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
      • Refaire le draft sous CAO puis FAO
      • Voir quels matières usiner => vérifier/approvisionner outils de coupe
  • Elec
    • Gravure et test de la carte d'alim de raoul
    • Design/recherche d'une carte de puissance moteur
    • Design d'une carte contrôle encodeurs