Aller au contenu


Photo
- - - - -

Simulation TRR épreuves "Roulant" & "DLVV"


36 réponses à ce sujet

#21 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 19 septembre 2022 - 10:11

Evolutions :

* Corrections multiples dont modèle physique

* Affichage de la vitesse, des commandes GAZ/DIRECTION, des accélérations, et des temps au tour

 

 

A faire :

* améliorer le modèle physique (vraiment trop optimiste) et le rendre paramétrable. Préciser la méthode de paramétrage du simulateur (mesures à réaliser sur son propre robot).

* rendre paramétrable le robot simulé, son apparence (voie, empattement, diamètre/largeur des roues, ...voire skin STL) et la position et l'orientation de ses capteurs

* produire un fichier de log (CSV) contenant toutes les données de la simulation (temps, capteurs, commandes, vitesse, accélérations...) afin de tracer des courbes et analyser la simulation.

* étudier la possibilité d'injecter du bruit et des imprécisions dans les mesures retournées par les capteurs.

* améliorer l'apparence du rendu 3D.

* inclure le circuit de la TRR 110m.

 

 

Je vais faire une toute première version distribuable et ouvrir un repo public sur Github.

Les plus motivés pourront tester/vérifier que cela fonctionne sur un autre ordinateur que le mien.

 

Toutes les remarques et suggestions sont les bienvenues.

 

Le gamepad ne permet vraiment pas d'apprécier au feeling le réalisme du simulateur. Il faudrait pouvoir brancher une radio à volant sur le PC mais ce type de radio n'est pas aussi moderne que les radiocommandes d'aéromodélisme. Il doit exister un moyen de récupérer les signaux de sortie (PWM) d'un récepteur et d'émuler un joystick via le post USB. Une petit adaptateur... ou un Arduino bien programmé.

 

Patrick.



#22 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 20 septembre 2022 - 10:01

Bonsoir,

 

Le simulateur produit un fichier de données lisible (CSV). A chaque Tick (~20ms), les données suivantes sont enregistrées :

  • numéro du tour courant
  • temps (ms)
  • vitesse (m/s)
  • accélérations longitudinale et latérale (m²/s)
  • commandes de direction et de gaz (-100%..+100%)
  • les distances mesurées par les LIDAR (cm)

 

Ce fichier est facilement exploitable pour tracer des courbes et analyser les résultats.  Exemples de graphes :

Graphs001.png

Graphs003.png

 

 

J'ai ajouté un bruit dans les mesures des capteurs. Pour commencer, j'ai choisi une distribution normale, avec une variance de l'ordre de 5 cm pour les LIDAR TF Mini plus. C'est supérieur à la précision des capteurs donnée par Benewake. A ajuster! Je pense faire la même chose sur la remontée de vitesse instantanée. Le simulateur connait la vitesse exacte, mais je peux retourner une valeur bruitée à l'algorithme de pilotage.

 

 

Je suis tombé sur l'adaptateur USB qui permet d'émuler un joystick à partir d'un ensemble R/C. Le couplage avec le simulateur a nécessité un simple ajustement de son fichier de configuration XML (mapping des axes). En pilotant manuellement, je ne retrouve pas le comportement de mon robot. La simulation physique (paramètre et formules) est à travailler.

IMG20220920220357.jpg

 

 

Pour configurer le simulateur, les performances du robot doivent être préalablement mesurées. A cet effet, le robot doit être équipé d'un capteur de vitesse et il doit pouvoir enregistrer sa vitesse sur un court laps de temps (~20s). L'objectif est d'obtenir un enregistrement de la manipulation suivante :

  • Départ arrêté 
  • Accélération maximale juste à la vitesse max,
  • Plus roule libre jusqu'à l'arrêt.

Cette manipulation doit permettre de relever :

  • la décélération liée aux frottements secs,
  • l'accélération produite par la force motrice
  • la vitesse maximale du robot

Une fois ces données reportées dans la configuration du simulateur, le robot simulé doit se comporter de la même manière. Il suffit de rejouer cette manipulation dans le simulateur, et analyser le fichier de données qu'il génère. Je vais essayer sur mon propre robot pour valider l'approche. Si cela fonctionne, il restera la physique liée aux virages.

 

 

