Aller au contenu


Photo
- - - - -

Simulation TRR épreuves "Roulant" & "DLVV"


36 réponses à ce sujet

#1 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 09:11

Bonjour,

 

En 2019, j'avais développé un petit simulateur en python pour préparer la course TRR, et pour tester mes algorithmes de contrôle du robot. Il permettait aussi d'estimer ses performances en avance de phase.

 

https://twitter.com/...Lyah2saNvxDi9HQ

 

La mini TRR 2022 se tient dans deux mois et la TRR 2023 se profile à l'horizon. C'est suffisant pour développer un nouveau simulateur et tester nos robots.

 

Mon propre robot roulant sera programmé en C/C++. Ce simulateur devra être capable d'exécuter le code de mon robot (et d'autres robots).

 

Je me demandais si un tel simulateur intéresse des membres. Qu'en pensez vous ?

 

Patrick.



#2 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 412 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 18 septembre 2022 - 09:31

Moi ça m'intéresse :)


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 


#3 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 020 messages
  • Gender:Male

Posté 18 septembre 2022 - 11:02

Il a l'air super ton simulateur ! Merci.

Cela m'intéresse, même si je ne présenterai pas de roulant mais un quadrupède, sur la grande piste, pour faire le grand tour.



#4 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 02:00

Bien ! Voyons où cela nous mène et commençons par la piste et quelques éléments graphiques !

 

Ci-dessous, le plan, la modélisation et le modèle 3D (STL). Quelques écarts minimes sur la longueur du premier et second secteurs rectilignes, que je ne parviens pas à corriger, sans conséquence pour la suite.

 

post-2084-0-12496300-1662042116.png

bordure v2.PNG

 

CaptureSTL.PNG

 

Un coup de peinture blanche et ca ira bien.

 

J'aimerais représenter le béton ciré. Il faut trouver une image de la texture et estimer les dimensions entre les joints (à vue d'œil, 5 à 10m sur les photos).

Fichier(s) joint(s)



#5 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 04:28

Et voila ! On a oublié personne pour l'épreuve des roulants (lignes, portique, bordures) ? Le feu tricolore et les piétons-obstacles, ce sera pour la simulation DLVV, plus tard.

 

TRRsimOpenGL 4.6.0 FPS_ 60 18_09_2022 17_24_43.png

 

Ce serait plus jolie avec des lumières et des textures, mais pour la simulation, ce n'est pas indispensable. Faudrait quand même des textures ...



#6 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 06:15

Moi ça m'intéresse :)

 

On a des roulants de conception assez proche. Un châssis R/C sur lequel on ajoute des capteurs et nos algorithmes pilotent la direction et les gaz. Ainsi, je propose d'orienter la conception du simulateur pour répondre d'abord à nos robots. Si cela fonctionne, je pourrai étendre le simulateur à d'autres types de roulants (châssis/capteurs). De manière illustrée, voici comment je vois les interactions entre le simulateur et les algorithmes du robot. Evidemment, je ne m'occupe que de la partie gauche. La partie droite est du ressort du roboticien ! Je compte fournir une API et éventuellement un exemple basique d'algorithme.

 

Arch v0.00.drawio.png

 

En outre, j'ajoute le support d'un contrôleur de jeu générique afin de piloter son robot en manuel, indépendamment des algorithmes. Je dispose d'un gamepad ordinaire. Le stick gauche pour les Gaz et le stick droite pour la Direction. Je prévois un fichier XML pour adapter la configuration au matériel disponible (mapping des axes différent d'un gamepad à l'autre) et à l'ergonomie souhaitée. 



#7 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 07:15

Avec un rendu graphique aussi basique, digne des années 90*, on peut espérer un simulateur capable de temps-réel. Soyons optimistes ! Considérons qu’il tournera à la cadence de 50/60Hz (Vsync), cohérente de la fréquence de nos servos et ESC de base. Le simulateur fonctionnera en temps discret, avec un ‘dt’ qui devrait être de l’ordre de 20ms.
 
En 2019, j’avais exploité un moteur physique (Bullet) pour simuler le comportement du robot roulant. Les années passent et je n’ai toujours pas les informations utiles (couple moteur, amortissement, adhérence des pneus…) qui permettraient de tirer profit d’une telle solution. L’idée est donc de formuler le comportement physique du robot de manière linéaire et approchée, voire très approchée. Validation au feeling, au gamepad. Ça promet !
 

 

