Robotique EUROBOT 2017 - Les Karibous

  • Auteur de la discussion Nadar
  • Date de début
K

K-lean (Oleg) (Ensim)

Apprenti
Salut nadar,

j'aime beaucoup votre base roulante et surtout votre jack !
C'est super cool que vous soyez avancés comme ça, j'espère que vous serez dans les temps pour le jour J :wink:
 
N

Nadar

Apprenti
K-lean (Oleg) (Ensim) a dit:
Salut nadar,

j'aime beaucoup votre base roulante et surtout votre jack !
C'est super cool que vous soyez avancés comme ça, j'espère que vous serez dans les temps pour le jour J :wink:
Cliquez pour agrandir...
Merci @K-lean :-D

Mais honnêtement, on est avancé en modélisation, mais vraiment, mais alors vraiment pas du tout en réalisation :-D:-D Pour faire simple, je suis devenu papa entre temps :smt060 et il faut dire que le robot a pas beaucoup avancé à mon niveau ( elec + code ) . Et niveau méca, mon collègue a terminé aujourd'hui une grosse partie mais on commence à fabriquer que la semaine prochaine ... Croisons les doigts :-D Bon aller, je mets deux photos de la modélisation pour le moment :
*old link*
*old link*
 
K

K-lean (Oleg) (Ensim)

Apprenti
Félicitations Nadar pour le petit (Kari)Bout ! Tu verras Ça a un comportement assez aléatoire et Ça ne se reprogramme pas :)

Bon courage pour le montage, je n'arrive pas à deviner l'ensemble des actions prévues mais je crois comprendre que les modules transverseront le robot ?
 
N

Nadar

Apprenti
K-lean (Oleg) (Ensim) a dit:
Félicitations Nadar pour le petit (Kari)Bout ! Tu verras Ça a un comportement assez aléatoire et Ça ne se reprogramme pas :)
Cliquez pour agrandir...
Mouahaha ! C'est tellement vrai !!! :lol::lol::lol:

K-lean (Oleg) (Ensim) a dit:
Bon courage pour le montage, je n'arrive pas à deviner l'ensemble des actions prévues mais je crois comprendre que les modules transverseront le robot ?
Cliquez pour agrandir...
En fait non. On s'est concentré sur l'acquisition des balles , et la sur la visualisation, il manque le bras avant et les palettes. Les balles sont stockées au centre du robot puis déposées dans la zone de départ dans notre robot secondaire ( en cours de conception ) qui fera le transfert vers la soute.

Pour les modules, on se contentera de les récupérer avec la pince pour les déposer dans la zone de départ.

On a voulu faire relativement simple cette année car on changeait pas mal de trucs par rapport à l'année dernière, et on était conscient qu'on aurait pas trop de temps ... Mais j'ai la chance d'avoir un stagiaire cette année au lab qui va s'occuper de mettre sur pied avec moi un soft pour générer une stratégie et une simulation de match sur processing et une librairie pour les déplacements de robots à moteurs pas-à-pas avec recalage bordure et évitement d'adversaire. Si tous va bien on documente l'ensemble dans quelques semaines et on profite de la coupe pour tester ça in-situ :lol: L'idée c'est de pouvoir offrir une solution relativement simple et exploitable pour les équipes que l'on accompagnera l'année prochaine au Lab mais également de s'en servir pour d'autres projets de robots :wink:
 
L

louloute30

Compagnon
Salut Nadar,

