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