Robot Coupe 2013 - Space Crackers

[romain_cvra]

Salut,

Fonctionne bien ton canon il a l'aire bien précis!

Pourquoi un barillet à 4 positions?
3 n'aurait pas suffit en mettant le capteur de couleur au même endroit que l’introduction?
Bon c'est vrais que ça change pas grand chose... sauf peut être qu'il aurait été possible de faire 1/3 de tour pour sortir une balle ou lieu de 3/4.
En tout cas il a de la gueule!!! Félicitation!

PS : Si c'est pas déjà fait...
Je te recommande vivement de mettre un capteur de présence à la position d'introduction de la balle et à la position de sortie de la balle.
Sa évite les blocages, simplifie le soft et permet d'être le plus rapide possible sans prendre de risque. (Sa évite les timer(le mal))

 

[MrDUS31]

Bonsoir les coupainss,

Merci pour les encouragements

Vous utilisez quoi comme capteur de couleur?

C'est un S6986 de Hamamatsu (de nombreuses équipes utilisent ça, on a piqué l'idée chez "je-sais-plus-qui")

Pourquoi un barillet à 4 positions?

Pour le diamètre de l'axe !!! Avec seulement trois balles, je n'aurait pas pus mettre le moteur à l'intérieur de l'axe du barillet.
Le principe de la Gatling est comme un pipeline de processeur : quand il est remplis, il traite une balle à chaque quart de tour alors qu'il faut trois quart de tour pour traiter une balle
En d'autres termes, cela permet de laisser à chaque fois 0,5s pour :
- la descente d'une balle,
- la détection de la couleur,
- le cycle poussé/retour de l'électroaimant (c'est lui qui limite la cadence).
Tout en ayant une cadence de tir de une balle toutes les 0,5s

Les blocages sont détectés par le PC qui pilote le moteur par PID (il y a un odomètre 600ppt au cul du moteur).
Pour ce qui est de l'optimisation de la cadence de tir, je pense qu'il va plutôt falloir calmer notre softeux pour pas qu'il augmente la cadence à 4 balles par secondes

Pour le plaisir des yeux, voilà un beau rendering du mini robot que j'ai fait pour le poster :

A+

Mr DUS

 

[romain_cvra]

Le principe de la Gatling est comme un pipeline de processeur : quand il est remplis, il traite une balle à chaque quart de tour alors qu'il faut trois quart de tour pour traiter une balle

Autant pour moi... Sa doit être une déformation dû à notre barillet.

Les blocages sont détectés par le PC qui pilote le moteur par PID (il y a un odomètre 600ppt au cul du moteur).
Pour ce qui est de l'optimisation de la cadence de tir, je pense qu'il va plutôt falloir calmer notre softeux pour pas qu'il augmente la cadence à 4 balles par secondes

En faite avec les capteurs supplémentaire que je te suggérais, il n'y aurait plus de cadence fixe...
Par exemple, la balle encours d’introduction met 0.2s de plus à entré (notre chère ami murphy)... pas de souci avec les capteurs car le barillet fait 1/4 de tour uniquement quand la belle est introduite.
Et c'est tout pareil avec l’éjection et le tire.
Dans tout les cas, la cadence sera maximisée. Bon par contre sa demande plus d’électronique...
Par expérience, il faut évité le plus possible de travaillé avec des délais...

La classe ton rendu!!!

 

[MrDUS31]

Salut Romain,

En faite avec les capteurs supplémentaire que je te suggérais, il n'y aurait plus de cadence fixe...

Oui oui, j'avais bien compris l'idée du tir "asynchrone". Mais avec le principe du pipeline c'est lourd à gérer je trouve : il faut que les quatre actions soient finies pour pouvoir faire tourner le barillet donc il faut quatre capteurs câblés en "AND". En dehors même des considérations "sureté de fonctionnement vs. loi de Murphy", je trouve que le temps gagné n'en vaut pas vraiment la peine.
La fiabilité du chargement (descente des balles depuis la zone de stockage) sera garantie par une mécanique "à-la-DUS"