J'ai pas mal bossé sur la gestion des moteurs pas à pas, et je me dis que je peux peut-être t'apporter mon expérience.
Dans ta boucle, où tu utilises micros(), personnellement, je la modifierai un peu. Evidemment, la première fois, je l'avais fait de la même manière, mais avec le temps, j'ai pu réaliser certaines améliorations...
Mes drivers (en 1/4 ou 1/8 pas, je ne me souviens plus) et moteurs supportent des impulsions tous les 900ns (et non 1200), et de même, je peux me permettre de ne pas mettre de delaymicros(x) entre l'état haut et bas de l'impulsion envoyée. Cela n'est en rien si important, mais dans ce que je vais rajouter après, cela peut influer légèrement:
Pour les pas à pas, tu le sais autant que moi, on cherche à obtenir le meilleur compromis vitesse/tenue de route.
Et pour obtenir une parfaite qualité de déplacement, j'en ai déduit après de nombreux tests qu'il fallait que j'applique sur mes moteurs pile poil 900ns (à Vmax) entre 2 impulsions (à 4ns près), et non 924ns une fois, puis 904... puisque par moment, on peut interroger les capteurs, cela influant sur les délais.
Pour cela, j'ai utilisé l'expression équivalente à "if ((micros()-_lastTime) >=_Pa)" au tout dernier moment juste pour lancer l'impulsion, les conditions d'acc, de vitesse constante et décélération ainsi que tout calcul sont à éviter dans cette condition (y compris les capteurs).
Et enfin, l'expression "_lastTime = micros();", je la place tout comme toi dans cette dernière condition juste après l'impulsion envoyée qui chez moi peut durer parfois 4ns ou 8ns selon.
Bon, je chipote un peu, mais j'ai pu constater que chez mes robots, cela a sensiblement améliorer la tenue de route et la qualité de déplacement.

Après, utilisant des codeurs, j'ai finalement rendu, dans ma boucle, indépendant les impulsions envoyées à la roue gauche de celles envoyées à la roue droite. Ainsi les deux roues ne tournent pas (plus) systématiquement en même temps, et n'ont (peut être) même plus le même nombre d'impulsions puisque cela tient compte de la distance réelle parcourue, et non plus de celle théorique, et l'ordre de départ de n impulsions est rarement identique de celui obtenu à la fin.
Avec ce principe, un robot pas à pas obtient les mêmes comportements de déplacement qu'un robot en moteur cc, ajouté que les déplacements circulaires sont tout simplement plus facile, et peut être un chouia plus propre théoriquement, reste à voir sur un robot similaire, si cela serait vérifié, ce que j'ai hâte de faire prochainement dans mon nouvel atelier... (encore quelques mois de patience).

Après, je salue le travail de partage :smt038où le code est compréhensible "tout public" et facilement modifiable/paramétrable et sympa pour ceux qui sont à la bourre.:smt023

A bientôt, et au plaisir de voir les matchs !
 
N

Nadar

Apprenti
Salut Louloute ! Je savais que tu réagirais à ce post :wink:

Alors avant d'aller plus loin, il faut que j'explique pourquoi j'ai tenus à re-developper une librairie. En effet, depuis deux ans on utilisait la librairie accelStepper qui fonctionne super bien et qui permet de piloter plusieurs moteurs en même temps ( ou presque ... ) et d'appliquer des rampes d'accélération et décélération.

Or, on s'est rendu compte la semaine dernière en reprenant le code pour des longs trajets, que le robot avait tendance à tracer un "genre de S" plutôt qu'une ligne droite. En tripotant la lib, on a vu qu'effectivement, les deux moteurs ne démarrant pas en même temps ( 5us entre chaque environ ), cela avait un gros impact en fin de match sur notre position.

Donc on a décidé de se coder ça nous même depuis mardi !

Et puis, dernière précision : on tourne maintenant sur teensy 3.2 ( ARM ). Du coup ça carbure à mort ! Par exemple, en testant mon calcul de atan2 en double sur teensy 3.2, j'ai environ 40us de temps de calcul, contre pratiquement plus d'1ms avec mon ancien 2.0 ( un 32u4 ) ... Ce qui explique peut être un code un peu bourrin parfois ...