* même pas, en vrai Doom était en 3D texturé !



#8 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 305 messages
  • Gender:Male
  • Location:Toulouse
  • Interests:Artiste Roboticien, prendre les dernières techno et les mettre sur scène... telle est ma devise.
    Gestuelle et conscience artificielle.
    Bipédie et quadrupédie

Posté 18 septembre 2022 - 08:31

Oulà, j'ai raté des sujets là ! :) Ca m’intéresse aussi.


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#9 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 09:14

Amis physiciens, c'est le moment de se distinguer !

 

Je suis sur la ligne de code qui fait avancer le robot en fonction de la commande de gaz dans le simulateur.

 

Avertissement : Je cherche un modèle simple. Le but du simulateur est de tester la configuration d'un robot, notamment le nombre et le placement des principaux capteurs, et de valider/comparer des stratégies et des algorithmes d'asservissement. Le réglage des paramètres de ces algorithmes (exemple : coefficients PID) se fera le matin du 18/19 novembre pendant les essais libres de la mini TRR.

 

1) L'équation de vitesse :

v(t+1) = v(t) + a(t).dt

2) L'équation d'accélération  :

a(t) = Forces/masse 
Forces = Fm - Fs - Fa

3) La force motrice  :

Fm/masse = Am * GAZ 

Dans un ESC basique, la commande de GAZ (0 à +100%) fait varier l'intensité dans le moteur électrique de manière proportionnelle.

Le couple moteur et proportionnel au courant dans le moteur électrique.

La force motrice est propositionnelle au couple moteur.

Je retiens un simple constante d'accélération (Am) qu'il faudra estimer de manière empirique avec le robot et sa radiocommande. 

On pourra par exemple mesurer l'accélération du robot en départ arrêté avec les gaz à fond .

 

4) Force de frottements secs

Fs/masse = As

Je retiens une simple constante de décélération (As) qu'il faudra estimer de manière empirique avec le robot et sa radiocommande. 

On pourra par exemple mesurer la décélération du robot à basse vitesse en roue libre.

 

5) Force de frottements aérodynamiques

Fa = Ka.v(t)^3

On ne connait pas le Cx du robot. Je retiens une constante (Ka) qu'il faut estimer de manière emprique... non, je plaisante! La valeur est nulle. Le robot va se trainer dans tous les virages de la mini TRR.

 

Synthèse :

v(t+1) = v(t) + dt * (Am * GAZ - As )

Si je me suis trompé sur le raisonnement ou les équations, dites le moi ! Au final, je suis surpris de ne voir aucun terme qui dépende de la vitesse (simple ou au carré) hors cette histoire de frottements aérodynamiques... qu'en pensez vous ?

 

 

Edit : Je crois me souvenir que le couple moteur décroit avec la vitesse. Il doit manquer un truc dans 3).



#10 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 305 messages
  • Gender:Male
  • Location:Toulouse
  • Interests:Artiste Roboticien, prendre les dernières techno et les mettre sur scène... telle est ma devise.
    Gestuelle et conscience artificielle.
    Bipédie et quadrupédie

Posté 18 septembre 2022 - 09:39

Pour l'équation selon la seule direction longitudinale, je rajouterais un peu de complexité sur les frottements secs :

- si la voiture est immobile, pour la faire avancer, tu doit lutter contre la resistance au roulement qui est proportionnelle au poids

- quand la voiture roule, et que les roues roulent sans glissements, la resistance au roulement est aussi là, proportionnelle au poids aussi mais légèrement inférieure à celle quand la voiture est immobile

si tu lances ta voiture en roue libre à une certaine vitesse, elle va s’arrêter sur une certaine distance D au bout d'un certain temps T. La résistance au roulement sera donc égale à

Crr = 2*D/(g*T²)

avec g la constante de gravité (9.81m/s²)

 

Crr peut être interprété comme le pourcentage du poids de la voiture qu'il faudra pousser pour la faire avancer et dépend des matériaux et du diamètre de la roue.

 

- si les roues dérapent, ce sont ici les frottements de coulomb qui vont agir avec un autre coefficient de retenue, lui aussi ne dépendant que du poids.

 