Tiens, j'ai oublié de mentionner un gros avantage du barillet tournant : il remonte la balle de 5cm par rapport à la hauteur de chargement. Cela m'a permis d'augmenter le volume de stockage des balles alors que l'électroaimant (incliné à 45°) impose la hauteur de la balle par rapport au châssis du robot.
Au début, je voulais faire un canon pilotable en azimut, il fallait donc le charger par au dessus et la capacité de stockage était assez faible : 10 balles maxi... donc une seule assiette à la fois.
Dans la configuration actuelle, je peux stocker jusqu'à trois assiettes (et même quatre avec une astuce à base de clapet mobile, mais on le fera probablement pas )

A+

Mr DUS

 

[MrDUS31]

Salut à tous

La zone stockage est fabriqué et elle fonctionne pas trop mal
Je vous montre donc une vue de ma "goulotte colimaçon" :

La voila en action :

Il y a quand même un risque de coinçage de balle en haut
Je vais essayer d'améliorer ça, mais pour l'instant la capacité est plutôt de 20 balles maxi (les autres ne sont pas sûre de descendre).

D'ici 15 jours, le gros robot devrait faire ses premiers tours de roues

A+

Mr DUS

 

[louloute30]

Tu n'utilises le gros robot que pour les balles de ping pong ?

 

[MrDUS31]

Salut Louloute,

Non non, le gros robots s'occupera aussi des bougies et de la funny action !
Soit patient, je ne dévoile les actionneurs qu'après qu'ils aient été validés

A+

Mr DUS

 

[MrDUS31]

Salut à tous

Voilà quelques bonnes nouvelles de nos robots !

Le petit fait une tour de verre :

Et le gros commence à ressembler à quelque chose. La base roulante, avec les nouveaux moteurs (2x 100W ) :

Et avec la structure, de face ça donne ça :

Et de derrière :

Les premiers tours de roues sont pour bientôt, il faut lui rajouter les deux cartes électroniques (+ un plat de spaghetti de fillasse ) et le PC. D'ici la fin du mois on devrait pouvoir faire les premiers essais "full power"

A+

Mr DUS

 

[romain_cvra]

Yeah!!! Très chouette le design transparent! Il est super beau!

Et vous vous lancez dans la vision! C'est pour repérer les positions des éléments aléatoire au départ?

 

[MrDUS31]

Merci Romain

J'adore le polycarbonate, c'est beau et c'est ultra solide

Ouais, la webcam c'est pour les couleurs des bougies. Pour l'instant on ne prévoit rien de plus... mais les possibilités seraient énormes

 

[louloute30]

Merci Romain

J'adore le polycarbonate, c'est beau et c'est ultra solide

Ouais, la webcam c'est pour les couleurs des bougies. Pour l'instant on ne prévoit rien de plus... mais les possibilités seraient énormes

Chapeau pour la Web cam, par contre, je trouve cela "lent" à la détection: Après, je ne dis ça qu'en ayant observé une équipe qui fait ça depuis des années, et généralement, le robot met une à 2 sec à réagir. Peut être n'utilise-t-elle pas la bonne méthode...
Je veux bien ton ressenti dessus MrDus

 

[romain_cvra]

Je veux bien ton ressenti dessus MrDus

Voici un petit retour d'info sur la vision :

Au CVRA, on fait de la vision depuis la coupe 2010. En faite la vitesse dépend grandement de se que tu en fait...

On utilise la vision principalement pour déterminer où sont les objets aléatoire au début du match. (comme Mr DUS) Dans ce cas, il n'y a aucun délais car les traitement sont fait avant le début du match.
En plus, dans se cas, il n'y a pas besoin de faire de la reconnaissance de forme. Un moyennage de la couleur dans une zone prédéterminée est suffisant.

