Vous pouvez très bien utiliser mon code pour flypt.
J'pense que je vais assez vite remettre aussi à jour le tensionneur GT.
Quand j'avais fait le GT, le manque de filtrage ne me choquait pas...
Je pourrai ajouter une fonction de filtrage dans le code
Bonjour Lebois
je n'ai pas compris ! de quel code parle t-on ? 
(et ton tensionner GT utilises SimHub et non PtMover... 
)
Le GT utilise simhub via la fonction pwm
Le P1 utilise simhub via le custom protocol et flypt
Le futur GT va utiliser la même control box que le P1 donc :
simhub via custom protocol ou flypt
Par contre effectivement pour le GT avec simhub, il faudra que j'ajoute une fonction de filtrage
EDIT : ceci dit, avec le GT, j'avais pas le souvenir que le manque de filtrage m'avait posé problème....
Mais moi je suis parti sur l'optimisation du GT...
regarde les post no #594 et #595
post no #595 : il y a une capture du paramètre de décélération de SimHub, cette courbe (surligné en jaune) explique ce qu'Eden appelle les "saccades" ou "à-coup" de sa vidéo (post no #594)
Ce point est confirmé en page 25 juste après Eden (avec sa vidéo) par Marc_63, par Banfy211 et moi même maintenant...
Le problème vient de l'acquisition SimHub du paramètre d'accélération (j'ai réussi à trouver qqchose de plus acceptable et jouant sur la plage dynamique et le gamma, mais de base, ça ne va pas !).
Filtrer ce paramètre n'est pas la meilleure solution (car ce filtrage sera aussi présent lorsque tu tapes un mur à 250 KM/H de face)
ce qu'il faudrait c'est avoir une acquisition juste de ce paramètre par Simhub (car j'ai un doute...)
Après si SimHub intègre une moyenne glissante et que le nombre d'échantillon est ajustable entre 1 et 10 (par exemple) on a le loisir de ne pas filtrer (avec 1 échantillon) ou filtrer au niveau souhaité à la volées (une capture montre un filtre avec une moyenne glissante sur 3 échantillons je crois)
Avec filtrage ça fonctionne parfaitement
Avec filtrage ça fonctionne parfaitement
Oui et non car l'Ideal est d'avoir une acquisition juste / linéaire du paramètre d'accélération
Filtrer c'est ajouter un passe bas qui retarde / ralenti la réponse (quand tu prends un mur de face il faut que ce soit rapide / sec ! et si tu fais une moyenne glissante sur plus de 10 ou 20 échantillons ET que ton échantillonnage est lent, ça ne va faire un mur en guimauve)
Après... c'est une question de compromis, il faut prendre en compte les signaux rapides et prendre une constante de temps compatible avec ces signaux
Toutes les simus envoient des données dégueulasses qu'il faut obligatoirement filtrer même si comme tu dis ça ajoute de la latence.
Sur le servo, le filtrage n'apporte pas de latence par contre.
Sur le servo, le filtrage n'apporte pas de latence par contre.
Servo ou pas... dans son principe, un filtrage passe bas ajoute un retard / déphasage (après, il peut être négligeable au regard des signaux les plus rapides quand c'est bien dimensionné)
Par exemple, quand on réalise un filtrage passe bas par une moyenne glissante sur 10 échantillons, lorsqu'on applique un échelon (0 à 100%) il faudra attendre le 5 eme échantillon pour franchir la moitié de la valeur finale => on peut considérer que le retard est d'au moins 5 périodes d'échantillonnage (la période d'échantillonnage étant l'inverse de la fréquence d'échantillonnage)
Toutes les simus envoient des données dégueulasses qu'il faut obligatoirement filtrer même si comme tu dis ça ajoute de la latence.
"dégeulasse..."
As-tu regardé l'info vitesse que SimHub renvoi ? (je l'ai posté sur le screen du post no #596... c'était avec le limiteur à 80 Km/H pour la corréler à l'info accélération avec ses "à-coup" bcp trop prononcés visible sur la capture d'écran du post no # 595).
Normalement, si la vitesse est constante => l'accélération est la dérivé de la vitesse => donc l'accélération est nulle
Sinon, contrairement à l'accélération, l'information vitesse est TRES PROPRE !!! (à ne pas filtrer)
(J'ai vérifié en roulant à toutes les vitesses... accélérant... freinant etc...)
ouai ou en tout cas le filtrage intégré au servo est très efficace... Je pense qu'il doit utiliser des filtres genres RC... parce que j'ai pas ressenti de latence et t'as un filtrage vraiment "onctueux"... alors qu'avec flypt, tu sens toujours que c'est numérique quoi...
Pour la vitesse peut-être parce que t'as le limiteur, mais je sais que quand on utilise la position de la voiture par exemple, la valeur brute est rarement terrible...
ouai ou en tout cas le filtrage intégré au servo est très efficace... Je pense qu'il doit utiliser des filtres genres RC... parce que j'ai pas ressenti de latence et t'as un filtrage vraiment "onctueux"... alors qu'avec flypt, tu sens toujours que c'est numérique quoi...
Mais non ! pas besoin de RC car un servo est un passe bas NATUREL !
Tous systèmes physiques (mécanique ou pas d'ailleurs !...) est un passe bas => il filtre naturellement les signaux plus rapide que sa réponse intrinsèque
autrement dit, un servo qui met en œuvre des pignons (qui réduisent d'autant sa vitesse...) filtre naturellement les signaux rapides (ou "plus rapide que lui")
Pour la vitesse peut-être parce que t'as le limiteur, mais je sais que quand on utilise la position de la voiture par exemple, la valeur brute est rarement terrible...
pas regardé l'info position... (bizarre qd même)
l'info vitesse de SimHub est propre sans limiteur aussi, comme je l'avais écrit dans le message : "(j'ai vérifié en roulant à toutes les vitesses... accélérant... freinant etc...)"
Afficher plusMais moi je suis parti sur l'optimisation du GT...
regarde les post no #594 et #595
post no #595 : il y a une capture du paramètre de décélération de SimHub, cette courbe (surligné en jaune) explique ce qu'Eden appelle les "saccades" ou "à-coup" de sa vidéo (post no #594)
Ce point est confirmé en page 25 juste après Eden (avec sa vidéo) par Marc_63, par Banfy211 et moi même maintenant...
Le problème vient de l'acquisition SimHub du paramètre d'accélération (j'ai réussi à trouver qqchose de plus acceptable et jouant sur la plage dynamique et le gamma, mais de base, ça ne va pas !).
Filtrer ce paramètre n'est pas la meilleure solution (car ce filtrage sera aussi présent lorsque tu tapes un mur à 250 KM/H de face)
ce qu'il faudrait c'est avoir une acquisition juste de ce paramètre par Simhub (car j'ai un doute...)
Après si SimHub intègre une moyenne glissante et que le nombre d'échantillon est ajustable entre 1 et 10 (par exemple) on a le loisir de ne pas filtrer (avec 1 échantillon) ou filtrer au niveau souhaité à la volées (une capture montre un filtre avec une moyenne glissante sur 3 échantillons je crois)
J'ai ces saccades quand le pit limiter est activé sur RF2, plutot sympa comme effet
J'ai ces saccades quand le pit limiter est activé sur RF2, plutot sympa comme effet
Bonjour Banfy
Tu aimes cet effet...
Mais Marc_63 ne l'aime pas...
Même chose pour moi, les effets étaient très mauvais comme sur la vidéo
, surtout au freinage même si je ne touchais que très peu aux freins. Ça venait peut-être du jeu (iRacing) dommage j’ai abandonné et j’ai tout désinstaller.
Ca dépend des gouts !....
MAIS aussi du jeu... de la voiture... ET du réglage de la dynamique dans SimHub
Pour mon relevé ACC ci-dessous, j'ai volontairement accentué un peu l'effet de saccade en augmentant le gain (ou réduisant la plage dans "Paramètres d'effet")
Autrement dit, j'ai réduit la dynamique maximale de l'effet à un peu moins de 2G (la force maxi "théorique" de SimHub est réglée un peu en dessous du double de son poids)
Ce réglage permet de mesurer avec plus de précision l'amplitude de l'oscillation renvoyé par SimHub => on constate que cette amplitude est supérieure à un demi G !!... (voir la flèche jaune ci-dessous) MAIS cette valeur est trop forte si on la corrèle au relevé de la vitesse qui est constante (80 Km/H) voir le post # 596
(car si la vitesse est "quasi constante" => l'accélération est nulle => et ces "à-coup" sont trop forts... d'ou le besoin de filtrage)
Apres il y a un autre problème avec le filtrage :
Dans l'exemple ci-dessus, les "à-coup" que l'on veut filtrer / diminuer sont espacés / lents => leur fréquence est basse
cela veut dire que le filtre passe bas devra couper assez bas pour être assez efficace vis a vis de ces signaux "lents"
MAIS filtrer trop bas impactera les signaux rapides comme un choc avec un mur de face qui ne doit pas ressembler de la "guimauve".
En jouant avec le filtrage du pluging SimHub du post #591 une moyenne sur 5 échantillons glissants est acceptable pour les signaux rapides... mais avec une efficacité visible (mais partielle à mon gout) sur ces "à-coups"
Sur le post dédié à ce tensionneur, je proposais une réponse qui est ajustable en fonction de la vitesse (et la vitesse est précise !). Pour cela, on peut assigner un signal vitesse sur une autre sortie de l'Arduino... ce serait peut-être mieux de le traiter par logiciel (mais ce n'est plus mon domaine)
Ça me paraît compliqué de récupérer les chocs frontaux, et pas forcément souhaitable (car violent).
Mais si tu veux faire ça, j'aurais tendance à dire que le mieux est de récupérer l'information de choc et de l'utiliser
Ça me paraît compliqué de récupérer les chocs frontaux, et pas forcément souhaitable (car violent).
Mais si tu veux faire ça...
Pas du tout ! évidemment il n'a jamais été question de récupérer l'information de choc frontal ET cette information ne servirait a rien !!
je disais que :
1) trop filtrer avec le passe bas limite l'impact du choc frontal
2) le limiteur de vitesse donne des "à-coup" trop fort car sur mon graphe (ou j'ai limité l'accélération) la violence du choc frontal n'est à peine 4 fois plus grande que celle du limiteur à 80 Km/H qui maintient une vitesse quasi constante => DONC qui devrait donner une accélération quasi nulle !!! (OK j'ai un peu triché en limitant la dynamique pour mesurer l'accélération du limiteur, j'avoue ! mais c'est pour mieux montrer car il n'est pas judicieux de jouer avec ce réglage)
Bref, ce que j'ai proposé sur le sujet dédié était de prendre en compte la vitesse que SimHub renvoi (car cette donné est juste, j'ai pu le vérifier)
Un peu a la manière du gamma => ajouter une non linéarité (inverse) pour compenser le problème le linéarité de cette acquisition
Sur le relevé d'accélération, les accélérations faibles sont trop importantes au regard, par exemple, du choc frontal (comme si il manquait la prise en compte de l'inertie) et j'aurai tendance à penser la même chose à basse vitesse
J'avais aussi évoqué une autre idée (pour parer à cette "non" linéarité de l'accélération dans le bas de la plage dynamique) c'était de partir de l'information vitesse de SimHub (qui elle est juste et linéaire) pour la dériver (car l'accélération est la dérivé de la vitesse)
salut j ai actuellement une erreur "403" au lancement du soft ptmover je n ai rien modifier depuis la dernière fois je n ai pas trouvé d infos sur le net à ce sujet @RacingMat 
no idea... mon simu n'est pas opérationnel en ce moment
interpelle le créateur ici ?