Donc pour moi, les forces allant contre la propulsion ne dépendent pas de la vitesse de la voiture mais du glissement entre roue et piste.

 

https://fr.wikipedia...ce_au_roulement

 

Pour les forces aéro, je pense aussi que la trainée est négligeable en rapport des frottements secs.

 

Mais il peut y avoir un effet combiné de la portance et de l'équation mécanique autour de l'axe de tangage qui fera par exemple équilibrer le véhicule plus vers l'avant ou l'arrière ce qui enlève de l'adhérence de propulsion (en plus des équations de virage en lacet, prochaine étape)


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#11 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 18 septembre 2022 - 10:59

Merci Thot. Je comprends. Je pense que la formule (3) est erronée. Le rendement en fonction de la vitesse de rotation manque.

 

Pour la direction, j'ai bricolé un équation très simple qui prend en compte le rayon de braquage du robot en fonction de la vitesse. Ca se mesure facile et l'approximation peut être suffisante.

 

En modélisant de manière procédurale le robot (4 cylindres pour les roues et un bloc pour le châssis), j'obtiens un premier résultat graphique et physique, en pilotage manuel. 

 

 

Difficile de se rendre compte du réalisme avec un gamepad (plutot qu'une radio à volant), mais ca prend forme !



#12 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 412 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 19 septembre 2022 - 02:52

 

 

5) Force de frottements aérodynamiques

Fa = Ka.v(t)^3

On ne connait pas le Cx du robot. Je retiens une constante (Ka) qu'il faut estimer de manière emprique... non, je plaisante! La valeur est nulle. Le robot va se trainer dans tous les virages de la mini TRR.

 

 

 

Pour ce qui est de la force de résistance aérodynamique il me semble que c'est proportionnel au carré de la vitesse et pas au cube ! :P mais je pense également qu'on va pouvoir la négliger même si j'espère que nos robots vont pas trop se traîner. 
 

 

 

 

Synthèse :

v(t+1) = v(t) + dt * (Am * GAZ - As )

Si je me suis trompé sur le raisonnement ou les équations, dites le moi ! Au final, je suis surpris de ne voir aucun terme qui dépende de la vitesse (simple ou au carré) hors cette histoire de frottements aérodynamiques... qu'en pensez vous ?

 

 

Edit : Je crois me souvenir que le couple moteur décroit avec la vitesse. Il doit manquer un truc dans 3).

 

Sans rentrer dans le détail il y a forcément une erreur dans le raisonnement juste en réfléchissant un peu à ce qu'impliquerait un tel résultat ...
Si cette formule était vraie alors en maintenant les gazs un peu au dessus de la force de frottement sec, en attendant suffisamment longtemps on pourrait atteindre une vitesse infinie ... Ce qui n'est pas le cas ...

 

Au lieu de chercher à faire l'approche " physique " je vais faire l'approche " science de l'ingénieur  / automatisme"  : 

La courbe d'un régime moteur à accélération constante se finit nécessairement par une vitesse constante, et on peut éventuellement déjà commencer par essayer de l'approximer avec un premier ordre de la forme 
 

v(t) = (V0 - VF) exp(-K * t) + VF  et quand on a V0 nulle ça nous donne v(t) = ( VF ( 1 - exp(-K * t) ) ...

Avec VF et K deux constantes qui vont varier en fonction des gazs des frottements et des paramètres du moteur )  

 