Cette année, notre caméra est dans une des balises fixe. Elle est basée sur un gumstix et son module caméra.
On va essayé (si on a le temps...) de faire en plus du traitement en cour de match pour déterminer si on objet et toujours à sa place ou non.
C'est une information très utile pour la stratégie, sa évite essayé de prendre un objet déjà pris.

A+

 

[MrDUS31]

Salut,

Je confirme ce que dit Romain. C'est exactement de cette manière que nous allons utiliser la caméra : une photo au début du match dans laquelle on connait à l'avance la position des bougies. Il suffit de détecter la couleur de chacune, sans aucune analyse d'image ni reconnaissance de forme.

Pour le temps de traitement, cela dépend surtout du matos... nous on a un Pentium à 1,6GHz... sur une Arduino ça prendrait sans doute un peu plus de temps

A+

Mr DUS

 

[louloute30]

Merci pour vos infos.

Par contre, j'ai pour souvenir que les éléments aléatoires sont posés après les 3min de préparation. Vous confirmez ?
Sinon, je tenterai bien de créer un petit clavier avec des boutons poussoirs pour que j'appuis durant la préparation sur les boutons qui correspond aux bougies à valider;

Puisque, comme l'année passée, je n'aurai que 2 boutons à actionner(l'un pour la couleur, et l'autre pour sélectionner entre 2 stratégies), et 2min50 à attendre...
Je me serai bien vu pd les 2min50 à tapoter sur le clavier pour indiquer les couleurs des bougies...

 

[MrDUS31]

Ah bah non, ce serait trop facile
D'abord tu prépare ton robot (ou tu poireaute en attendant l'autre équipe), là les arbitres demande si les robots sont prêt et dès cet instant il est interdit de communiquer avec les robots. Tu dois uniquement tenir la ficelle de démarrage pendant que les arbitres placent les éléments aléatoires.

Nous, on prendra la photo juste après le début du match (car il faut que le robot se tourne en direction du gâteau). La prise de vue devrait être instantanée et le temps de traitement sera "invisible" car fait en parallèle du programme principal.

A+

Mr DUS

 

[romain_cvra]

Ça c'est sûr! Trop facile si non.

Nous, on commencera à prendre des images et faire le traitement dès que le robot est prés à démarrer.
Le traitement et la prise d'image sera fait en boucle jusqu'au départ du match.
Et on garde uniquement les dernières valeurs. J'imagine qu'on devrait pouvoir faire au moins 4 traitement par seconde.

Nous, on prendra la photo juste après le début du match (car il faut que le robot se tourne en direction du gâteau).

En live sans arrêt du robot?

 

[louloute30]

Moi, j'aimais bien ma méthode .
Sachez entre parenthèses, que l'année passée, à chacune de nos apparitions, les arbitres plaçaient les éléments aléatoires en même tps qu'on plaçaient nos robots... (gain de tps sans doute)


Sinon, ta méthode MrDus implique que tu te centres au milieu de la table (à 1,5m du bord), je prends note, au cas où, par le plus grand des hasards, nous sommes face au SP, on évitera que le GR ait le tps de se placer .
Mais, dans ce cas, je ne comprends pas pourquoi tu n'as pas mis ta cam sur le coté du robot, ça t'aurai éviter un quart de tour. non ?

Je vais rester pour ma part sur les color sensors arduino... J'ai bien chercher qq capteur de couleurs industriels, mais,,, ça ne va pas, c'est un peut trop gros pour ce que je veux faire. Déjà que c'est le PR qui va s'occuper de ça, j'ai du bp, bp réduire la taille du périmètre pour atteindre la bougie du haut,

 

[MrDUS31]

Salut camarades

En live sans arrêt du robot?

