Montage second robot

Montage du PMI - Timelapse

Petit bilan, nous avons donc disputé 4 matchs, 3 défaites et 1 victoires. Donc une évolution par rapport à l'année dernière puisque nous avions fait au moins deux matchs forfait (le robot n'avait pas voulu sortir de la zone de départ).

Pour les deux premiers matchs, nous avons mis uniquement le robot principal sur la table. Il est allé pousser un lingot dans la cale. Impossible d'atteindre la bouteille. En fait, il dérivait légèrement sur la table. Suite aux tests effectués sur les tables d'essais, il aurait du l'atteindre. Mais il ne s'est pas comporté de la même manière sur les tables de match. Peut-être dû au fait que les tables de matchs étaient correctement nettoyées. Nous ne sommes pas les seuls a avoir eu le problème.

Avant de disputer les deux derniers matchs, nous avons réussi à faire homologuer le robot secondaire.

Comme nous étions un peu justes niveau temps pour tester le comportement de nos deux robots sur la table avant le 3ème match, nous avons décidé que le PMI ne sortirait pas de la zone de départ. Par contre, il a fait de la chouette lumière ! Une fois encore, le robot principal n'a pas réussi à atteindre la bouteille.

Dernier match, dernier espoir et nous avons eu raison d'y croire ! Le robot principal est allé jeter la bouteille à la mer. Et le PMI est sorti tout tranquillement de sa zone de départ. Ce qui nous a valu une victoire !

Une petite vidéo de ce dernier match :

Equipés d'un dremel, Zaps s'affaire à découper un coin. Ça passe tout pile ! Par contre, le robot refuse catégoriquement de sortir de la zone de départ ! Il n'obéit pas, n'en fait qu'à sa tête, tourne en rond ... Diagnostique, la pile de l'arduino qui est hs. Pile changée, le robot sort, pré-homologation remplie, on va pouvoir continuer l'aventure.

Après un repas vite avalé, chacun s'affaire. On teste d'abord une trajectoire de base qui nous permette de marquer des points. Une fois cette étape passée, on s'occupe du système de détection de la couleur de départ. C'est ensuite au tour du jack de démarrage. Tout roule. Reste le système de détection de l'adversaire qui donne un peu plus de fil à retordre à Dyna. Finalement, tout fonctionne ! Direction l'homologation. C'est la première fois qu'il nous faut un seul essai pour l'homologation dynamique \o/

Nous aurons donc le droit de disputer 4 matchs, soit un de plus que l'année dernière. Donc, nous ferons sans doute plus de points aussi !

Pour la PMI, la carte a cramé. Donc Detapi est encore en train de bosser dessus. On a bon espoir. Il est tellement beau qu'il ne peut que marcher ! On le soutient comme on peut !

[photos du robot à venir ....]

Toute l'histoire commence lors de la disparition tragique du Capitaine Jack-par-out, pendu et passé par dessus bord lors d’une mutinerie.
Incapable de contrôler le navire, les sombres héros de "L'Amer" ( n°2 ) dérivent traversant les océans du vide.
Conscients de leur naufrage inévitable, l'équipage tentera d'envoyer deux bouteilles à l'Amer la Mer,
avant de s’échouer sur une île au trésor découverte par un crocodile clandestin pendu au mat.

Description technique du navire :

Jack du démarrage : montage magnétique reprenant un aimant element de jeux de l’année dernière.

en cours :  arret d’urgence

en cours : voile solaire ( comme dans la planète au trésor )
cette voile solaire permet d’assurer l’apport journalier d’energie nécessaire au navire pour avancer au grés du vent.

Motorisation de secours et energie de secours :

en cas d’absence de vent solaire, c’est à l’aide de deux moteurs pas a pas ( sur lesquels nous grefferons de petites jambes, parce que ma maman m’a dit que sinon il ne marcherai pas ) que le navire avancera, alimenté par l'energie de deux reservoir NiMh placés en soute.

Pilote automatique :