( voir le principe des systèmes du 1er ordre : http://asi.insa-rouen.fr/enseignement/siteUV/auto/cours/cours2.pdf )

Pour estimer ces paramètres on peut lancer plusieurs fois la voiture avec des commandes d'accélérations constantes différents pour estimer la courbe VF(gaz)  et K(gaz)  ... 

Du moins c'est l'approche que je proposerais ...
 

 

 

Pour ce qui est du rayon de braquage c'est une formule assez délicate surtout pour nos robots ... 

En gros en théorie pure, si on néglige les forces inertielles que la direction des roues est " fixée " uniquement par l'angle du servo de direction alors l'angle de braquage devrait être indépendant de la vitesse ... " Pure loi cinématique " ... 

Or, si on va trop vite et qu'on braque trop fort la voiture ne va pas tenir la route et va partir en drift voir en tête à que ...  Mais rien ne nous empêche réellement de braquer autant ... C'est l'inertie  l'adhérence des roues, et la force centrifuge qui jouent ... 
Donc premier point qu'on devrait réussir à voir dans le simulateur : Quand est ce qu'on part en drift ... 


De plus généralement l'angle de braquage des roues sur ce genre de voiture n'est pas proportionnel à l'angle du servo, au delà de la loi cinématique qui lie les deux et qui n'est pas linéaire, il y a généralement un accouplement monté sur ressort qui fait qu'on peut toujours manuellement changer l'angle de braquage des roues de direction quelque soit l'angle du servo qui gère le braquage ... ce système permet notamment de limiter le couple exercé par le servo ( le ressort amortis l'effort ) et limite un peu le risque de tête à queue ...
En gros en l'absence de force exercée sur les roues de directions l'angle des roues de directions dépend uniquement de l'angle du servo = contrôle de repos ,  pour une même " consigne de braquage " ce qui change en fonction de la vitesse c'est pas censé être l'angle de braquage en lui même mais la vitesse à laquelle ça va braquer ... la vitesse provoque une inertie qui vient s'opposer au braquage, et ralentir le mouvement du braquage avec un amortissement plus ou moins important sur le ressort ... 

On peut réussir à définir la physique derrière ce mécanisme ... On a un ressort, qui exerce une force F = K * x avec x etant la distance de compression / étirement, cette force s'exerce à une distance d de l'axe de rotation des roue de direction, on obient donc un couple cr de résistance au braquage qui est est nul tant que l'angle de braquage correspond à l'angle contrôlé par la se servo ...  En calculant le couple exercé sur le roues de braquages qui s'oppose au braquage, ( liée à l'inertie du véhicule, elle même liée à la vitesse ) on va pouvoir trouver de combien le ressort se comprime pour compenser cette force ... Et donc avec un peu de cinématique on peut trouver quelle est la position réelle de braquages des roues par rapport à la position de consigne en temps réél ... 

Mais tout ça me semble bien " compliquée " ... Si je devais sortir comme ça une formule simplifiée de mon chapeau je commencerais par chercher la loi cinématique entre le servo et l'angle de braquage de roues en l'absence de force résistante puis j'appliquerais cette formule avec un retard plus important en fonction de la vitesse du robot et dont la rapidité de braquage serait aussi en fonction du delta entre la consigne et la position actuelle ... 

Je supposerais aussi que l'accélération du braquage de la roue serait une " constante " dépend de sa position p , de la position finale de braquage souhaitée et de la vitesse actuelle du robot ( on part tu principe que la vitesse initiale de rotation des roues de braquage est nulle dans la direction du braquage  ) 

 

 a(p(t)) = k1(pf - p(t)) - k2 v      => a(p) =( k1 *pf - k2 v) - K1 p 

v(p(t)) = (k1*pf - k2 v) p(t) - k1/2  p(t)²     (+ v0 mais v0 est considérée nulle )


p(t) = étant l'intégrale de v(p(t) )   et v(p(t) ) s'exprimant entre autre avec p(t) et connaissant la nature du type de mouvement recherché j'en déduit qu'on va avoir un résultat avec des exponentielle ...  Mais là il est un peu tard et ça remonte un peu à trop loin pour que je calcul cette intégrale rapidement sans erreur ... 

Cependant, vu qu'on sait un peu à quoi ça va ressembler car, l'expression d'un retard et où la position final c'est censé être la position PF demandé est la position initial c'est la position P0 ...

On doit pouvoir simplifier le résultat de l'intégrale précédente avec un truc  un peu proche de cette forme : 

 

p(t) = (P0 - PF) exp(-Kv t) + PF  // P(t) etant l'angle de braquage de roues en fonction du temps en appliquant une consigne PF, à t = 0 alors que l'angle de braquage était à la position P0) 

 

 

En arrivant là je me dit que j'ai fait beaucoup de blabla pour expliquer et justifier cette forme... qui est en fait de la même forme que celle de la vitesse du robot...

 

Et je pense qu'il faudrait que je revienne un peu plus tard sur les 2 formules proposées,  car il y manque très certainement des termes liées aux frottements ou autre et qui seraient  en forme : 