Les graphismes 3D n'ont pas changé. La marge de progression est énorme, mais ce n'est pas la priorité.

View001.png

 

 

Je souhaiterais tester la distribution sous forme de binaire exécutable. Je dépose en pièces jointe une archive (TRRsim.zip) contenant le dossier de TRRsim avec l'exécutable, ses fichiers dll et le pack de données. Je vous invite à tester l'exécution. Important : Vérifiez absolument les fichiers avec votre antivirus à jour avant de lancer l'exe.

CaptureAV.PNG

 

Si jamais le simulateur se lance correctement, voici les touches de fonction utiles, sachant qu'il y a un algorithme par défaut dans le simulateur pour contrôler le robot.

F2: RETURN TO START LINE
F3: START AUTOPILOT
F4: SUSPEND AUTOPILOT
F5: DRAW LIDAR
F10: WORLD CAMERA (MAYA)
F11: ON-BOARD CAMERA
ALT-F4 pour fermer.

Au lancement, la caméra est positionnée au ras du sol. Bouton gauche de la souris pour faire tourner la caméra, bouton droit pour la déplacer, bouton central pour zoomer (appuyer puis glisser droite<=>gauche). C'est une caméra avec l'ergonomie Maya (oui, c'est vieux!).

 

 

J'attaque la petite couche réseau qui permettra de faire le lien entre le simulateur et les algorithmes du robot à tester. Je voulais me rendre la vie plus facile en choisissant une petite librairie. J'ai trouvé Enet en faisant une recherche : http://enet.bespin.org/ . Si vous en connaissez une pratique, n'hésitez pas à me l'indiquer.

 

 

Reste à Faire :

améliorer le modèle physique (vraiment trop optimiste) et le rendre paramétrable. Préciser la méthode de paramétrage du simulateur (mesures à réaliser sur son propre robot).

* rendre paramétrable le robot simulé, son apparence (voie, empattement, diamètre/largeur des roues, ...voire skin STL) et la position et l'orientation de ses capteurs

* produire un fichier de log (CSV) contenant toutes les données de la simulation (temps, capteurs, commandes, vitesse, accélérations...) afin de tracer des courbes et analyser la simulation.

* étudier la possibilité d'injecter du bruit et des imprécisions dans les mesures retournées par les capteurs.

* améliorer l'apparence du rendu 3D.

* inclure le circuit de la TRR 110m.

* repo publique sur Github.

--edit :
* adaper UI aux dimesions de l'écran.
* compatibilité aux cartes graphiques à améliorer
 
A suivre !
 

Patrick.

Fichier(s) joint(s)

  • Fichier joint  TRRsim.zip   2,39 Mo   9 téléchargement(s)


#23 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é 21 septembre 2022 - 04:48

Du coup j'ai essayé de tester et j'ai un petit truc un peu bizarre : 

Le rendu est super en vue de dessous ... 
simu ok.JPG

Mais complètement "cassé " quand la caméra est au dessus du niveau du sol / vu de dessus ... 

cassé.JPG

 

Ce rendu " cassé " a directement un impacte sur le fonctionnement du simulateur. 

Lorsque je reste avec la caméra en vue de dessous, tout marche, dès que je bouge la caméra pour passer en vue de dessus et que le rendu est cassé, la voiture passe à travers les murs ... Et elle passe aussi à travers les murs dès que je passe la caméra en mode vue de la voiture...

J'ai pu faire l'affichage des données lidar et voir que l'affichage de données lidar marche dans tous les cas ... même quand le rendu est " cassé " du coup je ne sais pas exactement ce qui se passe dans le mode cassé pour que la voiture s'autorise à percuter les murs ...

En tout cas cela a l'air très prometteur ! 


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  

 

 

 


#24 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 21 septembre 2022 - 05:57

Merci Mike. Est-ce que tu as une carte graphique dans ton PC et est-ce que tu peux forcer l'exécution sur celle-ci plutôt que le processeur graphique intégré au processeur (Intel) ?

 

Je note d'adapter les dimensions de l'interface à celle de l'écran. Je vais aussi chercher à comprendre pourquoi sur certaines cartes/processeurs graphiques, le rendu ne se passe pas bien.

 

--edit: 

 

En pièce jointe, une nouvelle version qui force le Zbuffer en 24bits (defaut 16bits). A tester. Je pourrai également augmenter jusqu'à 32 bits.

Fichier(s) joint(s)



#25 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 21 septembre 2022 - 11:20

Lorsque le simulateur tourne sur ma carte graphique intégrée au processeur, avec une taille de Zbuffer de 16bits par défaut, je reproduis le même problème graphique.

Les bordures s'affichent de manière incorrecte et les mesures LIDAR sont erronées.

TRRsimOpenGL 4.6.0 FPS_ 66 21_09_2022 12_06_52.png

 

Lorsque je relance avec une taille de Zbuffer de 24 ou 32 bits. Tout semble rentrer dans l'ordre.

Et si je lance sur ma carte graphique NVidia, ca marche aussi. 

Screenshot 21_09_2022 12_10_38.png

 

Explication : Le circuit est modélisé en prenant comme unité le mm. Du coup, les coordonnées 3D des vertices ont de grands nombres (10m = 10000.0f) et les distances near/far de la caméra sont également tres grandes (15m = 15000.0f). A priori, ce n'est pas courant dans un jeu vidéo qui n'a pas besoin d'une unité aussi petite. Le Zbuffer en 16 bits (virgule fixe?) n'est vraisemblablement pas assez précis pour calculer correctement les pixels à afficher au premiers plan. 

 

Je note prochaine Release avec Zbuffer en 32 bits.

 

A priori, problème résolu! A tester sur d'autres configurations PC !

 

--edit: je réduis légèrement la taille par défaut de la fenêtre graphique (1400x800), qui restera pour le moment de taille fixe, afin de passer sur toute taille d'écran.



#26 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 22 septembre 2022 - 10:09

Bonsoir,

 

Le simulateur est maintenant séparé en deux composants logiciels distincts qui communiquent en réseau (port "1234") :

* serveur : le simulateur avec sa fenêtre graphique,

* client : le pilote automatique.

 

Utilisation :

 

1) lancer TRRsim.exe

   note : le simulateur indique "Waiting for autopilot..."