louloute30 a dit:
J'ai pas mal bossé sur la gestion des moteurs pas à pas, et je me dis que je peux peut-être t'apporter mon expérience.
Dans ta boucle, où tu utilises micros(), personnellement, je la modifierai un peu. Evidemment, la première fois, je l'avais fait de la même manière, mais avec le temps, j'ai pu réaliser certaines améliorations...
Mes drivers (en 1/4 ou 1/8 pas, je ne me souviens plus) et moteurs supportent des impulsions tous les 900ns (et non 1200), et de même, je peux me permettre de ne pas mettre de delaymicros(x) entre l'état haut et bas de l'impulsion envoyée. Cela n'est en rien si important, mais dans ce que je vais rajouter après, cela peut influer légèrement:
Cliquez pour agrandir...

En gros, tu supprime le délais c'est ça ? Car sur mes drivers, le _minPulseWidth est de 2uS ... Du coup, j'avais au début enlevé ce délais et les moteurs ne tournaient tous simplement pas ... ( peut être du à la vitesse du teensy 3.2 aussi ?)

louloute30 a dit:
Pour les pas à pas, tu le sais autant que moi, on cherche à obtenir le meilleur compromis vitesse/tenue de route.
Et pour obtenir une parfaite qualité de déplacement, j'en ai déduit après de nombreux tests qu'il fallait que j'applique sur mes moteurs pile poil 900ns (à Vmax) entre 2 impulsions (à 4ns près), et non 924ns une fois, puis 904... puisque par moment, on peut interroger les capteurs, cela influant sur les délais.
Pour cela, j'ai utilisé l'expression équivalente à "if ((micros()-_lastTime) >=_Pa)" au tout dernier moment juste pour lancer l'impulsion, les conditions d'acc, de vitesse constante et décélération ainsi que tout calcul sont à éviter dans cette condition (y compris les capteurs).
Cliquez pour agrandir...

Là je ne te suis pas : si tu fait tourner ton loop avec ton run() assez vite ( en gros plus vite que le temps entre deux pas ), pas de soucis ? (c'est ce que l'on fait depuis deux ans ... ) En fait, sur mon uC qui fait tourner cette lib, il n'y a que les déplacements et la lecture de quelques capteurs TOR. Le reste est géré par un autre uC, le tout relié en I2C. L'idée, c'est également de faire une autre librairie de lecture de capteurs couplée à celle-ci qui m'assure plusieurs choses, et principalement :
  • Que la lecture des capteurs ne se fait que quand le temps de reponse du capteurs est atteint
  • Que la lecture de plusieurs capteurs ne dépasse jamais une valeur définie ( donnée par le temps entre deux pas par exemple 8-) )
louloute30 a dit:
Et enfin, l'expression "_lastTime = micros();", je la place tout comme toi dans cette dernière condition juste après l'impulsion envoyée qui chez moi peut durer parfois 4ns ou 8ns selon.
Bon, je chipote un peu, mais j'ai pu constater que chez mes robots, cela a sensiblement améliorer la tenue de route et la qualité de déplacement.
Cliquez pour agrandir...

Yep ! Je suis d'accord sur le fait qu'une optimisation possible c'est de rapprocher le "if ((micros()-_lastTime) >=_Pa)" de la génération du pas. Je vais regarder ça ce weekend :wink:

louloute30 a dit:
Après, utilisant des codeurs, j'ai finalement rendu, dans ma boucle, indépendant les impulsions envoyées à la roue gauche de celles envoyées à la roue droite. Ainsi les deux roues ne tournent pas (plus) systématiquement en même temps, et n'ont (peut être) même plus le même nombre d'impulsions puisque cela tient compte de la distance réelle parcourue, et non plus de celle théorique, et l'ordre de départ de n impulsions est rarement identique de celui obtenu à la fin.
Avec ce principe, un robot pas à pas obtient les mêmes comportements de déplacement qu'un robot en moteur cc, ajouté que les déplacements circulaires sont tout simplement plus facile, et peut être un chouia plus propre théoriquement, reste à voir sur un robot similaire, si cela serait vérifié, ce que j'ai hâte de faire prochainement dans mon nouvel atelier... (encore quelques mois de patience).
Cliquez pour agrandir...

