K
Merci @K-leanSalut 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
Mouahaha ! C'est tellement vrai !!!Félicitations Nadar pour le petit (Kari)Bout ! Tu verras Ça a un comportement assez aléatoire et Ça ne se reprogramme pas
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.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 ?
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 partageoù le code est compréhensible "tout public" et facilement modifiable/paramétrable et sympa pour ceux qui sont à la bourre.
Pareillement ! Et merci pour ces conseilsA bientôt, et au plaisir de voir les matchs !
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).
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 !
Outch ! Effectivement ça pique :D J'ai mis une image plus grande :DCa a l'air joli... mais les pixels, j'aime pas
Merci !Très très jolie cette couleur orange !
Nous aussi ...En attende de voir le reste ...
Merci !Très joli travail
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 ...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.
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éeVous 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 ?
Ha ha ha ! Merci ! Oui on sait que ça nous gene. On a prévu de le dégager sur la droite en arrivant. C'est clairement pas la stratégie final !Attention vous avez un module mono devant votre depose des balles
Merci ! Ouaip ! On est assez content des déplacements, surtout sans codeurs ( pour le moment ...C'est très propre comme deplacement !
Merci !Salut,
Belle machine. (Les couleurs sont chouettes, et ça fait son travail)
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.Les recalage bordures, c'est à l'ultra son ? Le robot n'a pas l'air de toucher les bords, sauf erreur de ma part.
Ha bon ? Il y a des soucis d'éclairage à la coupe ?mais j'ai tellement pas de bons souvenirs de l'éclairage...
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?