En fait, je ne sais pas vraiment on a encore jamais fait de tests en conditions réelles !!!
Je me suis dit qu'a 25 images/seconde il n'y aurait pas vraiment besoin de temps d'arrêt.
Mais d'un autre côté c'est vrai que les webcams ne sont pas si rapide que ça et l'image "bave" facilement quand on bouge. Donc il est probable qu'on doivent marquer un petit temps d'arrêt...
Ou alors, on pourrait reprendre la méthode de romain : on fait plein de "mesures" avant le Start et on "vote" les résultats pour améliorer la fiabilité

Sachez entre parenthèses, que l'année passée, à chacune de nos apparitions, les arbitres plaçaient les éléments aléatoires en même tps qu'on plaçaient nos robots... (gain de tps sans doute)

C'est parce qu'en 2012 il n'y avais pas vraiment d'élément aléatoire
Le seul truc aléatoire était la position des CD noirs... qui n'avait absolument AUCUNE importance !
Je pense que personne ne s'est sérieusement soucié de les détecter puisqu'ils ne faisait pas perdre de points.
On l'avais signalé à l'organisation sur le forum de PlaSci mais ils n'ont pas voulu changer le règlement sur ce point.

Cette année, les éléments aléatoires ne compteront vraiment qu'en phase finale. En phase qualificative, ce qui compte c'est marquer un maximum de points. Comme la victoire ne rapporte quasiment rien, on pourrait très bien éteindre toutes les bougies sans se poser de questions
En 2002, 2003, 2010 et 2011 les éléments aléatoires avait une très grande importance (de 2004 à 2009, je ne sais pas, j'étais en "pause" )

A+

Mr DUS

 

[Jorus]

Salut les amis,

Ils sont encore au top tous vos robots !

Nous on va relever les couleurs au top départ.
Une seul mesure avec la lib OpenCV et une une vingtaine de lignes en Python.

L'arduino dédiée à la stratégie va interroger la carte mère associée à la webcam via un bus série. Si c'est bien calibré, c'est super fiable.

Mr DUS, si tu places ton robot par rapport à l'image au départ, tu es sur d'etre bien placé pour faire ton relevé. Par contre si tu fais d'abord un mouvement, faut pas se louper pour s'aligner pour le relevé.
Sauf si bien sûr en plus de la simple reconnaissance de couleurs, vous faites "un traitement d'image" visant à séquencer les bougies. La c'est la classe

++

 

[MrDUS31]

Salut les coupains

Dimanche dernier on a fait les premiers essais sur un terrain "officiel" (merci a Supaero )

On a pu valider le fonctionnement de la webcam : 5 minutes pour paramétrer la détection de couleur et hop, le robot enregistre toutes les positions en une fraction de seconde

Par contre, les premiers essais du canon en condition réelles ne sont pas très satisfaisant
Sur la vidéo suivante, on voit qu'un certain nombre de balles passent à côté :

L'azimut de tir n'est peut-être pas le meilleur possible, mais ce qui est gênant c'est surtout la variabilité de l'azimut. Le problème vient de la détection de la position "tir" du barillet de la Gatling. Actuellement, c'est un simple switch à lamelle qui est cliqué par le barillet. Or il ne "clique" pas exactement à la même position à chaque fois
Notre softeux va essayer d'améliorer le positionnement en utilisant le codeur optique du moteur. Il faudra régler le problème de l'initialisation à la mise ON, mais ensuite ce sera surement beaucoup plus précis (et même plus facile à piloter d'après le softeux !!)

Ensuite, une vidéo de l'extinction des bougies :

Pour l'instant uniquement celle du haut, les deux bras se gêne l'un l'autre
C'est juste une tête de vis qui coince, ce sera très vite corrigé (mais c'est systématique : à chaque que je ne modélise pas un truc en me disant "bof, ça sert à rien de le dessiner"... ça déconne une fois fabriqué )

A part ça, le petit robot est toujours en phase de débogage de l'asservissement de la propu. La vidéo ne devrait plus tarder

Petit bonus pour ceux qui consulte Usinages en plus du forum PlaSci, voilà mon secret pour des assemblages vissés dans la tranche des plaques avec une précision parfaite :

C'est tout bête : Il suffit d'avoir une fraiseuse de 1T6 avec une DRO et un foret de 2,5mm dans la broche en SA40 (oui, il y a une bonne marge de puissance )


A+

Mr DUS

 

[louloute30]

Salut MrDus,

Je vois que ça commence très sérieusement à prendre tournure tout ça...

Et comme tu le dis, rien de tel d'avoir une fraiseuse de 1T6 pour un forêt de 2,5mm ; Moi qui fait joujoux avec une simple perceuse à colonne... Cependant, à défaut d'en avoir une, j'ai la table de jeu :p

Je suis un peu étonné au final que tu n'as envisagé de destiner ton GR qu'aux bougies et aux cerises (et potentiellement aux cadeaux). Je pensais que tu allais nous inventer un truc qui aurait eu les capacités de tout faire !!!!!!! Bon, tu me diras, on ne voit qu'un coté de ton robot, qui sait, y a peut être un truc de l'autre coté encore bien caché...
Sinon, si j'ai bon souvenir, vous êtes bien plus en avance cette année que l'année passée, cela vous laisse largement le tps de gérer la balistique tel un tireur d'élite !
Hum, pourquoi ne pas placer le robot au milieu de la table, face au gâteau lors de l'envoi des cerises dans le conteneur ? Avez-vous prévu de tirer à partir de n'importe quel endroit de la table ?
Sinon, chapeau, belle conception, je vais presque dire, comme d'habitude, très soigné, rien n'est oublié, superbe !


Pour ma part, un petit mot, nos 4 robots vont faire leur premier tour de roue d'ici une dizaine de jour, en attente de la commande de courroies des roues motrices... Celle que j'avais étaient trop grande. Cela me laisse donc 10 jours pour l'électronique (enfin, l'assemblage d'une dizaine de arduino nano, atmega, et qq shield)... Petit plus, pour cette année, j'ai pensé à me munir de bp, bp d'ubec...

 

[MrDUS31]

Salut Louloute,

Désolé de te décevoir
Avec la réduction de gabarit, il était vraiment difficile de faire aussi les piles de verres avec le gros robot. Bon, je reconnais que je me suis fait plaisir avec mon système de traitement des cerises : il prend 60% du volume du robot alors que ça ne rapporte pas beaucoup de points.... mais j'avais tellement envie de faire un canon
Pour ce qui est des positions de tir, on a pas encore décidé. C'est en fonction de la position de départ car normalement on fera les cerises en premier. La vidéo correspond donc à la position du robot après le ramassage de deux assiettes en étant partis du "sud-est" du terrain.

Le côté droit du robot c'est le compartiment électronique. Pas d'actionneur miracle à cet endroit... mais il y a quand même des petits trucs que je n'ai pas encore montré

Par rapport à l'année passée, on a environ deux semaines d'avance sur le GR
Pour le PR, difficile à dire car l'année dernière je l'ai fait en 3 semaines... mais il était beaucoup moins perfectionné. On n'est pas en avance sur le PR, mais on reste assez confiants

Une info pour les Toulousains : on présentera notre robot ce week-end lors de la finale nationale des Trophées à la citée de l'Espace. Venez nous faire un petit coucou

A+

Mr DUS

 

[lapoutre]

C'est tout bête : Il suffit d'avoir une fraiseuse de 1T6 avec une DRO et un foret de 2,5mm dans la broche en SA40 (oui, il y a une bonne marge de puissance )
Mr DUS

je demande au modérateur la censure de ce post pour incitation à l'usage abusif de fraiseuse !

Perso, je fais tout mes trous de tranche à la perceuse à mains, ca me gonfle un max et avec la fatigue on dévie parfois.
La BF10 du local de "Sudriabotik" a trop de jeu (vis trapézoïdale dégueulasse) et elle est trop petite pour ce genre d'utilisation. De plus pour faire 2 trous successif il faut compenser l'erreur de la vis et il faut que l'étau soit bien parallèle avec l'axe de translation...
Est ce que qu'un a une solution intermédiaire?

Vincent

 

[MrDUS31]

Salut Vincent

Que veux-tu, on a tous nos perversions... moi j'adore les outils

Une solution que j'aimerai bien me bricoler pour l'année prochaine serait de percer les plaques avec la CNC
Il faudra faire une rainure dans le plateau (1cm x 40cm) pour pouvoir passer les plaques à travers et fabriquer un sorte d'étau qui bloque bien les plaques sur toute leur longueur. L'origine étant réglé sur une butée fixe et le mord fixe de l'étau, il ne reste plus qu'à préparer les fichiers de perçage

Sinon, avant d'avoir la Gambin, je m'étais fabriqué des gabarits de perçage avec ma première CNC. La série de trou à reproduire était faite (dans une chute quelconque) au fond d'une gorge de 6mm de large. J'emboitais la plaque à percer dans cette gorge et je la perçais en étant ainsi parfaitement guidé. Inconvénients : c'est vachement long de préparer les gabarits et ça gaspille de la matière

A+

Mr DUS

 

[goulou]

Salut,

Je vole la vedette à MrDus pour annoncer la première vidéo du PR en déplacement!

Certes mon terrain de jeu n'est pas très grand, mais c'est bien assez pour régler un PID!
Ici, le robot avance de 1m, puis fais demi-tour, avance de 50cm, retourne, recule de 50cm.... Il essaie un peu tout quoi! (marche avant/arrière, et rotations sur place)

A bientôt pour d'autres progrès...

Goulou

 

[MrDUS31]

Bravo Fred
Enfin, le p'tit bestiaux se montre en mouvement

Je suis pas du genre à mettre la pression mais j’attends avec grande impatience la construction d'une tour "en route"

A+

Mr DUS

 

[goulou]

La phase de réglage très chiants étant quasi terminée, je suis repassé en mode "codeur brutal", et pendant que certains débitent du polycarbonate, je débite du C! (*)
Patience, patience...

Goulou

(*) ne cherchez pas, il n'y a pas de contrepèterie... (en tous cas pas volontaire, et j'ai la flemme de chercher )

 