Alors, pour info, notre base roulante de cette année sera équipée de codeurs justement pour que l'on puisse tester ça mais après la coupe je pense car je n'aurais pas le temps de tout faire sinon :lol: Du coup, faudra que j'améliore tt ça . Mais l'idée principale de cette lib c'était surtout de régler les soucis que l'on avait avec Accelstepper et de pouvoir partager une lib simple pour les équipes qui débutent :wink:

louloute30 a dit:
Après, je salue le travail de partage :smt038où le code est compréhensible "tout public" et facilement modifiable/paramétrable et sympa pour ceux qui sont à la bourre.:smt023
Cliquez pour agrandir...

Hooo ! Ba merci :-D Je suis content que ce soit lisible car c'était vraiment l'intérêt, et surtout de pas utiliser des techniques de "vieux barbus codeurs fou" pour éviter de rebuter les jeunots à tripoter la lib :P Bon c'est pas fini ! J'ai encore beaucoup de taff et je vais commencer à compléter le wiki pour expliquer l'usage et les implémentations !

louloute30 a dit:
A bientôt, et au plaisir de voir les matchs !
Cliquez pour agrandir...
Pareillement ! Et merci pour ces conseils :wink:
 
N

Nadar

Apprenti
Salut !
louloute30 a dit:
Pour les pas à pas, tu le sais autant que moi, on cherche à obtenir le meilleur compromis vitesse/tenue de route.
Et pour obtenir une parfaite qualité de déplacement, j'en ai déduit après de nombreux tests qu'il fallait que j'applique sur mes moteurs pile poil 900ns (à Vmax) entre 2 impulsions (à 4ns près), et non 924ns une fois, puis 904... puisque par moment, on peut interroger les capteurs, cela influant sur les délais.
Pour cela, j'ai utilisé l'expression équivalente à "if ((micros()-_lastTime) >=_Pa)" au tout dernier moment juste pour lancer l'impulsion, les conditions d'acc, de vitesse constante et décélération ainsi que tout calcul sont à éviter dans cette condition (y compris les capteurs).
Cliquez pour agrandir...

ok : en me replongeant dans le code, j'ai compris ce que tu voulais dire :lol: Du coup, j'ai sortis les tests d'acc / cst /decc. C'est effectivement plus propre ! Je regarde aussi à faire les calcul de _q et _pa à la place de micros() dans step() afin de ne pas bloquer le uC "pour rien" :supz: Il faut que je regarde le temps que ça prend pour voir si c'est encore optimisable.

Merci encore pour tes remarques ! J'ai mis la nouvelle version sur Github à l'instant, et j'ai testé ce matin "vite fait" les fonctions "goTo" et "runGoTo" et ça à l'air de fonctionner :wink:
 
L

louloute30

Compagnon
Bonsoir,

Je n'ai plus grand chose à rajouter aux modif que tu as apporté sinon peut être dans le calcul acc et decé:
J'ai grotesquement remplacé les (lourdes) formules d'acc et donc de decc par des + et des -.
Ex:
Toujours après test, j'en ai déduit que mon robot pouvait démarrer à un temps entre impulsion d'environ 2200µs (Vmin) sans que cela soit préjudiciable au compromis vitesse/précision de déplacement. et comme indiqué, j'ai pu constater que Vmax était à 900µs entre impulsions.
J'ai pu voir que le robot encaissait aussi -50µs / impuls dans la phase d'acc et inversement +50µs dans la phase de décélération.
J'en ai déduit alors:
nbImpulseNécessaire_à_l'Acc=(2200-900)/50
Si nbImpul<nbImpulseNécessaire_à_l'Acc alors on est en phase d'acc, on diminue le tps d'attente entre 2 impul de 50µs
Si on a atteint 900, on plafonne à 900.
Et durant la phase de decc, on rajoute 50µs entre 2 impuls.
Tout ça en tenant compte que le trajet ait assez d'impulsion pour arriver à Vmax, sinon évidemment, il faut passer de la phase acc à dec à mi parcourt.
C'est vrai, là, c'est plus moche coté code mais, ça permettait juste de restreindre la quantité de calcul et libérer (encore) du tps au µproc.
Seulement, on s'éloigne nettement de la facilité de compréhension que ton code propose si un non avisé s’immisce dedans, et ce code sera très probablement utile qu'à ton robot, et moins fiable sur d'autres.
Je te laisse à décider si ces modif apporte ou non un plus au déplacement de ton robot. Mais comme on dit, si ça marche comme ça, pourquoi modifier.