2) lancer TRRautopilot.exe

   note : le simulateur indique "Autopilot connected"

3) presser F3 dans la fenêtre du simulateur pour lancer le robot. F4 pour arrêter. F2 pour revenir à la ligne de départ.

 

Il est possible d'arrêter le logiciel du pilote automatique, et de le relancer (après une modification du code par exemple), sans avoir besoin relancer le logiciel simulateur.

 

 

Code source :

 

Lien vers le code source de la partie pilote automatique : https://github.com/p...fr/TRRautopilot

Dans main.cpp, il y a un exemple d'algorithme basique. Il s'agit de créer une classe dérivée de Cautopilot et de compléter la fonction update() avec ses propres algorithmes.

Le fichier projet pour l'environnement Code::blocks et MinGW est fourni (codeblocks-20.03mingw-setup.exe). Le logiciel a besoin de la librairie Enet que j'ai précompilé pour Windows avec MinGW (voir dossier enet/).

 

 

Release :

 

v0.06

 

 

Reste à Faire :

améliorer le modèle physique (vraiment trop optimiste) et le rendre paramétrable. Préciser la méthode de paramétrage du simulateur (mesures à réaliser sur son propre robot).

* rendre paramétrable le robot simulé, son apparence (voie, empattement, diamètre/largeur des roues, ...voire skin STL) et la position et l'orientation de ses capteurs

* améliorer l'apparence du rendu 3D.

* inclure le circuit de la TRR 110m.

* repo publique sur Github.

* adaper UI aux dimesions de l'écran.
* compatibilité aux cartes graphiques à améliorer
* ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...
 
Patrick.

Fichier(s) joint(s)



#27 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é 23 septembre 2022 - 10:25

Merci Mike. Est-ce que tu as une carte graphique dans ton PC et est-ce que tu peux forcer l'exécution sur celle-ci plutôt que le processeur graphique intégré au processeur (Intel) ?

 

Je note d'adapter les dimensions de l'interface à celle de l'écran. Je vais aussi chercher à comprendre pourquoi sur certaines cartes/processeurs graphiques, le rendu ne se passe pas bien.

 

--edit: 

 