K1 *( t ^ n1) *exp( - K2 *  t^n2)   ( en gros quelque chose qui vaut 0 aussi bien quand t = 0 que quand t va vers l'infini ... )  

Ces termes sont des termes qui vont impacter la phase transitoire (et faire qu'on est pas vraiment sur un système du 1er ordre ... ) mais que pour le moment je pense qu'on doit pouvoir négliger ...

L'idéal serait de faire des mesures en continue sur les voitures et tracer les courbe pour comparer la forme simplifiée qu'on obtient avec les valeurs mesurées en vraie ...
Si on voit que notre courbe avec la formule simplifiée est trop éloignée, il faudra évoluer vers des systèmes d'ordre plus complexe que la forme du 1er ordre que j'ai proposée ... Limite le plus simple serait de tracer des courbes et chercher à caler une formule qui s'en rapproche ... 

Une fois qu'on a ces deux formules, ensuite il faut calculer la rotation de la voiture en fonction de la distance entre les roues avant et arrière et l'angle de braquage ( en déterminant le rayon de braquage instantanée ... )  afin de pouvoir estimer le déplacement x y théta du robot ...

Ce genre de formule marche bien pour du calcul itératif ... et ça me fait penser à mon premier " simulateur " qui ne faisait que calculer les valeurs de position et que j'avais fait sur excel pour mon premier Robot Rmad  Notez au passage que techniquement ce robot était déjà capable de participer à la TRR (à l'arrêt prêt à la fin) et c'était en 2012 et sans micro-contrôleurs... Juste de AOP ...

 

Bref tout ça pour dire que c'est super intéressant mais qu'on arrive au point pour lequel je ne fait que très peu de simulation ... En générale, je trouve que faire un simulateur "réaliste " est plus difficile que de trouver les paramètre d'asservissement ... 
Et que le reality gap est généralement trop important pour que le résultat soit directement transposable ... 

Après pour "ajuster au maximum la simulation " l'idéal est de pouvoir prévoir de faire directement des mesures sur le robot pour définir les paramètres du simulateurs ... Avec un code qui enregistre de lui même les données sur une carte SD par exemple pour ensuite pouvoir nourrir le simulateur avec ... 

En tout cas le simulateur à l'air super ! J'ai hâte de le tester ! :P 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 


#13 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 19 septembre 2022 - 05:39

Merci Mike. On est bien d'accord sur l'équation finale de la vitesse. Je vais relire ta proposition pour la vitesse et pour la direction, et je reviens vers vous.

 

J'ajouterai au fichier de configuration XML, l'ensemble des paramètres "physiques" qui seront à ajuster en fonction des caractéristiques de son propre robot.

 

Pour la mini TRR (basse vitesse),on va approcher le comportement du robot dans le simulateur avec une physique simplifiée. Pour la TRR, la vitesse est supérieure, on avisera...

 

En termes de capteurs, j'implémente en priorité le LIDAR (1D) qu'on utilise (TF Mini Plus), en exploitant le système de collision du moteur graphique.

 

J'ajoute donc 4 capteurs à mon robot (position et orientation configurables) avec une topologie proche de celle du robot de Mike.

 

Voici le rendu en mode "debug graphique". Le LIDAR retourne une mesure en cm, et zéro en l'absence de mesure.

 

 

Petite limitation : la mesure est faite à la cadence du simulateur, soit 60Hz (Vsync).



#14 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 412 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 19 septembre 2022 - 06:19

Franchement même si la vitesse est supérieure pour la TRR, si le reality gap est faible entre le simulateur de la TRR mini et la réalité, ( en gros même si le temps n'est pas le même entre la simulation et la réalité mais qu'avec les paramètre trouvé en simu, la voiture fait déjà de bons résultat en réalité ) alors il n'y aura pas de problème pour que ça marche tout aussi bien pour la TRR... 

Pour en revenir sur le paramètre physique des équations de vitesse, la simu devrait nous montrer que pour atteindre "plus rapidement" la consigne souhaité, on devrait vouloir faire des " overshot " de consigne ... 

Imaginons qu'on souhaite avoir atteindre une vitesse Vc, et que d'après nos tests cette vitesse est atteinte en limite quand on mets les gazs à la valeur Gazc, alors on devrait commencer par mettre les gazs à une valeur supérieur à Gazc jusqu'à ce que la vitesse se rapproche de Vc et diminuer progressivement les gazs jusqu'à la valeur Gazc ...

En tout cas le gros avantage de la simulation c'est que tu peux faire tourner des algo " auto adaptatifs " sans avoir peur de casser du matos et tu peux faire " pleins d'essais très rapidement " ... 
Au fait le simulateur tu as prévu de tout coder tout seul ( certains préfèrent ) ou bien tu fais ça sur un github et tu acceptes de l'aide ?

En tout cas je sais pas en combien de temps tu as fait ça mais ce que tu présentes et déjà bien sympa =) ça me rappel une simulation que j'avais fait en projet scolaire en utilisant vrep https://www.coppelia...tics.com/videosmais la grosse différence c'est que moi je ne faisais pas le simulateur je ne faisais qu'en utiliser un existant ^^


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 