Et voilà, comme tu l'as dit, tu pourras toujours gérer en plus les mouvements des actionneurs en même temps que la motricité du robot si ton Uc le permet.

De mon coté, j'avais aussi rajouté à la librairie sur les Goto(X,Y) les zones à ne pas y mettre les pieds, définies symboliquement selon deux catégories, par des zones rectangulaires, ou des zones en forme de cercle.
Ainsi, si la trajectoire la plus directe traversait un "rectangle/cercle interdit fixe (parois,base adverse...) ou mobile (robot adverse)", on passait par l'un des quatre points du rectangle, ou de même, par le point de rencontre entre les tangentes au cercle.
Cette partie du code était pour le moins vraiment intéressante. Avec ça, ma biblio était complète, et il n'y avait plus qu'à s'amuser sur la stratégie...
Rien que d'y penser, j'ai grand faim de retourner à la cdf !
 
Dernière édition:
N

Nadar

Apprenti
C'est amusant car, pour mon premier code, j'ai d'abord fait exactement comme tu l'indique ! Seulement, le code généré était loin d'être compréhensible, difficilement portable pour un autre robot, et surtout, le mouvement était loin d'être propre ( due peut être à mes drivers je penses ... ).

Du coup, j'ai fait quelques recherches et lu quelques thèses sur les rampes d'acc et de decc des moteurs pas-à-pas ( loin d'être aussi simple et trivial que je ne l'aurais pensé :lol::lol: ), puis je suis tombé sur le travail de Aryeh Eiderman qui proposait une solution simple n'utilisant pratiquement que des multiplications et additions ... J'ai donc décidé de porter ce travail pour mon algo.
Plus d'infos sur : https://github.com/LaMachinerie/Karibous-2017/wiki/Librairie-"Deplacement"
et sur : https://github.com/LaMachinerie/Kar...N/LIBRARIES/Deplacement/document/leibramp.pdf

Je suis plutôt satisfait du résultat pour le moment. Mais, j'ajouterais bien une variable pour une prochaine version qui autoriserait un calcul plus simple et plus rapide pour les uC moins puissants si on le désire ... Au moins, ce sera complet !

louloute30 a dit:
De mon coté, j'avais aussi rajouté à la librairie sur les Goto(X,Y) les zones à ne pas y mettre les pieds, définies symboliquement selon deux catégories, par des zones rectangulaires, ou des zones en forme de cercle.
Ainsi, si la trajectoire la plus directe traversait un "rectangle/cercle interdit fixe (parois,base adverse...) ou mobile (robot adverse)", on passait par l'un des quatre points du rectangle, ou de même, par le point de rencontre entre les tangentes au cercle.
Cette partie du code était pour le moins vraiment intéressante. Avec ça, ma biblio était complète, et il n'y avait plus qu'à s'amuser sur la stratégie...
Cliquez pour agrandir...

Justement, je me demandais si j'allais faire ça dans cette librairie ou dans une autre dédiée à la stratégie ... Pour l'instant je suis partis plutôt sur la deuxième hypothèse ... On verra bien si je vais au bout :D

louloute30 a dit:
Rien que d'y penser, j'ai grand faim de retourner à la cdf !
Cliquez pour agrandir...

Mais oui !!! Revient !! Ca manque de robot avec des moteurs pas-à-pas à la coupe :lol::lol::lol:
 