En pièce jointe, une nouvelle version qui force le Zbuffer en 24bits (defaut 16bits). A tester. Je pourrai également augmenter jusqu'à 32 bits.

 

Je confirme que ça marche beaucoup mieux, plus de problème de rendus, par contre il y a quand même quelques bugs qui peuvent apparaître un peu aléatoirement, et qui font que la voiture peut finalement passer à travers un mur alors qu'habituellement elle fait de nombreuses fois tout le tour de la piste sans incidents ...

 

 

 

Bonsoir,

 

Le simulateur est maintenant séparé en deux composants logiciels distincts qui communiquent en réseau (port "1234") :

* serveur : le simulateur avec sa fenêtre graphique,

* client : le pilote automatique.

 

Utilisation :

 

1) lancer TRRsim.exe

   note : le simulateur indique "Waiting for autopilot..."

2) lancer TRRautopilot.exe

   note : le simulateur indique "Autopilot connected"

3) presser F3 dans la fenêtre du simulateur pour lancer le robot. F4 pour arrêter. F2 pour revenir à la ligne de départ.

 

Il est possible d'arrêter le logiciel du pilote automatique, et de le relancer (après une modification du code par exemple), sans avoir besoin relancer le logiciel simulateur.

 

 

Code source :

 

Lien vers le code source de la partie pilote automatique : https://github.com/p...fr/TRRautopilot

Dans main.cpp, il y a un exemple d'algorithme basique. Il s'agit de créer une classe dérivée de Cautopilot et de compléter la fonction update() avec ses propres algorithmes.

Le fichier projet pour l'environnement Code::blocks et MinGW est fourni (codeblocks-20.03mingw-setup.exe). Le logiciel a besoin de la librairie Enet que j'ai précompilé pour Windows avec MinGW (voir dossier enet/).

 

 

Release :

 

v0.06

 

 

Reste à Faire :

améliorer le modèle physique (vraiment trop optimiste) et le rendre paramétrable. Préciser la méthode de paramétrage du simulateur (mesures à réaliser sur son propre robot).

* rendre paramétrable le robot simulé, son apparence (voie, empattement, diamètre/largeur des roues, ...voire skin STL) et la position et l'orientation de ses capteurs

* améliorer l'apparence du rendu 3D.

* inclure le circuit de la TRR 110m.

* repo publique sur Github.

* adaper UI aux dimesions de l'écran.
* compatibilité aux cartes graphiques à améliorer
* ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...
 
Patrick.

 

 

 

Bonsoir,

 

Le simulateur est maintenant séparé en deux composants logiciels distincts qui communiquent en réseau (port "1234") :

* serveur : le simulateur avec sa fenêtre graphique,

* client : le pilote automatique.

 

Utilisation :

 

1) lancer TRRsim.exe

   note : le simulateur indique "Waiting for autopilot..."

2) lancer TRRautopilot.exe

   note : le simulateur indique "Autopilot connected"

3) presser F3 dans la fenêtre du simulateur pour lancer le robot. F4 pour arrêter. F2 pour revenir à la ligne de départ.

 

Il est possible d'arrêter le logiciel du pilote automatique, et de le relancer (après une modification du code par exemple), sans avoir besoin relancer le logiciel simulateur.

 

 

Code source :

 

Lien vers le code source de la partie pilote automatique : https://github.com/p...fr/TRRautopilot

Dans main.cpp, il y a un exemple d'algorithme basique. Il s'agit de créer une classe dérivée de Cautopilot et de compléter la fonction update() avec ses propres algorithmes.

Le fichier projet pour l'environnement Code::blocks et MinGW est fourni (codeblocks-20.03mingw-setup.exe). Le logiciel a besoin de la librairie Enet que j'ai précompilé pour Windows avec MinGW (voir dossier enet/).

 

 

Release :

 

v0.06

 

 

 

 

Je vais tester ça ce week end et essayer de voir un peu ce code source. Je vais essayer plus particulièrement de regarder comment tu gère le modèle physique pour voir si je peux proposer un truc =)


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  

 

 

 


#28 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 23 septembre 2022 - 11:04

Merci, Mike pour ton essai.

 