#15 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 305 messages
  • Gender:Male
  • Location:Toulouse
  • Interests:Artiste Roboticien, prendre les dernières techno et les mettre sur scène... telle est ma devise.
    Gestuelle et conscience artificielle.
    Bipédie et quadrupédie

Posté 19 septembre 2022 - 07:04

Je suis d'accord sur le problème du reality gap, mais un simulateur permet de lever déjà pas mal de problématiques en avance. J'ai toujours eu du mal avec les logiciels de simulation standards pour lesquels on a du mal a savoir le realisme des equations sous-jacentes notamment quand il y a des frottements en jeu avec le sol. Dans le bipède c'est d'autant plus vrai.
C'est pour ça que le simulateur m'intéresse si on peut travailler directement sur les équations de la physique.

Pour mon futur robot a turbine, l'avantage va être que je vais coller assez bien à l'équation avec les gaz, les roues vont toujours être sans glissement.

Nous avions déjà un peu joué sur la petite piste avec les robots prévus pour la grande. Le simulateur va sans doute permettre de voir deux choses :
- la piste fait 1m de large au lieu de 1m50 et les virages sont vachement serrés. Ce circuit va mettre en valeur les temps de réaction et les retards/anticipation par rapport a l'autre piste.
- les virages sont très serrés donc ça risque de drifter... Comment gérer le drift ?

Je suis vachement curieux des temps qu'on va obtenir, a quel point on va pouvoir pousser les machines.

"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#16 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 19 septembre 2022 - 07:15

Imaginons qu'on souhaite avoir atteindre une vitesse Vc, et que d'après nos tests cette vitesse est atteinte en limite quand on mets les gazs à la valeur Gazc, alors on devrait commencer par mettre les gazs à une valeur supérieur à Gazc jusqu'à ce que la vitesse se rapproche de Vc et diminuer progressivement les gazs jusqu'à la valeur Gazc ...

 

C'est justement le feeling que je cherche à retrouver en pilotant manuellement avec le simulateur et ce modèle physique simplifié : plus de GAZ au départ, accélération plus forte au départ, vitesse constante en fonction des GAZ..

 

Pour la TRR, je me souviens que notre robot dérapait assez franchement dans certains virages. A voir si un simulateur plus réaliste permet d'aller plus loin dans la préparation à la course.

 

Sur le principe, je peux rendre public le repo sur Github. C'est juste que je ne m'attendais pas à avoir d'éventuels contributeurs sur le code. Je commence tout juste le développement.

 

Je comprends qu'il faudra différents modèles physiques à paramétrer en fonction du type de propulseur : moteur électrique, turbine, etc. Intéressant !

 

Voici ce que cela donne avec un algorithme basique de type PID direction exploitant les mesures LIDAR droite et gauche. Les Gaz sont en manuel. C'est fait à l'arrache...

 

 

----

 

Arch v0.00.drawio.png

 

Pour bien isoler le simulateur de l'implémentation des algorithmes à tester, je compte partir sur du client/serveur UDP ou TCP avec un format de trame simple et propriétaire. En effet, le simulateur en C/C++, compilé avec le moteur graphique pour PC/Windows, est plus simple à distribuer sous forme de binaire exécutable aux utilisateurs. La chaine de compilation n'est pas très complexe mais cela rendrait le simulateur moins accessible s'il est distribué sous forme de source à compiler soi même.

 

Enfin, la connexion réseau permet de programmer les algorithmes dans un langage autre que C/C++ (Python par exemple) et même de faire tourner les algorithmes sur la cible embarquée dans le robot (Rpi, Arduino, etc). Qu'en pensez vous ?

 

 

