Après quelques modifs mécaniques et quelques programmations, OLEG était en théorie capable de marquer des points. Le meilleur moyen de s'en assurer c'est bien entendu par la pratique, sur une vraie table avec des objets à taille réel !
Pour cela je suis entré en contact avec une école d'Ingé du Mans, l'ENSIM, qui a accepté un échange ce matin. Nous avons pu discuter un peu stratégie et j'ai pu faire quelques essais sur table réelle.
Pour info l'ENSIM est une équipe qui a fait quelques très bon classement ces dernières années dont :
- 25ème en 2009 : http://www.youtube.com/watch?v=0kSwCshufP0
- Qualifié pour les phases finales en 2010 : http://www.youtube.com/watch?v=0K1jtNpQ-o4
Je suis très satisfait des essais de ce matin, d'une part parce que OLEG a marqué des points et d'autre part parce que j'ai rencontré quelques problèmes de réaction aux évenements. Pour ces essais, j'ai équipé OLEG d'une pince pour pouvoir prendre les lingots dans les totems. Sans plus attendre, voici une vidéo où OLEG marque 9 pts !
Problèmes rencontrés :
- Manque de puissance (parfois) à l'approche du point cible, ce qui fait que le robot n'avance plus (comme sur la vidéo)
- Détection des lingots au sol, l'ultra son est positionné trop bas
- Les pièces bloquent le robot car il roule dessus
- Mon programme de détection de collision (mis en place uniquement lorsqu'OLEG recule contre le totem) n'est pas efficace à chaque fois
Objectifs : Efficacité et Pédagogie
samedi 17 décembre 2011
vendredi 16 décembre 2011
Eviter l'adversaire
Le système d'évitement est obligatoire sur chaque robot participant à Eurobot depuis plusieurs années. Mais il y a pleins de façon d'éviter la collision avec l'adversaire : s'arrêter, reculer et le contourner sont les principales façons de faire. Beaucoup s'arrêtent, peu reculent et vraiment très peu contournent l'adversaire. C'est tout de même cette dernière façon de faire (contournement) qu'il nous faudra réussir à faire si nous voulons à coup sûr activer les deux bouteilles à la mer, même si nous croisons l'adversaire !
Repérer l'adversaire :
Mais gardons la tête sur les épaules, chaque chose en son temps. Avant de le contourner, il faut déjà voir l'adversaire ! Pour cela, nous allons bien entendu utiliser le capteur ultra-son que nous avons dans le kit mindstorm de base. Ce capteur à quelques inconvenients et quelques avantages. D'un côté il nous dira à quelle distance se trouve l'objet, de plus il a un cône de détection. C'est à dire que ce capteur capte sur plusieurs degrés devant lui, il faudra donc bien le positionner pour ne pas détecter les objets au sol mais si votre robot est suffisament petit, il se peut qu'un seul capteur vous suffise !
L'inconvenient c'est qu'il fonctionne avec des ultra sons et ces ondes ricochent. Si les objets ou robots devant ont une forme particulière ou sont vides, il se peut que le robot ne le détecte pas !
Mais bon, ce qu'il faut se dire c'est que les robots pleins de vide sont souvent assez limités et que les robots que l'on risque de croiser en allant à la seconde bouteille sont des robots qui vont à leur propre seconde bouteille et qui, théoriquement, seront assez développés et donc (j'espere) assez remplis ...
Donc revenons en à notre évitement et notre sonar. Le sonar peut détecter des objets à plusieurs mètres mais nous n'aurons pas besoin de savoir qu'il y a un objet à 1,5 m donc nous n'exploiterons pas les mesures à plus de DistSonarMax. A l'inverse, il nous faut définir une distance à laquelle nous interdirons au robot d'aller plus loin : DistSonarMin. Cette longueur dépendra de ce que vous voulez entreprendre :
- Simplement s'arrêter : la distance peut être très courte
- Tourner et contourner : la distance devra être plus grande
Ensuite, entre ces deux valeurs (DistSonarMax et DistSonarMin) vous ferez ce que vous voudrez, pour ma part j'agis sur la valeur max de puissance des moteurs. C'est à dire que plus l'objet se rapprochera, plus le robot ralentira. En dessous de DistSonarMin, je programmerais plusieurs types 'évitements', chaque type correspondant à une situation ou action particulière.
Atteindre la cible :
J'ai pu voir beaucoup de robots qui s'arrêtaient après avoir détecté l'adversaire à 20cm alors que le point qu'ils cherchaient à atteindre se situait à seulement 1cm devant ! Aussi je compare la mesure lue par le sonar à la distance de la cible (DistCibl) et si le robot est plus près de sa cible que l'objet détecté alors la vitesse sera diminuée mais le robot dépassera cette 'barrière'. Bien entendu à l'inverse, si la cible est plus éloignée, le robot lancera son cycle d'évitement.
Résultat :
Pour vérifier que le programme est bon et fonctionnel, j'ai programmé la séquence suivante :
- Le robot part du point A pour aller au point B puis revient en marche arrière en A
J'y ai inclus bien entendu la détection sonar; l'action d'évitement ici est le fait que le robot recule.
1/ Mon action est de placer un objet devant le point B pour constater que le robot recule puis revient à la charge.
2/ Ensuite je recule l'objet derrière le point B pour constater que le robot va avancer jusqu'à ce point avant de revenir au point A en marche arrière.
3/ Ensuite en appuyant sur Entrée on relancer le cycle, en ayant enlever l'objet pour voir la diffèrence de vitesse.
Vous m'excuserez la façon dont recule le robot, je l'ai programmé rapidement.
Les sons entendus me permettent de vérifier que le robot capte l'objet.
Repérer l'adversaire :
Mais gardons la tête sur les épaules, chaque chose en son temps. Avant de le contourner, il faut déjà voir l'adversaire ! Pour cela, nous allons bien entendu utiliser le capteur ultra-son que nous avons dans le kit mindstorm de base. Ce capteur à quelques inconvenients et quelques avantages. D'un côté il nous dira à quelle distance se trouve l'objet, de plus il a un cône de détection. C'est à dire que ce capteur capte sur plusieurs degrés devant lui, il faudra donc bien le positionner pour ne pas détecter les objets au sol mais si votre robot est suffisament petit, il se peut qu'un seul capteur vous suffise !
L'inconvenient c'est qu'il fonctionne avec des ultra sons et ces ondes ricochent. Si les objets ou robots devant ont une forme particulière ou sont vides, il se peut que le robot ne le détecte pas !
Mais bon, ce qu'il faut se dire c'est que les robots pleins de vide sont souvent assez limités et que les robots que l'on risque de croiser en allant à la seconde bouteille sont des robots qui vont à leur propre seconde bouteille et qui, théoriquement, seront assez développés et donc (j'espere) assez remplis ...
Donc revenons en à notre évitement et notre sonar. Le sonar peut détecter des objets à plusieurs mètres mais nous n'aurons pas besoin de savoir qu'il y a un objet à 1,5 m donc nous n'exploiterons pas les mesures à plus de DistSonarMax. A l'inverse, il nous faut définir une distance à laquelle nous interdirons au robot d'aller plus loin : DistSonarMin. Cette longueur dépendra de ce que vous voulez entreprendre :
- Simplement s'arrêter : la distance peut être très courte
- Tourner et contourner : la distance devra être plus grande
Ensuite, entre ces deux valeurs (DistSonarMax et DistSonarMin) vous ferez ce que vous voudrez, pour ma part j'agis sur la valeur max de puissance des moteurs. C'est à dire que plus l'objet se rapprochera, plus le robot ralentira. En dessous de DistSonarMin, je programmerais plusieurs types 'évitements', chaque type correspondant à une situation ou action particulière.
Atteindre la cible :
J'ai pu voir beaucoup de robots qui s'arrêtaient après avoir détecté l'adversaire à 20cm alors que le point qu'ils cherchaient à atteindre se situait à seulement 1cm devant ! Aussi je compare la mesure lue par le sonar à la distance de la cible (DistCibl) et si le robot est plus près de sa cible que l'objet détecté alors la vitesse sera diminuée mais le robot dépassera cette 'barrière'. Bien entendu à l'inverse, si la cible est plus éloignée, le robot lancera son cycle d'évitement.
Résultat :
Pour vérifier que le programme est bon et fonctionnel, j'ai programmé la séquence suivante :
- Le robot part du point A pour aller au point B puis revient en marche arrière en A
J'y ai inclus bien entendu la détection sonar; l'action d'évitement ici est le fait que le robot recule.
1/ Mon action est de placer un objet devant le point B pour constater que le robot recule puis revient à la charge.
2/ Ensuite je recule l'objet derrière le point B pour constater que le robot va avancer jusqu'à ce point avant de revenir au point A en marche arrière.
3/ Ensuite en appuyant sur Entrée on relancer le cycle, en ayant enlever l'objet pour voir la diffèrence de vitesse.
Vous m'excuserez la façon dont recule le robot, je l'ai programmé rapidement.
Les sons entendus me permettent de vérifier que le robot capte l'objet.
Système d'Evitement d'OLEG
Premiers tours de roues d'OLEG vers un point cible
Vous pourrez voir ci-dessous une video d'OLEG réalisant son déplacement, de sa position vers un point cible défini. Pour cet exemple, il va flirter avec les bords de la table (il le fait bien) avant de revenir à son point de départ. Avant de poster cette vidéo, j'ai bien entendu fait plusieurs essais pour régler les diffèrents paramètres pour avoir un déplacement assez fluide.
Correctifs :
Par contre j'ai du revoir la programmation de la correction de trajectoire. En effet, je trouvais que le robot ne revenait pas assez rapidement sur le bon cap dans les derniers degrés d'écart. Aussi j'ai rajouté une condition doublant le virage lorsque le cap du robot est à moins de 15° du cap à prendre. Maintenant le robot arrive presque droit vers la cible !
J'ai de plus du revoir la programmation de DistCibl car la racine carrée prend trop de temps à mon goût à être calculée. A la place de la racine carrée, je prend simplement la plus grande valeur (absolu) entre Yc-Yr et Xc-Xr. Désormais OLEG est un peu plus aléatoire dans son approche mais le temps de calcul permet à OLEG d'être plus réactif sur son positionnement. Car au final, à l'approche du point cible, cela ne change pas grand chose d'être à 5 ou 7 mm, par contre s'il faut 1 seconde de plus pour faire le calcul, il faudra aller beaucoup plus lentement à l'approche de la cible pour ne pas s'arrêter trop tard !
Résultat :
Pour résultat le robot parcours un peu plus de 1,6 m dont 2 rotations de plus de 270° et il revient assez précisement vers son point de départ (croix blanche). Il le fait en 20 sec sachant que la vitesse max n'est pas atteinte et que j'avais demandé à faire que l'approche des points intermediaires soit précise, donc lente. En bref : ça marche !
Correctifs :
Par contre j'ai du revoir la programmation de la correction de trajectoire. En effet, je trouvais que le robot ne revenait pas assez rapidement sur le bon cap dans les derniers degrés d'écart. Aussi j'ai rajouté une condition doublant le virage lorsque le cap du robot est à moins de 15° du cap à prendre. Maintenant le robot arrive presque droit vers la cible !
J'ai de plus du revoir la programmation de DistCibl car la racine carrée prend trop de temps à mon goût à être calculée. A la place de la racine carrée, je prend simplement la plus grande valeur (absolu) entre Yc-Yr et Xc-Xr. Désormais OLEG est un peu plus aléatoire dans son approche mais le temps de calcul permet à OLEG d'être plus réactif sur son positionnement. Car au final, à l'approche du point cible, cela ne change pas grand chose d'être à 5 ou 7 mm, par contre s'il faut 1 seconde de plus pour faire le calcul, il faudra aller beaucoup plus lentement à l'approche de la cible pour ne pas s'arrêter trop tard !
Résultat :
Pour résultat le robot parcours un peu plus de 1,6 m dont 2 rotations de plus de 270° et il revient assez précisement vers son point de départ (croix blanche). Il le fait en 20 sec sachant que la vitesse max n'est pas atteinte et que j'avais demandé à faire que l'approche des points intermediaires soit précise, donc lente. En bref : ça marche !
Déplacement d'OLEG
mardi 13 décembre 2011
Matelots ! Pagayez ferme ! Droit devant !
Désormais le robot sait tourner jusqu'à un angle assez précisement, maintenant il va falloir avancer pour aller jusqu'aux coordonnées du point Cible.
Il va ici falloir adapter sa vitesse en fonction de la distance qu'il reste à parcourir et corriger la direction en fonction de l'écart qu'il pourrait y avoir entre le cap du robot et le cap à prendre.
Adapter sa vitesse :
Il va y avoir trois modes :
- Le freinage : A mon avis la plus importante. Si nous arrivons trop rapidement, nous risquons de dépasser le point cible pendant le calcul et donc le robot ne s'en rendrait pas compte et ferait demi tour ensuite. Si nous arrivons trop doucement, nous perdrons des secondes très précieuses.
- L'accélération : Qui est une phase aussi importante mais qui sera surtout fonction de la réaction mécanique du robot durant cette phase. Ainsi une accélération trop grande pourrait faire patiner les roues motrices et faire démarrer le robot un peu n'importe comment.
- La vitesse constante : Qui est le fonctionnement du robot à vitesse maxi. Le but étant d'atteindre la plus grande vitesse de déplacement sans que cela ne pose d'autres problèmes. Ainsi si nous n'arrivons pas à corriger le cap du robot parce que nous allons trop vite, il faudra soit adapter la vitesse soit modifier la façon de corriger la trajectoire.
- La phase d'approche :
Je n'ai pas parlé de la phase d'approche qui se situe après la décélération. Cette phase permettra de corriger précisément le cap du robot et d'aller suffisament lentement pour s'approcher le plus précisement du point Cible.
A vitesse constante :
Dans mon cas, en terme de régulation de vitesse, il ne se passe rien dans cette phase sauf si Vmot est supérieur à Vmax, dans ce cas Vmot prend la valeur de Vmax. Vmax ne sera pas un paramètre prédéfini mais une constante fonction de ce que détecte le sonar, nous y reviendrons un peu plus tard. Par contre Vmax pourra prendre la vitesse Vmaxi si le sonar ne détecte rien.
L'accélération :
Pour ma part, j'ai programmé simplement la phase d'accélération par élimination. Si le robot n'est pas dans la phase finale et que Vmot est diffèrent de Vmax alors
La décélération :
Cette phase est importante pour éviter au robot de passer de Vmax à Vmini en une fraction de seconde et de provoquer ainsi un à coup inutile à l'approche de la cible. Le calcul à faire est le suivant :
avec DistCibl la distance séparant le robot de la cible ;
Vmaxi la vitesse max pouvant être atteinte si le sonar ne détecte rien ;
Vmini la vitesse mini définie pour la phase d'approche ;
DistFreinMax la distance définissant le début de la phase de décélération ;
DistApproch la distance définissant le début de la phase d'approche à Vmini ;
Ce calcul est un peu 'lourd' pendant la boucle de calcul de Vmot, aussi je remplace la partie finale par ConstanteDec car ce calcul dépend de paramètres défini au démarrage :
La phase d'approche :
Cette phase est simple à programmer puisqu'une fois que DistCibl est inférieure à DistApproch alors Vmot prend la valeur Vmini. Cependant au vu de ce que j'ai pu programmer, le robot ne s'arrêtera jamais aux coordonnées exactes de la cible, j'ai donc rajouté un paramètre, ApprCibl, qui sera défini avant chaque déplacement, qui permettra au robot de passer à l'action suivante une fois que DistCibl sera inférieure à ApprCibl. Ainsi le robot pourra atteindre des positions très précises, ou juste s'approcher d'un point de passage avant de prendre une autre direction.
Corriger la direction :
Rappelez vous, avant d'aller tout droit, le robot devra sortir du mode rotation. Dans mon cas, il faudra que AlphaRC, la diffèrence entre le cap du robot et le cap à prendre, soit inférieure à AlphaRotMax pour que le robot sorte du mode rotation et commence à avancer.
Ensuite, une fois que le robot avance, il faut qu'il corrige sa trajectoire pour aligner le cap du robot au cap à prendre. Pour cela, il faut, à partir de la valeur d'AlphaRC, provoquer un ralentissement sur la bonne roue du robot pour qu'il tourne, de plus il faut que ce ralentissement soit proportionnel à la valeur d'AlphaRC. Après plusieurs programmations concernant surtout le ralentissement provoqué sur la roue, je me suis finalement tourné vers quelque chose de très simple : Le bloc 'déplacer' !
Et désormais lorsque le robot rentre dans le mode 'avancer', Vmot donne la consigne de vitesse et AlphaRC donne la rotation à faire !
C'est très simple mais attention, ce n'est pas très efficace pour des valeurs au delà d'environ 50° d'écart du cap à tenir. Le robot n'avance quasiment pas car il se préoccupe surtout de tourner. La valeur n'est pas sûre car je n'ai pas fais les essais pour vérifier ce que je dis. Je n'ai pas non plus vérifier encore que ce problème ne vient pas de mon programme.
De plus, avec cette méthode, même si on gagne en temps de calcul, on perd en vitesse maxi car ce n'est pas aussi efficace que de mettre les moteurs à 100 et contrôler la puissance.
Il va ici falloir adapter sa vitesse en fonction de la distance qu'il reste à parcourir et corriger la direction en fonction de l'écart qu'il pourrait y avoir entre le cap du robot et le cap à prendre.
Adapter sa vitesse :
Il va y avoir trois modes :
- Le freinage : A mon avis la plus importante. Si nous arrivons trop rapidement, nous risquons de dépasser le point cible pendant le calcul et donc le robot ne s'en rendrait pas compte et ferait demi tour ensuite. Si nous arrivons trop doucement, nous perdrons des secondes très précieuses.
- L'accélération : Qui est une phase aussi importante mais qui sera surtout fonction de la réaction mécanique du robot durant cette phase. Ainsi une accélération trop grande pourrait faire patiner les roues motrices et faire démarrer le robot un peu n'importe comment.
- La vitesse constante : Qui est le fonctionnement du robot à vitesse maxi. Le but étant d'atteindre la plus grande vitesse de déplacement sans que cela ne pose d'autres problèmes. Ainsi si nous n'arrivons pas à corriger le cap du robot parce que nous allons trop vite, il faudra soit adapter la vitesse soit modifier la façon de corriger la trajectoire.
- La phase d'approche :
Je n'ai pas parlé de la phase d'approche qui se situe après la décélération. Cette phase permettra de corriger précisément le cap du robot et d'aller suffisament lentement pour s'approcher le plus précisement du point Cible.
A vitesse constante :
Dans mon cas, en terme de régulation de vitesse, il ne se passe rien dans cette phase sauf si Vmot est supérieur à Vmax, dans ce cas Vmot prend la valeur de Vmax. Vmax ne sera pas un paramètre prédéfini mais une constante fonction de ce que détecte le sonar, nous y reviendrons un peu plus tard. Par contre Vmax pourra prendre la vitesse Vmaxi si le sonar ne détecte rien.
L'accélération :
Pour ma part, j'ai programmé simplement la phase d'accélération par élimination. Si le robot n'est pas dans la phase finale et que Vmot est diffèrent de Vmax alors
Vmot = Vmot + CoeffAcc
où CoeffAcc sera un coefficient défini au fur et à mesure des essais.La décélération :
Cette phase est importante pour éviter au robot de passer de Vmax à Vmini en une fraction de seconde et de provoquer ainsi un à coup inutile à l'approche de la cible. Le calcul à faire est le suivant :
Vmot = DistCibl . (Vmaxi - Vmini) / (DistFreinMax - DistApproch) + Vmax - DistFreinMax . (Vmaxi - Vmini) / (DistFreinMax - DistApproch)
avec DistCibl la distance séparant le robot de la cible ;
Vmaxi la vitesse max pouvant être atteinte si le sonar ne détecte rien ;
Vmini la vitesse mini définie pour la phase d'approche ;
DistFreinMax la distance définissant le début de la phase de décélération ;
DistApproch la distance définissant le début de la phase d'approche à Vmini ;
Ce calcul est un peu 'lourd' pendant la boucle de calcul de Vmot, aussi je remplace la partie finale par ConstanteDec car ce calcul dépend de paramètres défini au démarrage :
(9) ConstanteDec = DistFreinMax . (Vmaxi - Vmini) / (DistFreinMax - DistApproch)
Ce qui nous donne :(10) Vmot = DistCibl . (Vmaxi - Vmini) / (DistFreinMax - DistApproch) + Vmax - ConstanteDec
La phase d'approche :
Cette phase est simple à programmer puisqu'une fois que DistCibl est inférieure à DistApproch alors Vmot prend la valeur Vmini. Cependant au vu de ce que j'ai pu programmer, le robot ne s'arrêtera jamais aux coordonnées exactes de la cible, j'ai donc rajouté un paramètre, ApprCibl, qui sera défini avant chaque déplacement, qui permettra au robot de passer à l'action suivante une fois que DistCibl sera inférieure à ApprCibl. Ainsi le robot pourra atteindre des positions très précises, ou juste s'approcher d'un point de passage avant de prendre une autre direction.
Corriger la direction :
Rappelez vous, avant d'aller tout droit, le robot devra sortir du mode rotation. Dans mon cas, il faudra que AlphaRC, la diffèrence entre le cap du robot et le cap à prendre, soit inférieure à AlphaRotMax pour que le robot sorte du mode rotation et commence à avancer.
Ensuite, une fois que le robot avance, il faut qu'il corrige sa trajectoire pour aligner le cap du robot au cap à prendre. Pour cela, il faut, à partir de la valeur d'AlphaRC, provoquer un ralentissement sur la bonne roue du robot pour qu'il tourne, de plus il faut que ce ralentissement soit proportionnel à la valeur d'AlphaRC. Après plusieurs programmations concernant surtout le ralentissement provoqué sur la roue, je me suis finalement tourné vers quelque chose de très simple : Le bloc 'déplacer' !
Et désormais lorsque le robot rentre dans le mode 'avancer', Vmot donne la consigne de vitesse et AlphaRC donne la rotation à faire !
C'est très simple mais attention, ce n'est pas très efficace pour des valeurs au delà d'environ 50° d'écart du cap à tenir. Le robot n'avance quasiment pas car il se préoccupe surtout de tourner. La valeur n'est pas sûre car je n'ai pas fais les essais pour vérifier ce que je dis. Je n'ai pas non plus vérifier encore que ce problème ne vient pas de mon programme.
De plus, avec cette méthode, même si on gagne en temps de calcul, on perd en vitesse maxi car ce n'est pas aussi efficace que de mettre les moteurs à 100 et contrôler la puissance.
dimanche 11 décembre 2011
Virez à Babord !
Encore quelques calculs et programmes et notre navire se débrouillera presque tout seul !
Maintenant que nous avons toutes les données, il n'y a plus qu'à les exploiter :
- nous commencerons à chercher à tourner jusqu'à atteindre le bon cap puis
- nous avancerons vers l'objectif en corrigant tout écart
Tourner :
Il éxiste plusieurs manières, pour tout système sur deux roues, de tourner :
- les deux roues avancent dans le même sens, l'une allant plus vite que l'autre
- une des deux roues est à l'arrêt
- les deux roues tournent dans le sens inverse, à même vitesse
La première méthode est plutôt utiliser pour se déplacer que pour tourner.
La seconde méthode est utile pour que la rotation soit très précise, on atteindra moins rapidement mais plus justement le cap désiré.
La troisième méthode permet au robot d'atteindre rapidement le cap désiré tout en restant sur place, limitant ainsi le risque de croiser un obstacle.
La troisième méthode est la plus utilisée mais personnellement j'utilise les deux dernières.
Dans un premier temps il faudra comparer AlphaR, le cap actuel du robot, à DirecCibl, le cap à prendre. Puis il faudra exploiter cette valeur pour trois cas de figure :
- La diffèrence entre AlphaR et DirecCibl, que j'appelle AlphaRC est très grande : la vitesse des roues sera inversée l'une de l'autre mais la vitesse sera grande. C'est le cas de figure orange ci-dessous.
- AlphaRC n'est pas très élevé mais suffisament pour qu'il faille tourner encore. La vitesse des roues est toujours inversée l'une de l'autre mais la vitesse est Vmini, la vitesse mini (puissance) donnée aux moteurs. C'est le cas de figure jaune.
- AlphaRC se rapproche de 0, il faut ralentir pour augmenter la précision. Dans ce cas, j'arrête le moteur qui avançait et réduis la vitesse du moteur qui continue de reculer. C'est le cas de figure vert.
Bien entendu il faut arrêter le robot lorsque le cap est atteint mais il y a peu de chance pour que le robot s'arrête exactement au moment où il détecte qu'il a atteint le cap. C'est pourquoi j'arrête la rotation quelques degrés avant d'arriver au cap. Ces quelques degrés sont définis par mesure et cela me permet d'arrêter réellement le robot au cap souhaité.
Sortir du mode 'Tourner' :
Une fois que vous savez tourner, il faudra avancer ou reculer. Mais est-ce vraiment toujours utile d'être exactement aligné sur DirecCibl ? NON, pas toujours. Si vous allez vous plaquer contre un bord pour prendre vos références ou activer un élément de jeu, alors la oui. Mais si vous tournez avant de vous rendre à un point de passage, peut être pouvez vous 'sortir' du mode 'Tourner' pour rentrer dans le mode 'Avancer' ? Il faut par contre dans ce cas là que votre mode 'Avancer' rattrape le décalage angulaire provoquer.
Il y aura donc deux modes 'Tourner', les deux fonctionnant de la même manière mais le premier permettra de tourner avant une action précise et le second permettra de tourner avant de se déplacer.
Démonstration :
Maintenant que nous avons toutes les données, il n'y a plus qu'à les exploiter :
- nous commencerons à chercher à tourner jusqu'à atteindre le bon cap puis
- nous avancerons vers l'objectif en corrigant tout écart
Tourner :
Il éxiste plusieurs manières, pour tout système sur deux roues, de tourner :
- les deux roues avancent dans le même sens, l'une allant plus vite que l'autre
- une des deux roues est à l'arrêt
- les deux roues tournent dans le sens inverse, à même vitesse
Méthode 1 Méthode 2 Méthode 3
La première méthode est plutôt utiliser pour se déplacer que pour tourner.
La seconde méthode est utile pour que la rotation soit très précise, on atteindra moins rapidement mais plus justement le cap désiré.
La troisième méthode permet au robot d'atteindre rapidement le cap désiré tout en restant sur place, limitant ainsi le risque de croiser un obstacle.
La troisième méthode est la plus utilisée mais personnellement j'utilise les deux dernières.
Dans un premier temps il faudra comparer AlphaR, le cap actuel du robot, à DirecCibl, le cap à prendre. Puis il faudra exploiter cette valeur pour trois cas de figure :
- La diffèrence entre AlphaR et DirecCibl, que j'appelle AlphaRC est très grande : la vitesse des roues sera inversée l'une de l'autre mais la vitesse sera grande. C'est le cas de figure orange ci-dessous.
- AlphaRC n'est pas très élevé mais suffisament pour qu'il faille tourner encore. La vitesse des roues est toujours inversée l'une de l'autre mais la vitesse est Vmini, la vitesse mini (puissance) donnée aux moteurs. C'est le cas de figure jaune.
- AlphaRC se rapproche de 0, il faut ralentir pour augmenter la précision. Dans ce cas, j'arrête le moteur qui avançait et réduis la vitesse du moteur qui continue de reculer. C'est le cas de figure vert.
Bien entendu il faut arrêter le robot lorsque le cap est atteint mais il y a peu de chance pour que le robot s'arrête exactement au moment où il détecte qu'il a atteint le cap. C'est pourquoi j'arrête la rotation quelques degrés avant d'arriver au cap. Ces quelques degrés sont définis par mesure et cela me permet d'arrêter réellement le robot au cap souhaité.
Sortir du mode 'Tourner' :
Une fois que vous savez tourner, il faudra avancer ou reculer. Mais est-ce vraiment toujours utile d'être exactement aligné sur DirecCibl ? NON, pas toujours. Si vous allez vous plaquer contre un bord pour prendre vos références ou activer un élément de jeu, alors la oui. Mais si vous tournez avant de vous rendre à un point de passage, peut être pouvez vous 'sortir' du mode 'Tourner' pour rentrer dans le mode 'Avancer' ? Il faut par contre dans ce cas là que votre mode 'Avancer' rattrape le décalage angulaire provoquer.
Il y aura donc deux modes 'Tourner', les deux fonctionnant de la même manière mais le premier permettra de tourner avant une action précise et le second permettra de tourner avant de se déplacer.
Démonstration :
Démonstration de la rotation d'OLEG
jeudi 8 décembre 2011
La Localisation, et après ?
Comment aller du point A au point B :
Vous avez programmé votre localisation, vous avez obtenu votre coefficients, votre robot peut donc se déplacer comme vous le souhaitez et il vous redonnera ses coordonnées X, Y et Cap à chaque instant.
Pour le moment, à part pour vous la raconter, cela ne sert à rien ! L'intérêt de la localisation c'est de représenter le robot à l'instant t sur une carte d'abscisse X et d'ordonnée Y mais aussi et surtout de représenter aussi sur cette carte un second point qui sera votre cible. L'objectif étant de s'y rendre !
Vous avez programmé votre localisation, vous avez obtenu votre coefficients, votre robot peut donc se déplacer comme vous le souhaitez et il vous redonnera ses coordonnées X, Y et Cap à chaque instant.
Pour le moment, à part pour vous la raconter, cela ne sert à rien ! L'intérêt de la localisation c'est de représenter le robot à l'instant t sur une carte d'abscisse X et d'ordonnée Y mais aussi et surtout de représenter aussi sur cette carte un second point qui sera votre cible. L'objectif étant de s'y rendre !
Dans le schémas ci dessus, vous avez obtenu par calcul Xr, Yr et AlphaR les coordonnées et cap du robot. Les coordonnées Xc et Yc du point cible seront définis avant le calcul. Il nous reste deux données que nous devons calculer :
- DirecCibl : L'angle ou cap à prendre
- DistCibl : La distance séparant le robot de la cible
Le cap à prendre :
DirecCibl représente le cap à prendre. C'est à dire que lorsque la diffèrence entre AlphaR et DirecCibl est nulle, le robot est sur la bonne voie ! Il va donc falloir calculer DirecCibl, rien de bien sorcier puisque nos premiers cours de trigonométrie nous donnent :
tan (DirecCibl) = (Yc - Yr) / (Xc - Xr)
donc
(7) DirecCibl = Arctan ( (Yc - Yr) / (Xc- Xr) )
La programmation de ce calcul est assez complexe (pour l'avoir tenté ...) si vous n'utilisez que les blocs du programme de base mais une fois encore c'est Hitechnic et son bloc Atan2 qui nous facilitera la tâche ! Il suffira de calculer les diffèrences de position entre la cible et le robot, de les entrer dans le bloc pour en récupérer la valeur de DirecCibl !
Le bloc atan2
La distance jusqu'à la cible :
La distance calculée ne doit pas servir à alimenter directement un bloc moteur qui avancera d'autant que la distance calculée. Cette valeur devra être utilisée pour définir l'alimentation des moteurs au travers de trois phases : l'accélération, le régime stationnaire et surtout la phase d'approche de la cible. Mais nous n'en sommes pas encore là.
Une fois encore ce sont nos cours de trigonométrie qui vont nous permettre de calculer DistCibl, plus particulièrement grâce au théorème de Pythagore :
(DistCibl)² = (Yc - Yr)² + (Xc - Xr)²
Donc
(8) DistCibl = RACINE CARREE ( (Yc - Yr)² + (Xc - Xr)² )
Malheureusement je n'ai pas trouvé de bloc Racine carrée cette fois-ci, il va donc falloir faire un calcul qui s'en approche. La méthode de Héron d'Alexandrie est une méthode d'approximation de la racine carrée :
(9) rn+1 = (rn + N / rn) / 2
La méthode consiste à 'boucler' plusieurs fois le calcul si dessus avec :
- N qui est le nombre dont on souhaite la racine carrée N = ( (Yc - Yr)² + (Xc - Xr)² )
- rn+1 qui est le résultat le plus proche de la racine carrée rn+1 = DistCibl
- rn qui était le résultat le plus proche lors de la boucle précédente
Pour ceux qui ne comprendraient pas, voici un exemple avec la racine carrée de 12 par exemple. Le résultat est 3,46410 ...
Dans ce cas, N = 12 et nous commencerons toujours avec r0 = 1.
* Donc à n = 0 nous obtenons r1 = (1 + 12 / 1) / 2 = 6,5
* Ensuite à n = 1 nous aurons r2 = (6,5 + 12 / 6,5) / 2 = 4,17307...
* Et encore à n = 2 nous aurons r3 = (4,17307 + 12 / 4,17307) / 2 = 3,5243...
* Enfin à n = 3 nous aurons r3 = (3,5243 + 12 / 3,5243) / 2 = 3,46461...
Il faudra faire autant de boucle que l'on souhaite s'approcher du résultat.
Dans notre cas, N = (Yc - Yr) ² + (Xc - Xr)² et nous commencerons avec r0 = 1, le dernier rn+1 sera DistCibl.
Cependant nous ne savons pas combien de boucle nous devons faire : trop et nous perdrons de la ressource, trop peu et le résultat ne sera pas juste.
Aussi il faut faire le calcul manuellement jusqu'à voir clairement quelle précision on obtient à chaque boucle. Je vous épargne ces calculs, voici mes résultats :
- Pour X = 3000 mm et Y = 2000 mm, les dimensions maxi de la table, il faudra faire 13 boucles pour être à 2% du résultat
- Pour X = 5 mm et Y = 5 mm, il faudra faire seulement 5 boucles pour être juste à quelques centièmes de millimètre.
La réponse se situe en réalité entre les deux et dépendra de notre besoin : A partir de quelle distance avons nous besoin d'être précis ? Personnellement, je pense que c'est à partir du moment où le robot doit décélérer que nous avons besoin d'avoir une information fiable. Pour mon cas, 800 mm, il faudra 11 boucles.
Ma boucle Racine Carrée
mercredi 7 décembre 2011
Obtention des Coefficients de Localisation
Bon, c'est bien beau tout ces calculs, ces conseils et ces théories mais je suppose que vous voulez voir que ça marche et quelle précision on obtient non ? Vous allez être servi !
Si vous le souhaitez, je peux vous envoyer mon bloc Calcul_XrYrAlphar mais je vous conseille d'essayer vous même la programmation, vous gagnerez du temps par la suite dans le cas où vous récupèreriez des valeurs étranges.
Mesures et calculs des Coeff :
Rappellez vous, pour déterminer AlphaR, Xr et Yr les coordonnées du Robot, je vous conseillai d'obtenir les coefficients CoeffDAngl et CoeffGAngl pour calculer AlphaR & CoeffDLong et CoeffGLong pour calculer Xr et Yr, le tout afin d'éviter le calcul du diamètre des roues et de l'entre roue qui vous amenerait à perdre du temps de calcul et gagner de l'imprécision sur vos résultats.
Ces coefficients sont les rapports :
1/ (Distance parcourue par chaque roue par incrément du codeur) : CoeffLong
2/ (Influence de chaque incrément du codeur sur le cap du robot) : CoeffAngl
1/ Pour obtenir les deux CoeffLong il faut faire parcourir une distance en ligne droite à votre robot et relever les valeurs des codeurs. Le calcul Distance/Incréments vous donne le CoeffLong de la roue correspondante.
2/ Pour obtenir les deux CoeffAngl il faut faire tourner votre robot dans un sens sur X tours et relever les valeurs des codeurs ainsi que l'angle total parcouru (2 tours de 360° = 720°). Ensuite il faut faire tourner le robot dans l'autre sens et faire les mêmes relevés. Le calcul est ici plus compliqué, je l'avais rédigé à partir de la méthode de la team AMARE, mais aujourd'hui j'utilise un fichier dans lequel je rentre mes mesures et cela me donne directement les coeff. Donc soit vous faites votre propre résolution du système soit je vous envoie mon fichier !
Dans les deux cas, pour relever les valeurs et pour éviter de faire avancer puis tourner votre robot manuellement, il vous faudra un programme. Encore une fois pour vous faire gagner du temps, je peux vous envoyer le mien ainsi que le fichier qui va avec ! Ci-dessous trois videos présentant ma méthode complète d'obtention des Coeff.
Résultats obtenus :
A l'heure actuelle, j'observe un écart pouvant aller jusqu'à 2 mm sur une longueur d'un mètre (ma table de salon n'est pas plus grande !) et une erreur de 6° sur 3600° soit environ 0,5° par tour.
Ce n'est véritablement qu'une fois sur table, après plusieurs mètres de déplacements et de rotations que je pourrais juger de l'efficacité de la localisation d'Oleg mais en tout cas c'est pour le moment très intéressant !
Si vous le souhaitez, je peux vous envoyer mon bloc Calcul_XrYrAlphar mais je vous conseille d'essayer vous même la programmation, vous gagnerez du temps par la suite dans le cas où vous récupèreriez des valeurs étranges.
Mesures et calculs des Coeff :
Rappellez vous, pour déterminer AlphaR, Xr et Yr les coordonnées du Robot, je vous conseillai d'obtenir les coefficients CoeffDAngl et CoeffGAngl pour calculer AlphaR & CoeffDLong et CoeffGLong pour calculer Xr et Yr, le tout afin d'éviter le calcul du diamètre des roues et de l'entre roue qui vous amenerait à perdre du temps de calcul et gagner de l'imprécision sur vos résultats.
Ces coefficients sont les rapports :
1/ (Distance parcourue par chaque roue par incrément du codeur) : CoeffLong
2/ (Influence de chaque incrément du codeur sur le cap du robot) : CoeffAngl
1/ Pour obtenir les deux CoeffLong il faut faire parcourir une distance en ligne droite à votre robot et relever les valeurs des codeurs. Le calcul Distance/Incréments vous donne le CoeffLong de la roue correspondante.
2/ Pour obtenir les deux CoeffAngl il faut faire tourner votre robot dans un sens sur X tours et relever les valeurs des codeurs ainsi que l'angle total parcouru (2 tours de 360° = 720°). Ensuite il faut faire tourner le robot dans l'autre sens et faire les mêmes relevés. Le calcul est ici plus compliqué, je l'avais rédigé à partir de la méthode de la team AMARE, mais aujourd'hui j'utilise un fichier dans lequel je rentre mes mesures et cela me donne directement les coeff. Donc soit vous faites votre propre résolution du système soit je vous envoie mon fichier !
Dans les deux cas, pour relever les valeurs et pour éviter de faire avancer puis tourner votre robot manuellement, il vous faudra un programme. Encore une fois pour vous faire gagner du temps, je peux vous envoyer le mien ainsi que le fichier qui va avec ! Ci-dessous trois videos présentant ma méthode complète d'obtention des Coeff.
Présentation et CoeffLong
CoeffAngl en manuel
CoeffAngl en auto
Résultats obtenus :
A l'heure actuelle, j'observe un écart pouvant aller jusqu'à 2 mm sur une longueur d'un mètre (ma table de salon n'est pas plus grande !) et une erreur de 6° sur 3600° soit environ 0,5° par tour.
Ce n'est véritablement qu'une fois sur table, après plusieurs mètres de déplacements et de rotations que je pourrais juger de l'efficacité de la localisation d'Oleg mais en tout cas c'est pour le moment très intéressant !
Robot Oleg pour ces essais
Dimensionnement des roues motrices et roues codeuses
mardi 6 décembre 2011
Difficultées et conseils pour la Localisation
En pratique, programmer et utiliser un robot Lego avec le kit de base Mindstorm afin qu'il vous donne ses coordonnées et son cap n'est pas chose facile !
Difficultées de Programmation :
- La brique ne fonctionne qu'avec des nombres entiers : il faudra prévoir dans quelles mesures on utilisera les diffèrents paramètres.
- La brique ne connait pas PI (heureusement on peut s'en passer)
- La brique ne connait pas SIN ou COS (heureusement il y a Hitechnic)
- La brique ne connait pas la fonction RACINE (pour l'instant vous n'en avez pas besoin mais ça va arriver)
Difficultées de Mécanique :
- Les servo moteurs ont des codeurs intégrés mais il y a beaucoup de jeu ce qui provoquera des écarts dus à ce jeu.
- Les roues sont molles et larges, elles s'aplatiront plus ou moins suivant l'accélération ou le freinage & le centre de rotation variera suivant la vitesse ce qui engendrera encore des écarts.
- Plus il y aura d'éléments mécaniques en LEGO de fixation entre les deux moteurs des roues Droite et Gauche, plus il y aura d'écarts sur le centre de rotation et sur le diamètre des roues.
- Le capteur intégré au servo moteur ne comprend que 360 points.
Faire les bons choix :
Autant en terme de programmation, avec un peu de persévérance, on finit par avoir quelque chose qui fonctionne correctement. De plus, si vous me le demandez gentiment, je vous envoie mon bloc de calcul Xr, Yr et AlphaR ... (version 1.05 ; il vous faudra de plus le bloc Hitechnic SinCos)
Mais ! Attention, toute votre imprécision se jouera sur votre mécanique. Ainsi vous n'obtiendrez jamais la précision des équipes finalistes si vous récupérez les données des servo moteurs avec les roues fournies dans le kit et si en plus vous faites beaucoup de déplacement à grande vitesse !
Une fois encore il faudra faire le choix de ce que vous êtes 'prêt' à investir en fonction de l'objectif que vous vous êtes fixés.
Mode 'Kit Mindstorm' :
- Vous participez occasionnellement et ne souhaitez pas investir : Vous pouvez utiliser les roues et les servos moteurs du kit Mindstorm mais il vous faudra faire peu de déplacement et à accélération douce. Vous pouvez aussi régulièrement vous 'recaler' contre une bordure pour réinitialiser X ou Y et AlphaR.
Mode 'Bricoleur' :
- Vous participez occasionnellement mais êtes prêt à mettre quelques € pour avoir une meilleure précision : Je vous invite simplement à positionner des joints toriques sur les 'poulies' du kit et de mettre ces nouvelles 'roues' sur les servomoteurs. Vous aurez des roues beaucoup plus petites, donc une vitesse maxi plus faible, mais une bien meilleure précision. Vous pouvez aussi achetez des roues Lego grandes et étroites. Dans cette configuration vous aurez une meilleure précision mais en cas de glissement de la roue (à l'acceleration ou en cas de choc) le robot se retrouvera décalé dans son calcul.
Mode 'Lego +' :
- Vous comptez bien participer plusieurs fois mais avez un budget limité et souhaitez conserver la brique Lego et son environnement : Dans ce cas je vous invite à investir environ 100€ dans 2 capteurs de rotation (un pour chaque roue) de chez Hitechnic (certifié par LEGO) et d'y fixer une petite roue étroite en direct ou par l'intermédiaire d'engrenages. Ici le type de roue (diamètre, largeur, adhérence) utilisé pour le déplacement sera bien dissocié du système de localisation, cela améliorera grandement votre précision et ne réduira en rien les performances mécanique de votre robot. Pensez à installer un système de ressort qui plaquera constamment les roues dites folles au sol.
A l'heure actuelle, Oleg se trouve dans cette configuration.
Mode 'Sans limite' :
- Vous avez un budget bien plus élevé que 100€ et vous n'êtes pas limité à l'environnement LEGO : Je vous invite à faire vos propres recherches car les possibilités sont très très larges et cela dépasse mon experience !
Difficultées de Programmation :
- La brique ne fonctionne qu'avec des nombres entiers : il faudra prévoir dans quelles mesures on utilisera les diffèrents paramètres.
- La brique ne connait pas PI (heureusement on peut s'en passer)
- La brique ne connait pas SIN ou COS (heureusement il y a Hitechnic)
- La brique ne connait pas la fonction RACINE (pour l'instant vous n'en avez pas besoin mais ça va arriver)
Difficultées de Mécanique :
- Les servo moteurs ont des codeurs intégrés mais il y a beaucoup de jeu ce qui provoquera des écarts dus à ce jeu.
- Les roues sont molles et larges, elles s'aplatiront plus ou moins suivant l'accélération ou le freinage & le centre de rotation variera suivant la vitesse ce qui engendrera encore des écarts.
- Plus il y aura d'éléments mécaniques en LEGO de fixation entre les deux moteurs des roues Droite et Gauche, plus il y aura d'écarts sur le centre de rotation et sur le diamètre des roues.
- Le capteur intégré au servo moteur ne comprend que 360 points.
Faire les bons choix :
Autant en terme de programmation, avec un peu de persévérance, on finit par avoir quelque chose qui fonctionne correctement. De plus, si vous me le demandez gentiment, je vous envoie mon bloc de calcul Xr, Yr et AlphaR ... (version 1.05 ; il vous faudra de plus le bloc Hitechnic SinCos)
Mais ! Attention, toute votre imprécision se jouera sur votre mécanique. Ainsi vous n'obtiendrez jamais la précision des équipes finalistes si vous récupérez les données des servo moteurs avec les roues fournies dans le kit et si en plus vous faites beaucoup de déplacement à grande vitesse !
Une fois encore il faudra faire le choix de ce que vous êtes 'prêt' à investir en fonction de l'objectif que vous vous êtes fixés.
Mode 'Kit Mindstorm' :
- Vous participez occasionnellement et ne souhaitez pas investir : Vous pouvez utiliser les roues et les servos moteurs du kit Mindstorm mais il vous faudra faire peu de déplacement et à accélération douce. Vous pouvez aussi régulièrement vous 'recaler' contre une bordure pour réinitialiser X ou Y et AlphaR.
Recalage à 36' de la Team BRICKBOT
Mode 'Bricoleur' :
- Vous participez occasionnellement mais êtes prêt à mettre quelques € pour avoir une meilleure précision : Je vous invite simplement à positionner des joints toriques sur les 'poulies' du kit et de mettre ces nouvelles 'roues' sur les servomoteurs. Vous aurez des roues beaucoup plus petites, donc une vitesse maxi plus faible, mais une bien meilleure précision. Vous pouvez aussi achetez des roues Lego grandes et étroites. Dans cette configuration vous aurez une meilleure précision mais en cas de glissement de la roue (à l'acceleration ou en cas de choc) le robot se retrouvera décalé dans son calcul.
Exemple de roue sur codeur (Team Amare)
Mode 'Lego +' :
- Vous comptez bien participer plusieurs fois mais avez un budget limité et souhaitez conserver la brique Lego et son environnement : Dans ce cas je vous invite à investir environ 100€ dans 2 capteurs de rotation (un pour chaque roue) de chez Hitechnic (certifié par LEGO) et d'y fixer une petite roue étroite en direct ou par l'intermédiaire d'engrenages. Ici le type de roue (diamètre, largeur, adhérence) utilisé pour le déplacement sera bien dissocié du système de localisation, cela améliorera grandement votre précision et ne réduira en rien les performances mécanique de votre robot. Pensez à installer un système de ressort qui plaquera constamment les roues dites folles au sol.
A l'heure actuelle, Oleg se trouve dans cette configuration.
Mode 'Sans limite' :
- Vous avez un budget bien plus élevé que 100€ et vous n'êtes pas limité à l'environnement LEGO : Je vous invite à faire vos propres recherches car les possibilités sont très très larges et cela dépasse mon experience !
lundi 5 décembre 2011
La Théorie de la Localisation
Avec le robot Lego Mindstorm, il est assez simple et rapide d'atteindre le niveau 1 puis le niveau 2 que j'ai défini précédement. Tout dépend bien entendu des moyens que vous avez pour le faire ! Ainsi les éleves primaire de Chaufour notre dame qui consacrent seulement quelques jours à programmer leur robot sont des balèzes pour leur age.
Mais pour, presque à coup sûr, atteindre le niveau 3, il faudra un minimum de localisation. Il faut donc un moyen pour connaître les positions en X, Y et Cap du robot.
Le moyen c'est de réussir à calculer chaque micro déplacement du robot depuis sa position précédente et d'en conclure les nouvelles positions X, Y et C. Il faudra donc faire quelques calculs !
Pour information, j'utiliserais tout au long de ce message les termes (Xr, Yr, AlphaR, ...) que j'utilise dans mes programmes. Je ne sais pas encore comment faire mais je tâcherais de mettre à votre disposition les blocs que j'ai réalisé, si ça peut vous servir...
Déterminer AlphaR, le nouveau cap du Robot :
Prenons pour commencer simplement l'angle Alpha du robot :
- vous connaissez AlphaP, le cap du robot la dernière fois que vous l'avez calculé
- vous ne connaissez pas dAlpha, l'angle duquel s'est tourné le robot
- vous ne connaissez pas AlphaR, le nouveau cap du Robot. AlphaR = AlphaP + dAlpha
Ce qui nous intéresse c'est donc de calculer dAlpha, je vous passe les calculs, le résultat c'est :
dG : est l'avancement de la roue gauche
EntrRoue : est la distance entre les roues
Il y a deux méthodes pour déterminer dAlpha :
- Calculer le diamètre des roues et la distance entre les roues ; faire tout un tas de conversion pour obtenir dAlpha en fonction de ces dimensions et des valeurs des codeurs
- Suivre la méthode de Thibaut Détriché (Team Amare) pour obtenir deux coefficients que vous associerez aux incréments de vos codeurs
Bien entendu j'ai commencé par la première méthode mais depuis que j'ai découvert cette seconde méthode, j'obtiens des résultats beaucoup plus précis et surtout si vous modifiez votre mécanique, vous gagnerez beaucoup de temps à reconfigurer vos calculs !
Je vous montrerais prochainement ma façon d'obtenir ces coefficients.
Avec ces coefficients vous obtiendrez dAlpha très rapidement :
CoeffDAngl & CoeffGAngl : Coefficient déterminé gràce à la méthode de Thibaut Détriché
dD : nombre d'incréments effectués par le codeur de la roue Droite
dG : nombre d'incréments effectués par le codeur de la roue Gauche
Voilà, vous avez dAlpha, AlphaP donc :
J'encourage vivement toute personne utilisant une mécanique et un support de programmation tel que Lego Mindstorm à utiliser ces deux formules (1) et (2) car :
- il y a très peu de calculs à faire : cela dégage de la ressource à votre centre de commande
- la méthode des coefficients prend en compte l'écrasement de la roue et non un diamètre théorique
Déterminer Xr et Yr les nouvelles positions du Robot :
Après la team Amare, c'est le ClubElek de l'Insa de Lyon qu'il faut remercier pour le calcul d'odométrie !
Si nous reprenons le schémas plus haut, nous recherchons :
Xp et Yp : Coordonnées Précédentes du Robot (connues)
dX et dY : Projection de dDepl sur les axes X et Y
Xr et Yr : Nouvelles coordonnées du Robot
La valeur de dDepl est la moyenne des déplacements des roues droites et gauche :
dAngl = (AlphaP + AlphaR) / 2
Si le calcul d'AlphaR vient après, vous pouvez aussi calculer de cette façon :
Ici dAngl ne va pas être compliqué à calculer par contre il vous faut déterminer la valeur des déplacements des deux roues.
Là encore il y a deux méthodes :
- Calculer le diamètre des roues ; faire tout un tas de conversion pour obtenir dDepl en fonction de ces dimensions et des valeurs des codeurs
- Suivre ma méthode pour obtenir deux coefficients que vous associerez aux incréments de vos codeurs
Là encore je vous conseille la méthode des coefficients :
Le principe c'est de positionner votre robot à un point de référence, de le faire avancer d'une longueur X et de relever les valeurs des codeurs des roues Droite et Gauche. Vous en déterminerez deux coefficients pour chacune des roues par le calcul suivant :
CoeffDLong : Coefficient associé au déplacement de la roue Droite
CoeffGLong : Coefficient associé au déplacement de la roue Gauche
Pour revenir à notre calcul, dès que nous avons ces coefficients, nous pouvons connaître dDepl :
dD et dG : incréments du codeur D ou G depuis la dernière mesure
Occupons nous maintenant de déterminer ce qui nous intéresse : dX et dY !
Par projection sur chaque axe on détermine :
Avec tout ceci vous avez maintenant Xr et Yr (voir formule (3) ) !
Mais pour, presque à coup sûr, atteindre le niveau 3, il faudra un minimum de localisation. Il faut donc un moyen pour connaître les positions en X, Y et Cap du robot.
Déterminer AlphaR, le nouveau cap du Robot :
Prenons pour commencer simplement l'angle Alpha du robot :
- vous connaissez AlphaP, le cap du robot la dernière fois que vous l'avez calculé
- vous ne connaissez pas dAlpha, l'angle duquel s'est tourné le robot
- vous ne connaissez pas AlphaR, le nouveau cap du Robot. AlphaR = AlphaP + dAlpha
Ce qui nous intéresse c'est donc de calculer dAlpha, je vous passe les calculs, le résultat c'est :
dAlpha = (dD - dG) / EntrRoue
dD : est l'avancement de la roue droitedG : est l'avancement de la roue gauche
EntrRoue : est la distance entre les roues
Il y a deux méthodes pour déterminer dAlpha :
- Calculer le diamètre des roues et la distance entre les roues ; faire tout un tas de conversion pour obtenir dAlpha en fonction de ces dimensions et des valeurs des codeurs
- Suivre la méthode de Thibaut Détriché (Team Amare) pour obtenir deux coefficients que vous associerez aux incréments de vos codeurs
Bien entendu j'ai commencé par la première méthode mais depuis que j'ai découvert cette seconde méthode, j'obtiens des résultats beaucoup plus précis et surtout si vous modifiez votre mécanique, vous gagnerez beaucoup de temps à reconfigurer vos calculs !
Je vous montrerais prochainement ma façon d'obtenir ces coefficients.
Avec ces coefficients vous obtiendrez dAlpha très rapidement :
(1) dAlpha = CoeffDAngl . dD - CoeffGAngl . dG
dAlpha : angle duquel s'est tourné le robotCoeffDAngl & CoeffGAngl : Coefficient déterminé gràce à la méthode de Thibaut Détriché
dD : nombre d'incréments effectués par le codeur de la roue Droite
dG : nombre d'incréments effectués par le codeur de la roue Gauche
Voilà, vous avez dAlpha, AlphaP donc :
(2) AlphaR = AlphaP + dAlpha
J'encourage vivement toute personne utilisant une mécanique et un support de programmation tel que Lego Mindstorm à utiliser ces deux formules (1) et (2) car :
- il y a très peu de calculs à faire : cela dégage de la ressource à votre centre de commande
- la méthode des coefficients prend en compte l'écrasement de la roue et non un diamètre théorique
Déterminer Xr et Yr les nouvelles positions du Robot :
Après la team Amare, c'est le ClubElek de l'Insa de Lyon qu'il faut remercier pour le calcul d'odométrie !
Si nous reprenons le schémas plus haut, nous recherchons :
(3) Xr = Xp + dX
Yr = Yp + dY
Xp et Yp : Coordonnées Précédentes du Robot (connues)
dX et dY : Projection de dDepl sur les axes X et Y
Xr et Yr : Nouvelles coordonnées du Robot
La valeur de dDepl est la moyenne des déplacements des roues droites et gauche :
dDepl = (dD + dG) / 2
L'angle (ou vecteur) de dDepl est la moyenne des angles avant et après du robot :dAngl = (AlphaP + AlphaR) / 2
Si le calcul d'AlphaR vient après, vous pouvez aussi calculer de cette façon :
(4) dAngl = AlphaP + dAlpha / 2
Ici dAngl ne va pas être compliqué à calculer par contre il vous faut déterminer la valeur des déplacements des deux roues.
Là encore il y a deux méthodes :
- Calculer le diamètre des roues ; faire tout un tas de conversion pour obtenir dDepl en fonction de ces dimensions et des valeurs des codeurs
- Suivre ma méthode pour obtenir deux coefficients que vous associerez aux incréments de vos codeurs
Là encore je vous conseille la méthode des coefficients :
Le principe c'est de positionner votre robot à un point de référence, de le faire avancer d'une longueur X et de relever les valeurs des codeurs des roues Droite et Gauche. Vous en déterminerez deux coefficients pour chacune des roues par le calcul suivant :
Coeff = Distance parcourue par la roue / Valeur cumulée du codeur
CoeffGLong : Coefficient associé au déplacement de la roue Gauche
Pour revenir à notre calcul, dès que nous avons ces coefficients, nous pouvons connaître dDepl :
(5) dDepl = (CoeffDLong . dD + CoeffGLong . dG) / 2
Occupons nous maintenant de déterminer ce qui nous intéresse : dX et dY !
Par projection sur chaque axe on détermine :
(6) dX = dDepl . cos (dAngl)
dY = dDepl . sin (dAngl)
Avec tout ceci vous avez maintenant Xr et Yr (voir formule (3) ) !
dimanche 4 décembre 2011
Premières Stratégies 2012
Pour faire un bon robot pour participer à Eurobot, il n'y a pas besoin d'une machine de guerre avec les toutes dernières technologies, des caméras embarquées, des scaners lasers ... Pour faire un robot de compet' il faut maitriser ce que l'on fait, que le robot fasse ce que l'on programme ! On voit régulièrement des robots dits 'simple' arriver dans les phases finales. Exemple ici avec le Lycée Rascol en quart de finale en 2007 contre RCVA, il prend un objet et le 'balance' dans le panier. C'est simple, ça marche et en plus c'est fun !
Aussi pour 2012 je vais procéder par niveau, de sorte que si je n'arrive pas à faire le niveau x, je pourrais toujours me reposer sur le niveau x-1 m'assurant un minimum de points !
Niveau 1 : 3 points Au minimum un robot qui se déplace (et ne sait faire que ça) peut aller pousser le premier lingot près de la zone de point. C'est de cette manière que la plupart des équipes vont s'homologuer.
Niveau 2 : 8 points Un robot un peu plus complet (sait se diriger correctement /ou/ suit une ligne noire) ira jusqu'à la première bouteille au bout de la ligne noire.
Niveau 3 : 13 points Le niveau suivant est de pouvoir aller jusqu'à la seconde bouteille MAIS attention plus on avance dans la compétition plus on rencontre de bonnes équipes (si on gagne des matchs bien sûr). Et ces équipes chercheront aussi à activer la seconde bouteille ! Il y a un risque de croiser le robot adverse. Pour ce niveau, il faut donc non seulement réussir à détecter l'adversaire mais aussi l'éviter ! Beaucoup d'équipes ne développent pas ou peu le système d'évitement et leur robot recule et/ou s'arrête lorsqu'il croise l'adversaire. Pour atteindre ce niveau il faut valider que le robot sait où il se trouve ET qu'il peut éviter l'adversaire.
Possibilités pour les niveaux suivants :
Une fois ce niveau trois atteint il faudra se poser la question du "Que fait on après ?". Plusieurs possibilités :
- Soit il reste du temps à ce robot et vous lui redonner des choses à faire
- Soit il n'a plus le temps de rien faire et il vous faut un second robot pour réaliser d'autres tâches
Me concernant pour l'instant je n'en ai qu'un !
Et là les actions prendront vraiment un sens stratégiques !!
Diffèrentes possibilitées donc si vous souhaitez améliorer votre premier robot :
- Bloquer une bouteille adverse
Nécessite surement un actionneur mais seulement quelques secondes en plus sur le temps de parcours total : Prendre une pièce au passage que l'on lachera devant la bouteille de l'adversaire. Cela ne rapporte pas de point, cela n'est pas très fair play mais peut être obtiendrez vous les 10 pts de la victoire si cette pièce a empêché l'adversaire de prendre 5 pts !
- Vider le bateau adverse
Nécessite une bonne mécanique pour ne pas se coincer avec les objets, pas mal de temps en plus et potentiellement un actionneur pour élargir la largeur du robot : Une fois les 13 points atteints du niveau 3, dirigez vous en direction de la zone de point adverse, introduisez vous dans son bateau et ressortez un max d'objets dans la mer (zone bleue) ! Cela ne vous rapporte pas de points directement, mais si cela fonctionne bien, à vous les 10 pts de la victoire ! Même si cette action n'est pas interdite, attention à ne pas empêcher l'accès du bateau à votre adversaire sinon pénalité : -5pts !
- Découvrir la carte
Nécessite un actionneur, un bon reperage du robot et un bon système mécanique : Avant ou après avoir activé les bouteilles, vous pouvez aller décrocher le tissu sur la carte. Cela vous rapporte 5 pts mais à mon gôut cette opération n'est pas intéressante comparée aux deux autres précédements citées. Il y a beaucoup de déplacement pour aller devant la carte, l'orientation du support ne facilite pas le positionnement pour l'action et l'arrachement du tissu me semble incertain : Comment arracher le tissu ? Quel effort fournir ?
- Récolter des pièces
Nécessite un actionneur, un bon repérage du robot et un bon système mécanique : Avec une sorte de pince ou crochet, il doit y avoir un moyen pour prendre quelques pièces au sol et les rapporter dans son bateau. Là le résultat est incertain : Est-on sûr de retrouver des pièces ? Est-on sûr de retrouver le bateau ? Ne risque-t-on pas de gêner son second robot si on décide d'en faire un ? ...
- Prendre les lingos des totems
Nécessite un actionneur, un bon repérage du robot, un bon système mécanique : Avec une sorte de pince ou un bras, il doit y avoir moyen de prendre un lingot sur un totem et de le mettre dans le bateau. Personnellement c'est le système qui m'attire le plus car il est plus sûr : on a moins de chances de croiser l'adversaire en restant dans son coin, on marque plus de 13 points et il y a moins d'aléatoire sur les points à gagner en plus. De plus il n'y a aucune tactique cherchant à perturber l'adversaire ... Le risque ici est surtout de se désorienter à cause d'une pièce, dois je vous rappeler la loi de l'emmerdement maximale ?
Cycle potentiel si j'atteins le niveau 3 :
Je pense qu'il y a moyen de faire le cycle suivant en 90 sec avec un seul robot :
- Prendre un lingot sur le premier totem (15sec)
- Pousser le lingot devant le bateau ; lâcher le lingot du totem (15sec)
- Prendre un second lingot sur le premier totem (15sec)
- Lâcher le lingot du totem (15sec)
- Activer la première bouteille (15sec)
- Activer la seconde bouteille (15sec)
En 90 sec on peut atteindre 19 pts. Ce n'est pas exceptionnel vu ce que certaines équipes feront mais c'est l'objectif en terme de points que je me fixe (ne tient pas compte des points de résultat) !
-Multi balle :
Bon ensuite si vraiment le robot est super performant et qu'il n'y en a toujours qu'un seul, autant tout faire ! Prendre dans le totem, activer les bouteilles tout en bloquant l'adversaire, vider le bateau adverse, ... mais là il faudrait songer à faire un deuxième robot !
Et surtout je n'en suis pas là ...
Lycée Rascol à gauche et RCVA en noir
Comparaison de stratégies :
Mon point de vue est que pour gagner il faut être 'lean' (déformation professionnelle !), je m'explique : avoir un robot lean c'est avoir un robot qui rapporte beaucoup de points en peu de temps. En comparaison, un robot qui va à coup sûr pousser le premier lingot dans la zone de point et en plus activer une, voir deux bouteilles (3 actions pour 13 pts en 90 secondes) sera plus prolifique qu'un robot qui va 'chercher' à prendre un maximum de pièces au sol avant de les rapporter dans la zone. Imaginons que ce second robot arrive à prendre 8 pièces et pousse le lingot, il ne rapportera que 11 pts en 90 secondes. Peut être sera t il plus rapide que cela mais prendre 8 pièces en 8 actions augmentent les risques de rencontrer des 'paramètres' non désirés (rencontre de l'adversaire, une pièce se coince, ...). Et surtout si on compare les moyens pour mettre en oeuvre ces actions on devine que le premier robot n'a besoin que de se déplacer et le second par contre aura surement besoin d'un actionneur.
Les petits malins me diront : "Oui mais non on a deux robots !" Effectivement je ne tiens pas compte du nombre de robots autorisés (2) mais la méthode de décision est la même ! Presque toutes les équipes qui auront deux robots en auront un qui fera le rôle n°1 décrit, ce sera le plus petit parce que "ce qu'il fait est plus simple". Donc la question est : Allez vous travailler d'abord sur le 'gros' ou le 'petit' ? Par envie et par désir de réussite, presque tout le monde va chercher des idées pour le 'gros'. Pourtant s'il ne se déplace pas comme souhaité, c'est bien le petit qui vous rapportera vos points !! Donc on en revient toujours au même, avant de parler du 'gros', occupons nous de pousser ce premier lingot et d'activer au moins une bouteille.
Equipe Coffee Machine qui a d'abord travaillé sur le 'petit'
Application personnelle pour 2012 :Aussi pour 2012 je vais procéder par niveau, de sorte que si je n'arrive pas à faire le niveau x, je pourrais toujours me reposer sur le niveau x-1 m'assurant un minimum de points !
Niveau 1 : 3 points Au minimum un robot qui se déplace (et ne sait faire que ça) peut aller pousser le premier lingot près de la zone de point. C'est de cette manière que la plupart des équipes vont s'homologuer.
Niveau 2 : 8 points Un robot un peu plus complet (sait se diriger correctement /ou/ suit une ligne noire) ira jusqu'à la première bouteille au bout de la ligne noire.
Niveau 3 : 13 points Le niveau suivant est de pouvoir aller jusqu'à la seconde bouteille MAIS attention plus on avance dans la compétition plus on rencontre de bonnes équipes (si on gagne des matchs bien sûr). Et ces équipes chercheront aussi à activer la seconde bouteille ! Il y a un risque de croiser le robot adverse. Pour ce niveau, il faut donc non seulement réussir à détecter l'adversaire mais aussi l'éviter ! Beaucoup d'équipes ne développent pas ou peu le système d'évitement et leur robot recule et/ou s'arrête lorsqu'il croise l'adversaire. Pour atteindre ce niveau il faut valider que le robot sait où il se trouve ET qu'il peut éviter l'adversaire.
Equipe Wally qui voit l'adversaire, s'arrête mais n'évite pas
Possibilités pour les niveaux suivants :
Une fois ce niveau trois atteint il faudra se poser la question du "Que fait on après ?". Plusieurs possibilités :
- Soit il reste du temps à ce robot et vous lui redonner des choses à faire
- Soit il n'a plus le temps de rien faire et il vous faut un second robot pour réaliser d'autres tâches
Me concernant pour l'instant je n'en ai qu'un !
Et là les actions prendront vraiment un sens stratégiques !!
Diffèrentes possibilitées donc si vous souhaitez améliorer votre premier robot :
- Bloquer une bouteille adverse
Nécessite surement un actionneur mais seulement quelques secondes en plus sur le temps de parcours total : Prendre une pièce au passage que l'on lachera devant la bouteille de l'adversaire. Cela ne rapporte pas de point, cela n'est pas très fair play mais peut être obtiendrez vous les 10 pts de la victoire si cette pièce a empêché l'adversaire de prendre 5 pts !
- Vider le bateau adverse
Nécessite une bonne mécanique pour ne pas se coincer avec les objets, pas mal de temps en plus et potentiellement un actionneur pour élargir la largeur du robot : Une fois les 13 points atteints du niveau 3, dirigez vous en direction de la zone de point adverse, introduisez vous dans son bateau et ressortez un max d'objets dans la mer (zone bleue) ! Cela ne vous rapporte pas de points directement, mais si cela fonctionne bien, à vous les 10 pts de la victoire ! Même si cette action n'est pas interdite, attention à ne pas empêcher l'accès du bateau à votre adversaire sinon pénalité : -5pts !
- Découvrir la carte
Nécessite un actionneur, un bon reperage du robot et un bon système mécanique : Avant ou après avoir activé les bouteilles, vous pouvez aller décrocher le tissu sur la carte. Cela vous rapporte 5 pts mais à mon gôut cette opération n'est pas intéressante comparée aux deux autres précédements citées. Il y a beaucoup de déplacement pour aller devant la carte, l'orientation du support ne facilite pas le positionnement pour l'action et l'arrachement du tissu me semble incertain : Comment arracher le tissu ? Quel effort fournir ?
- Récolter des pièces
Nécessite un actionneur, un bon repérage du robot et un bon système mécanique : Avec une sorte de pince ou crochet, il doit y avoir un moyen pour prendre quelques pièces au sol et les rapporter dans son bateau. Là le résultat est incertain : Est-on sûr de retrouver des pièces ? Est-on sûr de retrouver le bateau ? Ne risque-t-on pas de gêner son second robot si on décide d'en faire un ? ...
- Prendre les lingos des totems
Nécessite un actionneur, un bon repérage du robot, un bon système mécanique : Avec une sorte de pince ou un bras, il doit y avoir moyen de prendre un lingot sur un totem et de le mettre dans le bateau. Personnellement c'est le système qui m'attire le plus car il est plus sûr : on a moins de chances de croiser l'adversaire en restant dans son coin, on marque plus de 13 points et il y a moins d'aléatoire sur les points à gagner en plus. De plus il n'y a aucune tactique cherchant à perturber l'adversaire ... Le risque ici est surtout de se désorienter à cause d'une pièce, dois je vous rappeler la loi de l'emmerdement maximale ?
Cycle potentiel si j'atteins le niveau 3 :
Je pense qu'il y a moyen de faire le cycle suivant en 90 sec avec un seul robot :
- Prendre un lingot sur le premier totem (15sec)
- Pousser le lingot devant le bateau ; lâcher le lingot du totem (15sec)
- Prendre un second lingot sur le premier totem (15sec)
- Lâcher le lingot du totem (15sec)
- Activer la première bouteille (15sec)
- Activer la seconde bouteille (15sec)
En 90 sec on peut atteindre 19 pts. Ce n'est pas exceptionnel vu ce que certaines équipes feront mais c'est l'objectif en terme de points que je me fixe (ne tient pas compte des points de résultat) !
Exemple de cycle
-Multi balle :
Bon ensuite si vraiment le robot est super performant et qu'il n'y en a toujours qu'un seul, autant tout faire ! Prendre dans le totem, activer les bouteilles tout en bloquant l'adversaire, vider le bateau adverse, ... mais là il faudrait songer à faire un deuxième robot !
Et surtout je n'en suis pas là ...
Choix de conception
Electronique :
En trois participations à la coupe de France de robotique avec Robotik2000, j'ai rencontré un grand nombre d'équipes dont les résultats ne correspondaient pas au temps passé ou à la technologie investie. Nous mêmes n'avions pas réussi à nous homologuer en 2007 lors du Tri des déchets, pourtant le robot savait tout faire à l'interieur, tri des canettes et bouteilles, stockage, vidange, ... Mais nous nous étions mis très (trop) tardivement sur le déplacement, nous avions une nouvelle carte électronique et un seul spécialiste pour la programmer. Des ressources donc risquées et très limitées comparé à l'importance de cet organe.
Etant seul pour démarrer ce projet, sans formation en programmation ni en electronique, il me fallait quelque chose d'existant dans le commerce, ayant fait ses preuves et si possible facile à programmer. Financièrement parlant il fallait que cela ne soit pas trop onéreux car je n'ai pas l'intention de rechercher des sponsors. Je vous passe le temps de recherche, au final mon choix s'est porté sur la brique LEGO Mindstorm !
Voilà, pour environ 200€ j'ai acheté un Kit Complet Lego Mindstorm dans lequel on retrouve la brique de programmation, le CDrom d'installation, 3 Servo-Moteurs, 4 Capteurs (1 capteur de son, 1 capteur d'ultra-son, 1 capteur de couleur et 1 capteur de contact) et des pièces de montage. Tout un arsenal pour commencer à faire mumuse en robotique !
Programmation :
Le très gros intérêt que j'ai trouvé à ce kit est la simplicité de programmation. En effet, là où beaucoup programment en language C (programmes en ligne), ici on programme en nxt-G, développé par National Instrument Labview, comme si on programmait en 'brique' lego ! Un bloc représente une action, vous pouvez configuré chaque bloc et enchainer les actions comme bon vous semble. Et en cas de bug ou de 'truc qui marche pas', on retrouve beaucoup plus facilement l'origine.
Mécanique :
Concernant les capteurs et actionneurs, le choix est déjà fait puisque je vais prendre des équipements fonctionnant avec la brique et principalement déjà fournis dans le kit.
Par contre, le kit offre assez peu d'élements longs et rigide pour que le robot soit suffisament rigide, précis et protégés des 'agressions' exterieures. Aussi je compte utiliser des plaques de plexiglas que je découperais et percerais au besoin de sorte d'obtenir une bonne rigidité. Le fait d'utiliser du plexiglas me permet aussi et surtout de permettre à tous de voir ce qu'il se passe dedans ! J'aurais donc un mix Lego / Plexi.
En trois participations à la coupe de France de robotique avec Robotik2000, j'ai rencontré un grand nombre d'équipes dont les résultats ne correspondaient pas au temps passé ou à la technologie investie. Nous mêmes n'avions pas réussi à nous homologuer en 2007 lors du Tri des déchets, pourtant le robot savait tout faire à l'interieur, tri des canettes et bouteilles, stockage, vidange, ... Mais nous nous étions mis très (trop) tardivement sur le déplacement, nous avions une nouvelle carte électronique et un seul spécialiste pour la programmer. Des ressources donc risquées et très limitées comparé à l'importance de cet organe.
Etant seul pour démarrer ce projet, sans formation en programmation ni en electronique, il me fallait quelque chose d'existant dans le commerce, ayant fait ses preuves et si possible facile à programmer. Financièrement parlant il fallait que cela ne soit pas trop onéreux car je n'ai pas l'intention de rechercher des sponsors. Je vous passe le temps de recherche, au final mon choix s'est porté sur la brique LEGO Mindstorm !
Kit Complet LEGO Mindstorm
Les capteurs et actionneurs reliés à la brique
Présentation des possibilitées du kit de départ
Programmation :
Le très gros intérêt que j'ai trouvé à ce kit est la simplicité de programmation. En effet, là où beaucoup programment en language C (programmes en ligne), ici on programme en nxt-G, développé par National Instrument Labview, comme si on programmait en 'brique' lego ! Un bloc représente une action, vous pouvez configuré chaque bloc et enchainer les actions comme bon vous semble. Et en cas de bug ou de 'truc qui marche pas', on retrouve beaucoup plus facilement l'origine.
Interface de programmation
Présentation de programmation
Mécanique :
Concernant les capteurs et actionneurs, le choix est déjà fait puisque je vais prendre des équipements fonctionnant avec la brique et principalement déjà fournis dans le kit.
Par contre, le kit offre assez peu d'élements longs et rigide pour que le robot soit suffisament rigide, précis et protégés des 'agressions' exterieures. Aussi je compte utiliser des plaques de plexiglas que je découperais et percerais au besoin de sorte d'obtenir une bonne rigidité. Le fait d'utiliser du plexiglas me permet aussi et surtout de permettre à tous de voir ce qu'il se passe dedans ! J'aurais donc un mix Lego / Plexi.
Un peu de transparence !
Présentation du projet OLEG
Historique de l'équipe :
Oleg participe pour la première fois à la coupe de France, cependant j'ai (Klean) déjà participé trois années consécutives en 2005 Bowling, 2006 Golf et 2007 Tri des déchets, lorsque j'étais étudiant.
Je compte bien utiliser ces experiences (bonne ou manvaise) afin d'atteindre les objectifs que je me suis fixé.
Objectifs d'Oleg pour cette année :
- Efficacité :
J'envisage de faire qu'Oleg soit un robot efficace par rapport à son coût, au nombre de membres dans l'équipe, et bien entendu par rapport au nombre de points marqués ! Le but principal est de montrer qu'on peut faire quelque chose d'efficace avec 'peu' !
- Pédagogique :
Je ne sais pas encore comment rendre mon projet pédagogique mais dans l'idée je voudrais réussir à transmettre :
- cette passion de la robotique aux plus jeunes
- ma méthode de gestion de projet pour que chacun atteigne les objectifs qu'il s'est fixé
"Simplicité = efficacité !" Voilà le maître mot pour atteindre mes objectifs, aussi je vais avancer à ma méthode : petits pas par petits pas !
Conditions de réalisations d'Oleg :
Pour atteindre ces objectifs, je me suis définis plusieurs critères. Oleg devra au final :
- être le plus aéré et transparent possible : que tout le monde voit ce qu'il se passe dedans
- être le plus simple en terme d'actionneurs et capteurs : 2 moteurs pour le déplacement ; 1 actionneur pour une action spécifique ; 2 capteurs pour le déplacement ; 1 capteur pour démarrage et Arrêt d'Urgence ; 1 capteur pour la détection de l'adversaire.
Voilà pour la définition du projet !
Oleg participe pour la première fois à la coupe de France, cependant j'ai (Klean) déjà participé trois années consécutives en 2005 Bowling, 2006 Golf et 2007 Tri des déchets, lorsque j'étais étudiant.
Je compte bien utiliser ces experiences (bonne ou manvaise) afin d'atteindre les objectifs que je me suis fixé.
Objectifs d'Oleg pour cette année :
- Efficacité :
J'envisage de faire qu'Oleg soit un robot efficace par rapport à son coût, au nombre de membres dans l'équipe, et bien entendu par rapport au nombre de points marqués ! Le but principal est de montrer qu'on peut faire quelque chose d'efficace avec 'peu' !
- Pédagogique :
Je ne sais pas encore comment rendre mon projet pédagogique mais dans l'idée je voudrais réussir à transmettre :
- cette passion de la robotique aux plus jeunes
- ma méthode de gestion de projet pour que chacun atteigne les objectifs qu'il s'est fixé
"Simplicité = efficacité !" Voilà le maître mot pour atteindre mes objectifs, aussi je vais avancer à ma méthode : petits pas par petits pas !
Conditions de réalisations d'Oleg :
Pour atteindre ces objectifs, je me suis définis plusieurs critères. Oleg devra au final :
- être le plus aéré et transparent possible : que tout le monde voit ce qu'il se passe dedans
- être le plus simple en terme d'actionneurs et capteurs : 2 moteurs pour le déplacement ; 1 actionneur pour une action spécifique ; 2 capteurs pour le déplacement ; 1 capteur pour démarrage et Arrêt d'Urgence ; 1 capteur pour la détection de l'adversaire.
Voilà pour la définition du projet !
Présentation d'Eurobot 2012 !
Bienvenue sur le blog du robot Oleg qui participera à la coupe de France de Robotique 2012 (Eurobot2012).
L'Ile au trésor !
Deux équipes s'affrontent sur une table de 2m sur 3m, une équipe rouge et une violette, composées de un ou deux robots autonomes.
Chaque équipe part du carré de sa couleur et doit gagner des points par l'intermédiaire de plusieurs actions :
- rapporter des pièces blanches (1 pts) et/ou lingots (3 pts) dans son bateau (zone marron de son côté)
- activer les 'bouteilles à la mer ' de sa couleur (5 pts)
- dévoiler la 'carte' (5 pts)
Après 90 secondes de match les robots s'arrêtent et les arbitres comptent les points !
Rappels :
- Présentation du theme 2012 : Treasure Island (Ile au trésor)
- Reglement complet en français : FormatPDF
L'Ile au trésor !
Deux équipes s'affrontent sur une table de 2m sur 3m, une équipe rouge et une violette, composées de un ou deux robots autonomes.
Chaque équipe part du carré de sa couleur et doit gagner des points par l'intermédiaire de plusieurs actions :
- rapporter des pièces blanches (1 pts) et/ou lingots (3 pts) dans son bateau (zone marron de son côté)
- activer les 'bouteilles à la mer ' de sa couleur (5 pts)
- dévoiler la 'carte' (5 pts)
Après 90 secondes de match les robots s'arrêtent et les arbitres comptent les points !
Table vide
Exemple en fin de match
Rappels :
- Présentation du theme 2012 : Treasure Island (Ile au trésor)
- Reglement complet en français : FormatPDF
Inscription à :
Articles (Atom)