J'ai constaté un bug : lorsque je déplace la fenêtre, la simulation est mise en pause. Quand la simulation reprend, l'intervalle de temps (dt) est perturbé. Le robot et projeté en avant et il peut sortir de la piste.

 

Le git du pilote automatique est public. Celui du simulateur est privé encore. Je suis sur la partie physique justement. Le comportement dans l'axe longitudinal commence à être proche de la réalité. Je suis en train de retoucher le comportement en virage.



#29 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 24 septembre 2022 - 09:05

Bonjour,
 
Une petite modification de la gestion du temps dans le simulateur pour corriger un bug. Lorsque le rendu 3D de la simulation est interrompu, le temps de la simulation est figé.
 
Au sujet du modèle physique, j'obtiens un résultat plutôt satisfaisant avec la méthode suivante dans l'axe longitudinal.
 
  • Simulation des frottements aérodynamiques avec une constante C_drag calculée sur la base d'un Cx de 0.3 et d'une surface frontale de 1dm².
f_drag = - _v * _v * C_drag;
  • Simulation des frottements de roulement avec une constante C_rr calculée sur la base de 10x la valeur de C_drag
f_rr = - _v * C_rr;
  • Simulation d'une force de frottements secs que j'estime en observant la décélération (Drr) de mon robot en roue libre à basse vitesse (~1m/s²). A appliquer si la vitesse est positive seulement.
fs = Drr * weight;
  • Simulation de la force de freinage que j'estime en observant la décélération (D) de mon robot BRAKE à fond sans déraper (~10m/s²). A appliquer si la vitesse est positive seulement.
f_braking = - weight * (D-Drr) * _throttle_setpoint;
  • Estimation de la force de traction maximale, qui dépend du poids sur les roues motrices, en fonction de la masse du robot (~1.1Kg), de la position longitudinale du centre de gravité (au centre), de la hauteur du centre de gravité (~4cm), de l'empattement du robot (~24cm), d'un coefficient de friction des pneu (bon ~1.5) et de l'accélération courante (_a) et du type de propulsion/traction/intégrale...