En l’absence du capitaine, c’est à lui de diriger le navire.
Armé d’un contrôleur 8bits, il décidera de la strategie à adopter, communiquera avec le robot principale et ordonera les deplacements de navire, jusqu’à son naufrage.

Crocodile clandestin :

attention, il mord !!! (surtout les tissus) heureusement que son ventre fait le tic-tac d’un réveil pour nous prevenir de sa présence...

( des vidéos de tout cela en actions seront réalisées durant les deux prochains mois. )

Entre le Technistub à Mulhouse, et l'Electrolab ( www.electrolab.fr ) de Nanterre que nous fréquentons depuis déjà un an, on peut dire que notre équipe apprécie l'ambiance et les possibilités offertes par les fablabs Qu'est-ce qu'un fablab : http://fr.wikipedia.org/wiki/Fab_lab) !

En attendant plus de nouvelles du robot (du nouveau ce week-end), on parle de Reb'UT sur le site du Technistub : http://technistub.fr/?p=266

D'autres images lorsque tout cela sera monté sur les blocs moteurs !

Site Damengo : http://damengo.com/

C'est à ces éléments que je me suis intéressé dans un premier temps. Du fait du support cubique, les CDs seront inclinés sur la table de jeu, il est donc délicat de prévoir un système qui permette de s'en saisir à coup sûr par le côté.

Afin de les saisir correctement par le dessus, nous avons envisagé la possibilité d'utiliser un système de ventouse. En effet, les ventouses, de par leur souplesse, pourraient nous permettre d'agripper de façon sûre les éléments quel que soit le côté par lequel nous nous en approchons. Restait à définir quelle taille de pompe serait nécéssaire pour maintenir les éléments en position une fois pris par les ventouses.

C'est désormais chose faite grâce à Eric de l'electrolab  (www.electrolab.fr) qui nous a laissé faire des tests avec une petite pompe ASF Thomas et des ventouses qu'il avait en réserve.

La vidéo suivante montre comment on parvient à aspirer et maintenir en position un disque à l'aide de cette petite pompe. Les résultats sont très convaincants. Alimentée en 10V/300mA la pompe fourni une dépression suffisante pour maintenir le disque accroché à la ventouse, malgré le fait que nous n'utilisons qu'une seule ventouse. Il a fallu secouer le tout relativement fort pour que le disque se décroche. Le tenue pourrait être améliorée en utilisant plusieurs ventouses (au minimum deux pour maintenir le disque droit lors de la manipulation), et des ventouses de diamètre supérieur, ainsi que des tuyaux de plus gros diamètre pour améliorer la réactivité du système. Dans l'ensemble, cette méthode de manipulation semble prometteuse étant donné la forme des éléments à manipuler.

Vidéo : test pompe à vide

Une pompe similaire à celle utilisée pour les tests a été commandé ce week-end pour des tests plus approfondis.

La table de jeu représentera une île au trésor. De chaque côté du terrain, une zone représentant la cale du bateau. Cette année, différentes manières de marquer des points, soit en ramassant des trésors sur l'île, soit en dévoilant la carte au trésor, soit en allant chercher des messages dans des bouteilles à la mer.

Cette année, il est aussi possible d'avoir deux robots sur la table. Mais qui dit deux robots pour une équipe, dit quatre robots pendant le match donc nous avons intérêt à soigner notre stratégie d'évitement ! Il faut aussi penser à faire communiquer les deux robots entre eux ...

De prime abord, le règlement semble encore se compliquer par rapport à l'année dernière. Nous avons donc (re)lancé la machine ce week-end. Nous avons profité d'un moment tous ensemble sur Belfort pour commencer à réfléchir à la stratégie. Nous nous sommes aussi fixés des objectifs pour notre prochaine réunion (dans un mois). Cette année, nous allons tenter de mieux nous organiser pour être un peu moins "à l'arrache" ...

Niveau stratégie, nous aimerions avoir deux robots. Le principal serait chargé de la collecte des trésors sur la table. Le secondaire irai dévoiler les messages dans les bouteilles. Nous n'avons pas encore vraiment pensé à un système permettant de dévoiler la carte.