Merci pour votre support ! C'est très enrichissant.



#17 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 19 septembre 2022 - 07:22

Je suis vachement curieux des temps qu'on va obtenir, a quel point on va pouvoir pousser les machines.

 

Sur une réplique du circuit dans nos locaux, on arrive à moins de 8 secondes en manuel.

 

Je viens de mesurer 6 secondes avec le simulateur et mon PID basique.

 

On va dire que le simulateur est optimiste dans l'état actuel, mais 6 secondes au tour devient mon objectif pour le robot qu'on va inscrire. Challenge !

 

 

NB: j'espère que les bordures sont robustes et bien fixées ! :-)



#18 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 412 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 19 septembre 2022 - 11:04

 

 

NB: j'espère que les bordures sont robustes et bien fixées ! :-)

 

 

Il y a un truc dans le règlement qui dit qu'on ne doit pas défoncer les bordures :P

 

 

 

Sur une réplique du circuit dans nos locaux, on arrive à moins de 8 secondes en manuel.

 

 

Ah mais vous avez une réplique du circuit dans vos locaux !  :crazy: 

Moi mon seul bout de circuit c'est le bout de couloir qu'on voit dans une des vidéo x) Ils sont où vos locaux déjà ? :P 

 

 

 

 

On va dire que le simulateur est optimiste dans l'état actuel, mais 6 secondes au tour devient mon objectif pour le robot qu'on va inscrire. Challenge !

 

 

6 secondes c'est un beau challenge :P

 

 

 

 

Pour la TRR, je me souviens que notre robot dérapait assez franchement dans certains virages. A voir si un simulateur plus réaliste permet d'aller plus loin dans la préparation à la course.

 

 

 

Le mien de mémoire il allait pas du tout assez vite pour cela ... mais bon à essayer de paufiner les réglages uniquement sur site le jour du concours j'ai pas eu le temps d'aller très loin non plus :). J'espère que cette année ça marchera mieux ;)

 

 

 

 

Sur le principe, je peux rendre public le repo sur Github. C'est juste que je ne m'attendais pas à avoir d'éventuels contributeurs sur le code. Je commence tout juste le développement.

 

Je comprends qu'il faudra différents modèles physiques à paramétrer en fonction du type de propulseur : moteur électrique, turbine, etc. Intéressant !

 

Pour bien isoler le simulateur de l'implémentation des algorithmes à tester, je compte partir sur du client/serveur UDP ou TCP avec un format de trame simple et propriétaire. En effet, le simulateur en C/C++, compilé avec le moteur graphique pour PC/Windows, est plus simple à distribuer sous forme de binaire exécutable aux utilisateurs. La chaine de compilation n'est pas très complexe mais cela rendrait le simulateur moins accessible s'il est distribué sous forme de source à compiler soi même.

 

Enfin, la connexion réseau permet de programmer les algorithmes dans un langage autre que C/C++ (Python par exemple) et même de faire tourner les algorithmes sur la cible embarquée dans le robot (Rpi, Arduino, etc). Qu'en pensez vous ?

 

 

Merci pour votre support ! C'est très enrichissant.

 

Je pense aussi que distribuer sous forme d'exécutable le rendrait plus accessible, mais si les sources sont partagés il est fort possible que tu puisses avoir des contributeurs ;) et c'est plus facile de suivre un projet dès le début et de proposer des modification pendant le début que lorsque tout est figé ... Mais bon après ce n'est que mon avis et libre à toi de choisir comment tu veux faire ce que tu veux faire =)


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 


#19 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 305 messages
  • Gender:Male
  • Location:Toulouse
  • Interests:Artiste Roboticien, prendre les dernières techno et les mettre sur scène... telle est ma devise.
    Gestuelle et conscience artificielle.
    Bipédie et quadrupédie

Posté 19 septembre 2022 - 11:11

 


NB: j'espère que les bordures sont robustes et bien fixées ! :-)

Les bordures sont en aluminium peint de 10mm d'épaisseur, ça devrait aller :)


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#20 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 19 septembre 2022 - 12:33

D'accord, on va peaufiner les algorithmes !

 

Avec un autopilot avec un PID direction et un PID vitesse.

 

https://youtu.be/uOyTrFJKA7I

 

 

 

Prochaine étape ?





Répondre à ce sujet



  


0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users