DIY - [Simtools v3] Logiciel pour gérer les simulateurs dynamiques

Oui il faut garder l'ancienne pour pas perdre les réglages

Installer une nouvelle version ne fait pas perdre les réglages, par contre ils proposent un truc qui me semble intéressant maintenant. On peut choisir si les actionneurs se déplacent linéairement (vérins) ou par rotation (moteur/manivelle/bielle), cela peut être intéressant et permettra peut être d'exploiter au mieux les effets. Par contre ce réglage fait perdre les configurations. A tester !

Pas certain que pour une exploitation à 120° le gain soit sensible. Tu en avais fait l démonstration Wanegain en traçant les courbes de linéarité :

Rotation des manivelles 180° à gauche et 120° à droite.

On constate que sur 180° on introduit une erreur de 11% alors qu'a 120° cette erreur chute à 3,5% d'écart maximum par rapport à un vérin qui lui trace une droite parfaite.

Tout ça avec un montage géométrique correct.

Oui je me doute que dans notre cas c'est pas vraiment utile et je ne suis pas certain de ressentir vraiment la différence...

Prenons un déplacement de 180°,

concrètement en action, en jeux, tu dois sentir quoi comme différence ? par rapport a un truc parfaitement linéaire?

étant donné qu'on demande une position dans l'espace j'ai beaucoup de mal a m'imaginer ce que ça change .

j'aimerais connaitre vos avis sur ce point.

Ce que ça change :

On constate que sur 180° on introduit une erreur de 11% alors qu'a 120° cette erreur chute à 3,5% d'écart maximum par rapport à un vérin qui lui trace une droite parfaite.

Dans certain cas tu altères le mouvement de plus de 10% de son amplitude... après le ressenti ???

La parfaite linéarité du mouvement ne peut que te rapprocher de la réalité...

Le plus gros intérêt des 120°, avec la bonne mise en œuvre, c'est que tu parcours la même distance en 1/3 de temps en moins et là, le ressenti a tout à y gagner !

oui mais on place un potentiomètre pour définir le déplacement sur cette distance.

que ce soit pour l'un ou pour l'autre le moteur donne un déplacement, une course et on positionne notre simulateur sur cette course.

Dans tout les cas on déplace le simu sur un point.

Donc concrètement ça change quoi entre les 2 ?

dans les 2 cas on demande au moteur d'emmener le simu sur un point .

pourrait on simplifier, vulgariser en disant que le déplacement suit une ligne droite pour l'un et plus ou moins courbe pour l'autre?

on en déduirait que le trajet est plus long de 10 % pour le non linéaire?

donc il aurait 10% de temps de perdu? mais cela n'est pas vrai sur toute la distance, plutôt au démarrage et a la fin.

Le PID va t'il compenser cela?

il suffit que l'in des ensemble ai une vitesse moins importante ou soit sous dimensionner pour anéantir les efforts !

prenons le cas d'un SCN ou la vitesse en charge chute énormément tout le bénéfice ( 10% au pire des cas ) du linéaire est perdu

la vitesse, la charge, .... tous les autres paramètres rentrent en compte, bref c'est une vrais galère à vulgariser....

Je pense que sur un simu où les dof sont indépendants ça va être difficile de sentir une différence, et à la limite la non linéarité serait presque intéressante pour gommer les saturations éventuelles

Par contre évidemment sur un 6 dof type hexapod à manivelles, c'est primordial de maîtriser ce calcul (c'est bien pour ça qu'aucune plateforme 6 dof sous simtools n'a bougé correctement avant l'arrivé du plugin hexpod il me semble).

On demande une position précise sur cette course, si le calcul de position est bon le déplacement doit être précis et répétitif malgré la linéarité ou non?

Le potentiometre donne toujours la même position lui .

C’est plus dur à calculer car la vitesse bouge en fonction de la courbe non linéaire pour un déplacement par exemple horizontal de la plateforme.

Une fois le bon algorithme en place ça doit fonctionner aussi bien qu’u Vérin linéaire.

D’ailleurs c’est le cas

Sauf qu'avec des pid comme asservissements, le réglage ne peut pas être optimal pour toutes les positions quand ce n'est par linéaire. C'est le cas de pleins de simus, même à vérins, le système à manivelle rajoute juste une non linéarité supplémentaire.

exacte oui c'est vrai! j'avais oublié ce point...

encore un truc de plus qui vient interférer .

le PID est finalement trop basique via un potar.

ça devrait ce régler avec un PID via un encodeur directement au cul du moteur non?

Les problèmes d'optimalité du PID et de non linéarité du système n'ont rien à voir avec le fait qu'on utilise un potar plutôt qu'un encodeur, ni avec le positionnement du capteur (après ou avant le réducteur).

oui ok entre potar et encodeur évidement.

c'est la vitesse de la plateforme elle même qui n'est pas linéaire a cause du mode de motorisation.

il faudrait mesurer la plateforme alors ?

Pas besoin de mesurer la position de la plateforme (et puis tu comptes faire comment ?), "juste" besoin de calculs pour compenser la non linéarité.

ok , je m'interrogeais , mais oui ça semble plus simple , enfin ça dépend pour qui , par le calcul.

pas pour moi !!

Le problème avec les PID que l'on utilise actuellement c'est qu'ils sont fixes. Pour bien faire il faudrait plusieurs PID selon le poids sur le simulateur et peut être même des PID qui s'ajustent si tes manivelles sont dans une position haute/basse...

Après comme dit Etienne, à part pour les 4-6dof à moteurs mixés il n'y a pas trop d'intérêt d'utiliser cette fonctionnalité dans Simtools, c'est surtout pour les déplacement linéaires de la plateforme (surge/sway) que la différence peut être ressentie

effectivement, il faudrait des pid ajustable en fonction de la position, il y a longtemps on en avait parlé. le pid pourrait etre parfait à l'horizontale et pourri à 120°.... apres est ce que ça se resent vraiment en jeux ou ça bouge en permanence, je ne sais pas.

Ça ne bouge pas forcement en permanence, et c'est vraiment étrange un simu qui bouge sans raison.

Un asservissement correct c'est indispensable sur un simu, même si on est d'accord que c'est pas aussi critique que sur un cnc.

Et puis il faudrait déjà que ça fonctionne bien dans une position, ce qui veut dire pas de bruit de capteur et une interface digne de ce nom pour faire le réglage...

Pour l'instant les 2 simus que j'ai testé qui utilisent des PID ne remplissent pas ces conditions (je ne citerais pas les noms )

Et puis il n'y a pas que les PID comme algos d'asservissement... Mais la on est HS

Non je ne dirais rien. En tout cas pas avant d'avoir fait et expérimenté moi même. On en reparlera quand j'aurais mis tout ce qu'il faut dans Node Blue pour faire ça

La commande est un sujet très vaste, qui demande des bases solides en math si on veut un peu comprendre ce qu'on fait. Au delà des maths il y a aussi les problèmes d'implémentation (utilisation hérétique des doubles float sur un AVR 8 bits par ex, bruit de calcul, etc...)