Niveau méca, il faut attendre la parution du règlement complet avant de se lancer dans la modélisation. Les pièces seront pour la plupart réalisées comme l'année dernière dans les ateliers Imap de l'UTBM. Cepandant, ZapS a déjà commencé à travailler sur la base roulante comme il l'explique dans le dernier article.

Niveau élec, Detapi voudrait continuer à travailler avec des moteurs pas à pas. C'est donc lui qui sera chargé des déplacements du robot secondaire. Nous allons pouvoir réutiliser la carte que nous avions l'année dernière (sans usb de préférence ). Ellé voudrait essayer de développer un bus de communication entre les cartes. Il voudrait également développer un système de débuggage qui permettrait de voir ce qui passe sur le bus.

Niveau info, Dyna va travailler sur l'asservissement du robot principal. Problème que nous n'avions pas l'année dernière puisque nous utilisions des moteurs pas à pas. De mon côté, je vais travailler sur le système de communication entre les deux robots.

Étant donné que cette approche est plus complexe à mettre en place et demande une précision de mise en place importante, nous avons eu l'idée de développer un systèmes de blocs moteurs le plus modulaires possibles, afin de pouvoir les réutiliser sans modification (ou en tout cas le moins possible) sur les robots des années suivantes, ou même sur des projets n'ayant rien à voir avec la coupe de robotique.

Outre le soin particulier à apporter au choix des moteurs (ne pas hésiter à surdimensionner), ainsi qu'aux instruments d'odométrie (roue codeuses présentant une résolution suffisante), il est vraiment important que la mécanique présente le moins de jeu et d'imprécision possible. En effet, même les meilleurs algorithmes ne pourront pas rattraper les erreurs causées par une mécanique trop flottante.

Le système à développer devait présenter les caractéristiques suivantes :

• Embarquer l'ensemble roue-moteur sur une même base facilement (dé)montable d'un bloc
• Permettre l'utilisation de codeurs incrémentaux indépendants
• Permettre un accès facile aux éléments pouvant nécessiter des réparations/remplacements (moteur, roues..)
• permettre la séparation des ensembles roue/moteur gauche et droit
• réduire au maximum les jeux

la facilité d'assemblage du bloc n'est pas un critère majeur, en effet, l'objectif est de disposer d'un bloc installable sans modification sur une base de robot.

nous avons chois d'utiliser ces moteurs car ils nous ont été conseillés par une autre équipe participant à la coupe, en ce qui concerne les codeurs incrémentaux, nous avons profité des soldes chez vicatronic.fr et investi dans une paire d'OEZ-1024-2MC (présentant une résolution de 1024 points/rotation). Concernant les roues, nous avons réutilisé les roues Lynxmotion que nous avons acheté pour le robot de l'an dernier.

La raison pour laquelle nous avons souhaité installer des codeurs indépendants des roues motrices, afin de détecter les cas de dérapage (afin de ne pas avoir d'erreur ur la position lorsque la roue tourne, mais que le robot ne se déplace pas). Ces codeurs viennent en complément des codeurs montés d'origine sur les moteurs. Les codeurs des moteurs vont nous permettre de réaliser l'asservissement en vitesse des moteurs, tandis que les codeurs indépendants vont permettre à l'IA du robot de connaitre sa position, afin de calculer des trajectoires (qui seront converties en consignes de vitesse pour la carte d'asservissement).

Dans les grandes lignes, l'assemblage final ressemblera à ceci :

La roue motrice est représentée en noir, et le moteur est monté orthogonal à l'axe de la roue motrice, et la transmission est assurée par une paire d'engrenages coniques (en vert). Le cylindre bleu représente le codeur externe, qui est monté sur un support pivotant (un ressort sera ajouté afin de le maintenir en contact avec la table).

Des captures d'écrans du modèle définitif seront postées bientôt en attendant la fabrication effective des pièces !