Dernière édition:
N

Nadar

Apprenti
Go pour le montage ! Une petite photo du pré-assemblage de notre robot :lol::lol: Plus d'images demain soir j'espère :wink:
296402IMG20170425194638.jpg
 
N

Nadar

Apprenti
Bon alors, grosse, grosse , grosse frayeur aujourd'hui :
Suite à un léger court circuit sur une de nos cartes en test, le régulateur de notre teensy s'est mis en vrac et a, je ne sais pas trop comment, dézingué le régulateur général de la carte ... Seul problème, on a pas compris tt de suite que c'était le teensy qui posait problème, et on a cru à un soucis sur le régulateur. Après remplacement du régulateur, celui-ci a LITTERALEMENT pris feu au démarrage ... la petite fumée et les flammes quoi ... J'avais jamais vu ça en 12 ans d'électronique ... Pourtant la carte était protégée, et le régulateur complètement neuf.

Donc on a décidé de changer une nouvelle fois le régulateur pour être sur du soucis ( et c'est la qu'on a compris que c'était le teensy qui posait problème ), et là tout a fonctionné correctement ( les protections et tout le barda ... ).

On penche donc pour un soucis qualité sur le second régulateur. Pour info on vous donne la ref : D24V10F5 de chez pololu. On va voir pour changer de composant avant la coupe pour éviter d'avoir le même soucis .:evil:
 
N

Nadar

Apprenti
On continue le montage du robot aujourd'hui ! Quelques photos :
 
Dernière édition:
K

K-lean (Oleg) (Ensim)

Apprenti
Ca a l'air joli... mais les pixels, j'aime pas
:sad:
 
K

K-lean (Oleg) (Ensim)

Apprenti
Ha ! C'est mieux !
Je vois mieux comment ça va fonctionner :wink:
 
V

Valentin (INSA Rennes)

Nouveau
Très très jolie cette couleur orange !
En attende de voir le reste ... :P
 
P

pwet

Nouveau
Très joli travail :)

Je suis curieux par rapport à votre système de détection par balise, il semble que vous utilisez des OPB720 qui ne fonctionnent qu'à 300 mm d'après la doc, y'a une astuce ? Ça me parait faible pour voir un adversaire.
Vous utilisez un collecteur tournant pour la connexion des lasers mais on dirait que la rotation est assurée par un servo, c'est une rotation continue ?
C'est quoi votre sentiment rapport à ce système, ça répond à vos attentes ?
 
N

Nadar

Apprenti
pwet a dit:
Très joli travail :)
Cliquez pour agrandir...
Merci !
pwet a dit:
Je suis curieux par rapport à votre système de détection par balise, il semble que vous utilisez des OPB720 qui ne fonctionnent qu'à 300 mm d'après la doc, y'a une astuce ? Ça me parait faible pour voir un adversaire.
Cliquez pour agrandir...
Il y a une astuce en effet ! Du réflecteur sur les balises que l'on pose sur l'adversaire. Tu double pratiquement la distance de détection et au moins tu sais que ce que tu détecte, c'est bien la balise ( ... et pas un arbitre par exemple ... :lol: )
pwet a dit:
Vous utilisez un collecteur tournant pour la connexion des lasers mais on dirait que la rotation est assurée par un servo, c'est une rotation continue ?
C'est quoi votre sentiment rapport à ce système, ça répond à vos attentes ?
Cliquez pour agrandir...
Bon alors, je vais être honnête, en l'état, je voulais juste tester les OPB avec ce prototype et utiliser un servomoteur continu et capteur hall pour calculer la vitesse. C'était plus simple de reprendre cette idée car elle était proche de celle de l'année dernière, donc moins de conception pour faire mes tests. Par la suite, je voulais faire un truc plus compact avec un mini moteur pas à pas ... Sauf que ... On a tellement pris de retard, que l'on a décidé d'utiliser la solution telle quelle sans modif, et sans rotation continue pour utiliser le même code que l'année dernière , et j'ai seulement pu tester hier pendant une petite demi-heure ( Ouais ... on est vraiment , genre grave à la bourre cette année :lol::lol: ). Mes premières impressions :
  • Ca fonctionne vite est bien
  • Ca a pas l'aire d'être perturbé par la lumière extérieure
  • C'est hyper directif
  • Sans les balises, on détecte à 300 environ voir moins, avec les balises je suis monté à 600, donc super.
  • C'est pas super chère, et c'est simple à utiliser donc ça me convient !
  • Ca remplace avantageusement mes Sharp d'il y a 3 ans et mes Sick des deux dernières années pour le moment
  • C'est très petit et facile à placer, et le câble est bien flexible, donc easy à positionner .