weight_front = 0.5f * weight * G - cg_z / wheelbase * weight * _a;
weight_rear  = 0.5f * weight * G + cg_z / wheelbase * weight * _a;
f_traction_max = mu * (four_wheel_drive ? weight * G : ( traction ? weight_front : weight_rear ));
  • Estimation du couple moteur en fonction du régime moteur. Dans le cas d'un moteur électrique, c'est une droite qui commence au couple max à vitesse nulle, et passe par zéro à la vitesse max. Pour ce calcul, il faut paramétrer le couple max (0.03N.m) et la vitesse max (16000RPM) de son moteur (ex. Mabushi 540 d'une 1/10 Tamiya), et connaitre le rapport de réduction de sa transmission (~3.5) de son robot. Il faut au préalable calculer le RPM du moteur en prenant l'allure du robot et la circonférence des roues motrices.
t_engine_max = torque_max * ( 1.0f - current_rpm/rpm_max);
  • Simulation de la force de traction, bornée par la force de traction maximale, en tenant compte d'un rendement de la transmission. 
f_traction = std::min( f_traction_max, t_engine_max * _throttle_setpoint * gear_efficiency * gear_ratio / wheel_radius );
  • Somme des forces donne accélération
_a = ( f_traction + f_braking + fs + f_rr + f_drag ) / weight;
  • Accélération donne vitesse
_v = _v + _a * dt;
Avec ma radio à volant et en paramétrant pour mon robot, je trouve le simulateur assez réaliste. Je n'ai pas simulé le glissement des pneus. Je n'ai pas encore bien compris comment l'implémenter. La vitesse de rotation des roues dépend de la vitesse du robot et de la force de traction, c'est l'œuf et la poule quand je tente de coder ca...
 
Je m'occupe de la simulation des virages maintenant.
 
 
Release v0.08 :
 
 
 
 
 
Reste à Faire :
  • améliorer le modèle physique (virages) et le rendre paramétrable. Préciser la méthode de paramétrage du simulateur (mesures à réaliser sur son propre robot).
  • rendre paramétrable le robot simulé, son apparence (voie, empattement, diamètre/largeur des roues, ...voire skin STL) et la position et l'orientation de ses capteurs
  • améliorer l'apparence du rendu 3D.
  • inclure le circuit de la TRR 110m.
  •  ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...
 
Patrick.


#30 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é 24 septembre 2022 - 12:08

Je n'ai pas simulé le glissement des pneus. Je n'ai pas encore bien compris comment l'implémenter. La vitesse de rotation des roues dépend de la vitesse du robot et de la force de traction, c'est l'œuf et la poule quand je tente de coder ca...

 
 

 

 

Pour ce qui est du fait que les roues patines quand tu es en ligne droite en phase d'accélération ou de décélération  : 

 

Tu as ton moteur qui exerce un couple d'accélération , ce couple essaye de se transférer en totalité en accélération de la voiture en se transmettant des pneus au sol, hors, le sol lui ne peut transmettre qu'une force Fantiglissement au delà de laquelle la roue va glisser. ( dont la valeur dépend de la matière de tes roues, et du poids de ton robot =  coef de frottement )

Tant que le couple d'accélération induit une " force d'accélération " inférieur à Fantiglissement, ton robot ne patine pas. 
Si la force d'accélération dépasse, dans ce cas ton robot va patiner... Le sol effectuera alors une force de résistance FresistanceAuGlissement < Fantiglissement et c'est la seule " force qui sera transmise à ta voiture " et donc qui participera à l'accélération de ta voiture. Le reste est perdu en échauffement entre le sol et les pneus ... Dans ce cas l'accélération effective de la voiture est grandement diminuée, la voiture accélère quand même ( même si moins que prévu ) et à un moment donné la voiture ira suffisamment vite pour qu'il n'y ait plus de glissement ...

Quand tu es en virage tu as une composée qui est à la fois liée à l'inertie de ton virage et à ton accélération et la somme des deux sur chaque roue doit rester inférieur à Fantiglissement... souvent on observe que la force dépasse sur les roues arrière et que la voiture part en tête à queue ... Mais là c'est encore un autre problème un peu plus compliqué ...


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  

 

 

 


#31 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 24 septembre 2022 - 12:31

Oui! Pour la vitesse longitudinale, j'ai implémenté une simple limite de force de traction (cf. f_traction_max ci-dessus), liée à l'adhérence et au poids du robot sur les roues motrices. Au delà de cette limite, la force de traction est bornée, et le couple moteur est en partie perdu. Ca simule le glissement...

 

Si on met de coté, le dérapage franc, ce que je n'ai pas codé est le léger glissement de la roue en régime établi. La vitesse de rotation de la roue n'est pas exactement la vitesse d'avance du robot, il y a un léger glissement qui produit justement cette force de traction (ou de freinage). Je n'ai pas non plus implémenté l'inertie de la transmission... peut être plus tard !

 

C'est compliqué la mécanique automobile... pour le direction, je commence à perdre mes cheveux !  :crazy:



#32 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é 24 septembre 2022 - 05:00

C'est compliqué la mécanique automobile... pour le direction, je commence à perdre mes cheveux !  :crazy:

 

Je te comprend x) 


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  

 

 

 


#33 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté 24 septembre 2022 - 09:28

Pour les virages :

  • la vitesse longitudinale est calculée en fonction de toute les forces (traction, freinage, frottements...), cf post précédent.
  • au niveau de chaque roue, calcul des vitesses longitudinale et latérale à partir des vitesses longitudinales et angulaire du châssis (et de ses dimensions), et estimation de l'angle de glissement
  • au niveau de chaque roue, calcul de la force latérale produite par l'angle de glissement, avec une borne supérieure liée au poids appliqué sur le roue
  • calcul du couple appliqué au châssis engendré par la somme de toutes les forces latérales produites par les roues
  • calcul de l'accélération angulaire du châssis à partir du coupe et de l'inertie du châssis
  • calcul de la nouvelle vitesse angulaire du châssis
  • calcul du nouveau cap du châssis dans le repère 'monde'.

Sur la papier, ca paraissait pas mal ! Quelques constantes à estimer, certaines faciles à calculer car liées aux dimensions et à la masse du robot, d'autres plus faciles à mesurer sur le robot comme la friction des pneus (angle donne force).

 

Au final, le résultat est décevant et le réalisme de la simulation ne se ressent pas au volant. Peut-être des bugs ou des mauvaises constantes ! Je cherche...