[Jorus]

Salut !

Belle méca !

[mode chieur on]C'est une idée ou il dévie sur trajectoire rectiligne ?[mode chieur off]

D'un coup une question me taraude : Pourquoi avoir re-développé l'asser/odométrie du petit robot. Celle du second robot de l'an dernier n'était pas satisfaisante ?

N'empêche c'est fou ce qu'on fait avec les AVR

 

[romain_cvra]

Hello,

Hey!!! Très chouette tout ca!
Merci pour les vidéos!!!

 

[MrDUS31]

Salut les amis

Avec plaisir Romain, avec plaisir
On attend les tiennes avec impatience

Oui Jorus, il ne va pas parfaitement droit...
Mais l'asserv est très chiant à régler car d'après Goulou les deux moteurs ne sont pas identiques au niveau du couple de démarrage (étonnant pour des maxon à 150€ pièce... mais il observe clairement une dissymétrie ).
Ce qui importe vraiment n'est pas qu'il aille parfaitement droit, mais qu'il sache où il est et qu'il atteigne les coordonnées demandées par la boucle "stratégie". Et là dessus, la précision est très bonne (i.e. suffisante pour ce que doit faire ce robot )

Le PR2013 n'a pas de codeur au cul du moteur (pas la place ) donc on ne peut pas utiliser le même principe que le GR2012 qui avait une carte LM629 pour l'asserv de vitesse en boucle rapide + l'odométrie indépendante pour l'asserv de position en boucle lente (par le PC).
Le PR2013 a seulement l'odométrie indépendante. Après, j'ignore si Goulou est parti d'un code Arduino existant pour écrire ses PID...

A+

Mr DUS