Suite la semaine prochaine en essai sur une vrai table ... On verra bien après la coupe aussi :lol: Peut être que je dirait : "Les OPB, plus jamais " ha ha ha !
 
N

Nadar

Apprenti
Quelques news très rapidement ( et je retourne coder :D )
Depuis, la détection adverse est activée et utilisable, la vitesse à été multipliée par 3 et des optimisation de déplacement et d'actionneurs ont été fait. Malheureusement, on avait la table que mardi et plus d'accès depuis, donc on ferra les réglages à la coupe :lol: Et puis je crois qu'on a filmé nos pires essais aussi ! Mais c'est instructif au moins ! Bon ... je retourne sur mon code et sur le second ( oui oui, il y a "normalement" un second robot :lol::lol: ).
 
K

K-lean (Oleg) (Ensim)

Apprenti
Attention vous avez un module mono devant votre depose des balles
 
K

K-lean (Oleg) (Ensim)

Apprenti
C'est très propre comme deplacement !
 
L

louloute30

Compagnon
Salut,
Belle machine. (Les couleurs sont chouettes, et ça fait son travail)
Les recalage bordures, c'est à l'ultra son ? Le robot n'a pas l'air de toucher les bords, sauf erreur de ma part.
 
N

Nadar

Apprenti
louloute30 a dit:
Salut,
Belle machine. (Les couleurs sont chouettes, et ça fait son travail)
Cliquez pour agrandir...
Merci !
louloute30 a dit:
Les recalage bordures, c'est à l'ultra son ? Le robot n'a pas l'air de toucher les bords, sauf erreur de ma part.
Cliquez pour agrandir...
C'est de l'infrarouge. La distance de détection est très courte ( 1cm ). La procédure c'est de reculer jusqu'à détection de la bordure, puis ensuite je recul contre la bordure sans détection. Les capteurs sont des OPB716Z. C'est sensé être utilisé pour remplacer les switchs. Je voulais tester ça cette année . Pour l'instant j'en suis content.
 
K

K-lean (Oleg) (Ensim)

Apprenti
Pas bête ton truc du capteur IR, mais j'ai tellement pas de bons souvenirs de l'éclairage...
 
N

Nadar

Apprenti
K-lean (Oleg) (Ensim) a dit:
mais j'ai tellement pas de bons souvenirs de l'éclairage...
Cliquez pour agrandir...
Ha bon ? Il y a des soucis d'éclairage à la coupe ? :smt021:lol::lol:
Effectivement, je suis impatient de tester ça en match ! En vrai on ne s'en sert que au début du match et pour un recalage en bordure de dépose. Mais on active la détection à environ 2 cm du bord, donc on espère être pas trop brouillé. Ensuite, on a fait des tests avec des spots Led et simplement avec la lumière du soleil : vu leur montage, les capteurs sont très sensibles à une lumière rasante, mais à partir de 20° Tout rentre dans l'ordre.

Comme je ne crois pas qu'ils vont placer un spot rasant sur la table à 2cm du bord, j'ai bon espoir :lol::lol: Réponse à la coupe !

Nota : bon sinon, on a prévu une solution de secours à base de switchs :wink:
 
Pour répondre, connectez ou inscrivez vous.
Haut