Pourtant, j'arrive à reproduire certains phénomènes réels comme le survirage ou le sous-virage en fonction de la charge sur les roues....

 

Le phénomène le plus curieux est que le rayon de braquage ne semble pas dépendre de la vitesse du robot. C'est très perturbant. A basse vitesse ca ne braque pas fort. A haute vitesse, ca braque tout autant qu'à basse vitesse, et du coup ca braque trop fort, et ca rend le robot difficile à piloter en manuel. Trop mou a basse vitesse, trop sensible à la direction à haute vitesse. Ca ne colle pas à la réalité. Il peut manquer quelque chose dans l'approche précédente. Je finissais par imaginer l'effet gyroscopique des roues et a son impact sur le couple et la vitesse du servo de direction... ca me semble chercher un peu trop loin. :Alvarin_07:

 

Patrick.



#34 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é 24 septembre 2022 - 11:07

Pour les virages :

  • la vitesse longitudinale est calculée en fonction de toute les forces (traction, freinage, frottements...), cf post précédent.
  • au niveau de chaque roue, calcul des vitesses longitudinale et latérale à partir des vitesses longitudinales et angulaire du châssis (et de ses dimensions), et estimation de l'angle de glissement
  • au niveau de chaque roue, calcul de la force latérale produite par l'angle de glissement, avec une borne supérieure liée au poids appliqué sur le roue
  • calcul du couple appliqué au châssis engendré par la somme de toutes les forces latérales produites par les roues
  • calcul de l'accélération angulaire du châssis à partir du coupe et de l'inertie du châssis
  • calcul de la nouvelle vitesse angulaire du châssis
  • calcul du nouveau cap du châssis dans le repère 'monde'.

Sur la papier, ca paraissait pas mal ! Quelques constantes à estimer, certaines faciles à calculer car liées aux dimensions et à la masse du robot, d'autres plus faciles à mesurer sur le robot comme la friction des pneus (angle donne force).

 

Au final, le résultat est décevant et le réalisme de la simulation ne se ressent pas au volant. Peut-être des bugs ou des mauvaises constantes ! Je cherche...

Pourtant, j'arrive à reproduire certains phénomènes réels comme le survirage ou le sous-virage en fonction de la charge sur les roues....

 

Le phénomène le plus curieux est que le rayon de braquage ne semble pas dépendre de la vitesse du robot. C'est très perturbant. A basse vitesse ca ne braque pas fort. A haute vitesse, ca braque tout autant qu'à basse vitesse, et du coup ca braque trop fort, et ca rend le robot difficile à piloter en manuel. Trop mou a basse vitesse, trop sensible à la direction à haute vitesse. Ca ne colle pas à la réalité. Il peut manquer quelque chose dans l'approche précédente. Je finissais par imaginer l'effet gyroscopique des roues et a son impact sur le couple et la vitesse du servo de direction... ca me semble chercher un peu trop loin. :Alvarin_07:

 

Patrick.

 

 

Il y a l'effet " ressort " sur la direction dont je t'ai parlé un peu plus tôt qui pourrait correspondre à ce qu'il semble te manquer. Sans ce "ressort" il est normal que le rayon de braquage ne dépende pas de la vitesse du robot. Sans le ressort le seul "effet " qui dépendrait de la vitesse c'est pour un braquage donné si la voiture dérape ou pas ... 


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  

 

 

 


#35 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté hier, 16:04

 

Trois tours en manuel, puis trois tours en automatique. C'est accablant pour le pilote humain !  :angry:

 

La partie simulation physique avance. Le comportement se rapproche petit à petit de la réalité, même si les dérapages sont beaucoup trop prononcés (je simule une propulsion, mais quand même). 

 

En fait, la partie la plus complexe est celle liée à l'adhérence des pneus, avec les formules qui dépendent du "slip ratio" et du "slip angle" pour obtenir les forces de traction et latérale qui s'exercent sur la roue. Il y a des formules magiques aux multiples coefficients, ou des implémentations à base de courbes prédéfinies. Bien sur aucune ne concerne une voiture R/C. Je lis une publication qui explique qu'il vaut mieux mettre des bornes partout dans le code pour obtenir un comportement stable du modèle physique....

 

