44 réponses à ce sujet

[pat92fr]

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.

[pat92fr]

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 :

 

 

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.

 

 

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é.

 

 

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.

 

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)

•  TRRsim.zip   2,39 Mo   72 téléchargement(s)

[Mike118]

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

Le rendu est super en vue de dessous ... 


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

 

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 ! 

[pat92fr]

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)

•  TRRsim release 0.01.zip   2,43 Mo   67 téléchargement(s)

[pat92fr]

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.

 

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. 

 

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.

[pat92fr]

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)

•  TRRsim release 0.06.zip   2,44 Mo   70 téléchargement(s)

[Mike118]

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 =)

[pat92fr]

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.

[pat92fr]

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 :

 

 

https://github.com/p...eases/tag/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.

[Mike118]

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é ...

[pat92fr]

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 ! 

[Mike118]

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

 

Je te comprend x) 

[pat92fr]

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.

 

Patrick.

[Mike118]

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.

 

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 ... 

[pat92fr]

 

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

 

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.

[Oracid]

Courage ! 

[pat92fr]

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)

•  TRRsim release 0.10.zip   2,52 Mo   60 téléchargement(s)

[pat92fr]

Bonjour,

 

Plus j'avance sur ce simulateur, et plus les avancées prennent du temps !

 

 

Physique :

 

Je me suis finalement basé sur le papier de Marco Monster pour l'implémentation, avec quelques touches personnelles.

 

Il reste des imperfections, notamment à très basse vitesse, que je parviendrai peut être à corriger un jour.

 

La touche F6 permet d'afficher le vecteur vitesse (bleu), l'angle de glissement du châssis (bleu) et l'angle de glissement de chaque roue (rouge).

 

 

 

 

Configuration XML :

 

L'intervalle de temps (ms) de la simulation est paramétrable. Il est par défaut cohérent d'un taux de rafraichissement écran de 60Hz. En diminuant l'intervalle de temps, il est possible de 'ralentir' la simulation tout en conservant un affichage rapide. Cela permet notamment de simuler des algorithmes dont la cadence est supérieure à 60Hz dans le robot.

<simulation>
	<general>
		<setting name="timestep" value="16">
	</general>

Dans la configuration du robot, j'ai ajouté un paramètre pour la largeur des roues, uniquement pour le rendu 3D. Cela n'influe pas sur la simulation physique. 

	<robot>
		<setting name="mass" value="1.3">
		<setting name="wheelbase" value="0.260">
		<setting name="track" value="0.150">
		<setting name="wheel_radius" value="0.033">
		<setting name="wheel_width" value="0.025">	<<<<<<<< new !
		<setting name="gear_ratio" value="3.75">
		<setting name="cg_z" value="0.03">
		<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">
	</robot>

Enfin, j'ai ajouté une section pour les capteurs de type LIDAR (benewake) permettant de configurer leur placement et leur orientation.

Les coordonnées XYZ ont pour point de référence, le centre du robot, l'axe X dans le sens de la marche, l'axe Y vers la gauche et l'axe Z vers le haut. Angles dans le sens TRIGO.

J'ai implémenté quatre capteurs de ce type. On pourra faire évoluer le simulateur pour plus de capteur et d'autres types en fonction des besoins.

	<lidar>
		<setting name="left_angle" value="45.0">
		<setting name="left_pos_x" value="0.160">
		<setting name="left_pos_y" value="-0.050">
		<setting name="left_pos_z" value="0.060">
		<setting name="right_angle" value="-45.0">
		<setting name="right_pos_x" value="0.160">
		<setting name="right_pos_y" value="0.050">
		<setting name="right_pos_z" value="0.060">
		<setting name="front_pos_x" value="0.160">
		<setting name="front_pos_y" value="0.000">
		<setting name="front_pos_z" value="0.060">
		<setting name="top_angle" value="60.0">
		<setting name="top_pos_x" value="-0.120">
		<setting name="top_pos_y" value="0.000">
		<setting name="top_pos_z" value="0.060">			
	</lidar>

Rendu 3D :

 

Dans ce registre, c'est la défaite ! Modélisation. Textures. Lumières. Tout est possible, mais je ne suis pas inspiré et cela n'influe pas sur l'usage du simulateur. Je laisse tomber.

J'ai juste adapté le rendu du robot avec les dimensions indiquées dans le fichier de configuration. Le robot sera donc un assemblage de cubes de couleur jaune (teinte Ferrari quand même). 

 

Note : on reconnait bien le TT01 de Tamiya ! Non ? :-)

 

 

 

Gyro :

 

Le simulateur transmet au pilote automatique, les informations d'un gyro virftuel dont les mesures sont entachées d'erreur (gaussienne) et d'une dérive (aléatoire).

struct Cautopilot_inut_sensors
{
    u32 command = 0;
    u32 time_ms = 0;
    f32 lidar_left_distance_mm = 0.0f;
    f32 lidar_right_distance_mm = 0.0f;
    f32 lidar_front_distance_mm = 0.0f;
    f32 lidar_top_distance_mm = 0.0f;
    f32 velocity_mps = 0.0f;          
    f32 angular_velocity_dps = 0.0f;   <<<<<<<<< new ! Gyro 1 axe (vertical) virtuel en degrés par seconde
    f32 manual_direction = 0.0f;
    f32 manual_throttle = 0.0f;
};

Prochaines évolutions & Suite :

 

Je prévois d'implémenter de meilleures statistiques pour pouvoir mesurer et optimiser ses algorithmes de pilotage. On voit déjà beaucoup de choses dans l'état actuel.

 

Je fais un peu de ménage, et je mets le code du simulateur sur un repo Github public.

 

Je passe à autre chose, dans les prochains jours, mais je resterai en support si quelqu'un souhaite utiliser ce simulateur.   

 

 

 

Release v0.13:

 

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

 

 

 

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 ==> ASAP
• Améliorer l'apparence du rendu 3D.
• Inclure le circuit de la TRR 110m. ==> à faire l'année prochaine.
• Ajouter d'autres capteurs simulés : gyro, double-encodeur (solution mike)...

 

Patrick.

Fichier(s) joint(s)

•  TRRsim release v0.13.zip   2,87 Mo   63 téléchargement(s)

[Mike118]

Perso on est méga à la bourre sur la voiture, ( en gros le code de base n'est pas encore fait ) du coup on a pas encore testé la partie simulateurs pour simuler la voiture... Je pense qu'on posera sans doute quelques questions ce week end et qu'on aura plus l'occasion d'utiliser le simulateur pour les épreuves suivantes =)

En tout cas c'est super ce que tu as fait! =)

[pat92fr]

Bonjour Mike,

 

Merci. J'ai implémenté les algorithmes de base pour ma voiture, et j'ai fait quelques tests dans le simulateur. Ca permet de debugger, voir de faire les premiers réglages. Je vous montrerai le week-end prochain !

 

Par contre, je n'ai encore aucune idée du degré de fidélité du simulateur, par rapport à la réalité. Réponse dans quelques jours !

 

Il y aura de nouvelles révisions du simu d'ici la prochaine TRR (2023).

 

Patrick.

 

NB: Pour ce qui est d'être à la bourre, et bien, de mon coté, c'est mal barré. On est dimanche soir, les essais sont dans 5 jours, et je suis en ce moment même en train d'imprimer des supports en PLA pour mes LIDAR....  Courage !