Reste à Faire :
  • Finaliser un premier modèle physique
  • Rendre paramétrable le robot et le modèle physique .
  • Rendre paramétrable les capteurs installés sur le robot (type, position, orientation)
  • Améliorer les statistiques au tour (vitesse moyenne, vitesse max...)
  • Améliorer l'apparence du rendu 3D.
  • Inclure le circuit de la TRR 110m.
  • Ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...
 

 

Patrick.



#36 Oracid

Oracid

    Pilier du forum

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

Posté hier, 18:17

Courage !  :bye:



#37 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 325 messages

Posté aujourd'hui, 05:36

Bonjour,

 

Ca fait une semaine que j'ai commencé. Maintenant, la simulation physique semble suffisamment acceptable, pour s'intéresser à d'autres points de la simulation. Je laisse reposer la physique.

 

TRRsim.exe a son fichier de configuration XML.

 

 

Pour le mode manuel, il faut renseigner les deux paramètres suivants :

<setting name="direction" value="0">
<setting name="throttle" value="1">

Note : sur un gamepad ps3, direction est sur l'axe 4 dans mon cas, et les gaz sur l'axe 0.

 

 

Ensuite, il faut renseigner les caractéristiques de son robot :

  • masse en kg
  • wheelbase (ou empattement) en m
  • track (ou voie) en m
  • wheel_radius (ou rayon des roues) en m
  • gear ratio (rapport de transmission) se mesure sur le robot: c'est le nombre de tours moteur par tour de roue motrice (>1).
  • cg_z en m : c'est la hauteur du CG au dessus du sol
  • traction = true pour une traction avant, = false pour une propulsion
  • four_wheel_drive = true si c'est une transmission intégrale
  • rpm_max en tours par minute, c'est la vitesse max du moteur (note 16000 RPM pour un Mabushi 540, sinon Kv*7.2 pour les brushless)
  • Drr en m/² (<1) est la décélération en roue libre du robot lorsque la commande GAZ/BRAKE est à 0
  • D en m/s² (<1) est la décélération en freinage du robot lorsque la commande BRAKE est au maximum (sans déraper).

A régler en dernier, car il est rare d'avoir les caractéristiques de son moteur :

  • torque_max en N.m, c'est le couple max du moteur (note : 0.305N.m pour un Mabushi 540, augmenter légèrement jusqu'à trouver les bonnes accélération/vitesse de pointe du modèle dans le simulateur)
<setting name="mass" value="0.8">
<setting name="wheelbase" value="0.300">
<setting name="track" value="0.180">
<setting name="wheel_radius" value="0.028">
<setting name="gear_ratio" value="3.75">
<setting name="cg_z" value="0.04">
<setting name="traction" value="false">
<setting name="four_wheel_drive" value="true">
<setting name="torque_max" value="0.035">
<setting name="rpm_max" value="16000">
<setting name="Drr" value="-1.0">
<setting name="D" value="-10.0">

Les autres paramètres de la simulation physique sont dans le code. Je les reporterai dans une section avancée du XML. Elles ne sont pas mesurables sur le robot.

On ne trouve pas l'angle de braquage max des roues avant. Il est de +/- 45° dans le code, proportionnel à la commande de direction [-1..+1]. A rendre paramétrable si besoin.

On ne trouve pas la position longitudinale du CG. J'ai mis au centre du robot pour le moment. Je pourrai exploiter sa position réelle sans difficulté si besoin.

 

 

Release v0.10 :

 

https://github.com/p...eases/tag/v0.10

 

 

 

Reste à Faire :
  • Pour le debug du moteur physique, afficher les forces, couples, accélérations, vitesses à l'écran avec une touche de fonction (ex. : F6)
  • Adapter le visuel du robot aux caractéristiques du robot dans le XML
  • Rendre paramétrable les capteurs installés sur le robot (type, position, orientation)
  • Améliorer les statistiques au tour (vitesse moyenne, vitesse max...)
  • Ouvrir git public de TRRsim
  • Améliorer l'apparence du rendu 3D.
  • Inclure le circuit de la TRR 110m.
  • Ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...

Fichier(s) joint(s)





Répondre à ce sujet



  


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

0 members, 0 guests, 0 anonymous users