Reglage vitesse sur Slider acceleration/decceleration

Alors voila mon probleme.

Je veux affecter le slider droit au deplacement en tilt de la nacelle Zenmusse H3-3D sur mon Black Snapper.

MAIS je voudrais avoir une acceleration/decceleration de la vitesse lorsque j'actionne ce slider.

C'est a dire pour bien etre compris, partir au debut du mouvement du slider de vitesse zero, puis que la vitesse accelere et en fin de mouvement (qui n'est pas forcement la fin de la course du slider), avoir une decceleration.

Le but de tout cela est d'avoir un mouvement hyper coulé et fluide sans aucun a coup. (pour les pros de l'image, c'est ce que l'on peut faire quand on a une tete fluide professionnelle (type Vinten par exemple) sur un un pied de camera.

Il faut donc ( j'imagine cela en fait) pouvoir avoir une courbe programmée ou quelque chose du genre, qui soit un peu dissocié de la course reelle physique du slider. Le slider servant donc a demarrer le mouvement, l'amplitude du slider servant a determiner la course totale du deplacement. L'arret du slider servant a indiquer le besoin de ralentissement du mouvement puis son arret.
Cela doit forcement induire un leger decalage entre le mouvement physique du slider et le mouvement du deplacement reel.

Si quelqu'un a deja fait cela, ou a une idée, merci d'avance

bonnes vacances a tous

Pour apporter de l'eau au moulin de cette parfaite description du besoin, (merci mg) voici où j'en suis sur ce sujet dans cette vidéo. La deceleration est très perceptible et c'est ça qu'il nous faut.
Mais pour l'instant les petites corrections angulaire reste trop brutales.
<-Video supprimée car caduque->

Mon fichier de config
Le tilt se commande sur RS et sort sur CH6 (DJI Wookong CH5 sur Naza.)
La config est usine à gaz en CH 11 à 16.
Je débute en Taranis (Quelque heures) donc sur qu'il y ait plus simple et plus efficace.
Personnellement une vitesse angulaire rapide ne me gène pas sur de gros changements de consigne d'angle mais c'est l'accel decel qui est ultra important.

Hello,
dans mon cas j'ai besoin d'une vitesse angulaire lente ça c'est ok et facile a faire une decel et accel serait vraiment un plus...
mais aucune idée de comment faire

Alors vraiment pas de solutions efficace et aisée pour l'accel decel?

Ce sujet est ou point mort   alors je vais apporter quelques info pour expliquer ce que l'on veut. Nous sommes quelques un a être venu vers Taranis pour implémenter cela, espérons y parvenir.
Je reviens pas sur le besoin, MG l'a très bien fait, voici ce que j'ajoute.
Sauf plan particulier, pour qu'un mouvement angulaire de camera provoque un scene agréable il doit: Démarrer lentement, atteindre la vitesse angulaire souhaitée elle peu être lente ou rapide, mais doit se terminer par une deceleration lente. Le soucis avec OpenTX est que nous pouvons agir sur la vitesse mais pas sur les Accel Decel.
Illustration de l'effet sur la position en fonction de la vitesse acceleration deceleration pour une consigne de position identique.

D'origine la Taranis reste dans la config centrale. En jonglant avec des mixages courbes il est possible de s'approcher de la config idéale de droite (Mon post précédent).
Là ou je suis bloqué c'est sur les petites modification de consigne, c'est trop rapide. Dans ce cas une vitesse lente sans acc dec conviendrait. Le passage d'un mode à l'autre provoque un a coup qui met tout en l'air.
Donc la question posée au pros Taranis Avez vous un moyen d'agir sur les acceleration deceleration sur OpenTX?
En espérant avoir eclairci le sujet, merci de votre aide

Ma Taranis X9D n’exécute pas un mixage qui fonctionne très bien sous Compagnion.
Toujours dans le même objectif que ci dessus, j'ai trouvé une solution dans compagnion elle fonctionne parfaitement dans le simulateur mais pas sur la radio.
Le fichier de config

L'addition d'une répétition d'une même voie dans une autre mais avec des vitesses et retard différent ne fonctionne pas. En fait seule la non temporisé fonctionne dans la radio, les retardés ne démarre jamais.
Déplacer RS, CH11 dans compagnion accélère bouge puis decelere. Dans la Radio soit rien ne se passe ou seul le mouvement lent fonctionne. 

Je pense que là on est aux limites de possibilités de la Taranis ' de base', AMHA c'est typiquement le genre de choses qui rentre dans le cadre des scripts en LUA..

L’intégration de LUA est à peine démarrée, donc il faudra être un petit peu patient, ou sinon s'y jeter à bras le corps pour le faire, et partager, parce que ce type de mouvement peut être 'sympa' aussi dans d'autres domaines, genre des trappes de train, des volets...

Parfaite implémentation avec un PCB Servo Smoother.

Servo Smoother
Compagion ne peut il pas permettre de faire cela?
Je galère grave depuis 2j pour ralentir fortement en cas de petites corrections, je ne trouve pas d'astuce pour faire la transition entre petites corrections et grande correction.
Lourd dingue pour faire un truc aussi simple en apparence.

jmmaupin a écrit:Lourd dingue pour faire un truc aussi simple en apparence.

Il n'y a rien de simple en apparence !!

Si je comprends tout, tu veux 2 comportements :
- amplitude "importante" : accélération, vitesse nominale, décélération
- amplitude "faible" : vitesse lente

2 comportements différents = choix de l'un ou de l'autre par un inter.

Sinon il faut définir physiquement ce que tu entends par "amplitude importante" : > 10°, à 30°, plus ?
idem pour amplitude faible : < 10° ? moins ?
Quelle vitesse pour chaque mode ?

Au minimum il faut 2 courbes car les pentes de courbe sont complètement différentes.

Le smoother est dédié car il va gérer les différentes phases en fonction de la consigne de départ et de la consigne de fin. A lui de déterminer les différentes transitions et de rmoduler le signal PPM en conséquence.

Pour illustrer le phénomène, voici un schéma qui décrit les interactions Accélération, Vitesse et Mouvement :


et un peu d'explications sur la théorie (qui pourra être implémenté en script LUA)
LA THEORIE
Définition 1 : On définit les variables suivantes
ΔT1 : durée de l’accélération de « sans mouvement » (t0) jusqu’à « la nacelle a atteint sa pleine vitesse » (t1)
ΔT2 : durée du mouvement à vitesse constante de t1 à t2
ΔT3 : durée de la décélération  de « pleine vitesse » (t2) jusqu’à « l’arrêt de la nacelle » (t3)
ΔT = ΔT1 + ΔT2 + ΔT3  : durée totale du mouvement

Δd1 : progression parcourue pendant le délai ΔT1
Δd2 : progression parcourue pendant le délai ΔT2
Δd3 : progression parcourue pendant le délai ΔT3
Δd = Δd1 + Δd2 + Δd3  : progression totale.
On peut parler ici de course du slider ou potentiomètre de -100% à +100%, mais aussi de la durée de l’impulsion PPM au niveau du Naza (ou Wookong ou autre centrale de vol) de 0 à 20 ms.
Quelques rappels :
- d(t) = 0.5 . a(t).t² + v0.t + d0
avec d0 : distance initiale à t0
v0 : vitesse initiale
a(t) : accélération
t : le temps
- d(t) : progression en fonction du temps

- v(t) = a(t).t + v0
avec v0 : vitesse initiale

Définition 2 : On définit A la constante d’accélération du système
- a(t) = A entre t0 et t1 : accélération constante, la vitesse croît linéairement
- a(t) = 0 entre t1 et t2 : vitesse constante nominale
- a(t) = -A entre t2 et t3 : décélération, la vitesse décroît linéairement

Les calculs donnent :
- ΔT3 = ΔT1
- Δd3 = Δd1 = 0.5 . A . ΔT1²
- Δd2 = A . ΔT1 . ΔT2
- Δd = A . ΔT1 . (ΔT1  + ΔT2)
Δd = A . ΔT12 . (1  + ΔT2/ΔT1)

LES CHOIX
Pour aller plus loin, on est obligé de faire un choix de ratio entre  ΔT1 et  ΔT2 .
(On pourrait faire d’autres choix mais inutile ici de les aborder, cela engendrerait d’autres problèmes à résoudre)
Choix 1 : définissons arbitrairement que ΔT2 = 2. ΔT1, donc la durée de la phase vitesse constante est équivalente à la durée d’accélération plus la durée de décélération
(Des essais permettront d’affiner et modifier ce choix)
Les calculs donnent :
- ΔT = 4 . ΔT1 = 2 . ΔT2
- Δd = 3/16 . A . ΔT
- A = 16/3 . Δd / ΔT

Si on veut, une course totale Δd (de -100% à +100%) en ΔT secondes, la valeur de A est simple à calculer. Et elle est suffisante pour tous les calculs.

En script :
A est fixé comme constante.
LIMITE : valeur qui sépare un petit mouvement lent d'un mouvement avec accélération et décélération

si ( |ConsigneFinale - ConsigneDepart| < LIMITE) {
 Appliquer_MouvementComplexe(); // cf formule avec accélération
} sinon {
 Appliquer_MouvementLent(); // cf formule linéaire avec un simple coefficient multiplicateur
}

Il faut bien sûr tenir compte des paramètres de la nacelle (gain PID) qui déterminent une vitesse de rotation des moteurs.

En résumé :
Le problème est complexe et la Taranis de base ne peut répondre totalement à ta demande.
Le passage a un script me semble obligatoire.

(j'espère ne pas avoir trop gavé les membres avec toute la théorie   )

L'approche me semble plutôt bonne, mais je pense qu'il est possible de simplifier, je ne suis pas sur que la correction de vitesse en fonction de l'amplitude du mouvement soit requise...

Vu qu'il faut un amortissement, donc une vitesse de déplacement qui se réduit quand la position est proche de la consigne, cette vitesse basse sur les corrections mineures se ferait naturellement..

Pour aller plus loin, ça me semble pertinent de 'fixer' les termes et variables, ce script ayant de fortes chances d'être réutilisé, je propose de le faire en anglais...
PositionTarget = cible constante pour le servo
PositionFinalTarget = cible, "la valeur du potentiomètre"
ServoPosition = la position du servo
ServoSpeed = la vitesse de défilement à l'instant T
ServoMaxSpeed = la vitesse de défilement max (fixé comme entrée)
ServoAcc = l'accélération de défilement (fixé comme entrée)
ServoMaxAcc = l'accélération de défilement max (fixé comme entrée)

en ébauche brutale (attention, fait à l'arrache ! )on aurait quelque chose du genre

if ServoAcc > ServoMaxAcc {
ServoAcc = ServoMaxAcc }; # Limitation de la valeur d'accélération

if ServoSpeed > ServoMaxSpeed {
ServoAcc = 0 }; # Limitation de la valeur vitesse

PositionTarget = ServoPosition - ( ServoPosition + ServoAcc)

Il manque des bouts, mais c'est juste pour amorcer :p

En fait il n'y a pas besoin de calculer la vitesse.
x valeur de sortie est fonction de A (constante de l'accélération qui détermine la vitesse max de la partie linéaire) et du temps.
pour la variation lente, c'est un simple coefficient en fonction du temps

Au final, avec 3 constantes on a tout !
- ratio entre  ΔT1 et  ΔT2
- Constante de l'accélération du mouvement : A
- Constante de vitesse pour le mode faible amplitude x = B.t

Il y a de grande chance que l'implémentation se fasse par palier: delta de temps (dt) => delta de consigne (dx)
... car la consigne peut changer à tout moment.

Bref, comme tout cahier des charges, il faut spécifier le comportement attendu pour tous les cas.

L'autre possibilité est de recréer le smoother à partir d'un microcontroleur PIC ou ATMEL, mais là peu de membres pourront le customiser.

Alex, à plusieurs on va pouvoir arriver à un résultat "universel" :-)

Pour ma part, il me reste à savoir comment la radio donne la main au script, débranchement total type interruption ou gestion par événement ou timer type multi threading, etc. (J'ai commencé seulement hier soir LUA   )

EDIT :
les scripts LUA sont appelés au mieux tous les 30 ms (sans garantie).

Non la théorie ne me gave pas bien au contraire je programme à longueur d'année des servos moteurs industriel et leurs fait faire des truc bas banal, bref je m’éclate avec ça . D'où ma frustration de galérer autant sur la Taranis pour faire quelque chose qui ne devrait pas être compliqué.
Merci de votre intérêt pour ce sujet qui semblait n’intéresser personne, alors qu'effectivement ce type de mouvement est générique.
Actuellement je suis sur mon lieu de tournage il me reste 15j pour faire ce que j'ai prévu c'est très mal partit, car je n'ai rien fait vu que je n'arrive pas a gérer correctement le tilt de ma nacelle. Donc je cherche une config avec les fonctions de base au plus vite qui me permette de faire au moins quelque chose. Je ne me risquerais pas a passer en firmware 2.xx vue les galères de certains.

A mon retour je passerais ma radio en 2.0.8 et étudierais les lua.
Pour l'Anglais dans les scripts 100% OK je ne développe qu'en Anglais, variables plus courtes commentaires plus court, c'est international ...

Pour simplifier le codage je partirais sur cette façon de faire qui s'adaptera aussi au petites variations de consignes qui elles, n’atteignent jamais la vitesse max donc la distance de deceleration est variable.
On défini une vitesse max, Une acceleration.
Un écart entre consigne et position réelle survient.
Augmentation de la vitesse positive ou négative suivant l'acc définie.
Vitesse max atteinte ou Mi course atteinte ->(mémorisation de la vitesse en cour pour le calcul de la decel immédiate.).
On passe sur une vitesse proportionnelle a l’écart entre consigne et position courante.
Ceci provoque un décélération très lente idéale pour une camera.
Si l'on veux une decel plus rapide on peu passer par une courbe entre l'ecart et le ratio de vitesse. Comme courbe je prend des sections de LOG entre X>1 une valeur.
Ça c'est quelque chose que j'e pratique couramment.

Mais c'a n'est que mon opinion.
Sinon si mi course atteinte avant VMax on calcule la dec par Vcourante / Tdec et on l’applique.

Je vois que de toute façon le sujet est maîtrisé par Belov.

Hello Belov!
Si je remets tes idées dans un ordre différent, on obtient :

Belov a écrit:L'autre possibilité est de recréer le smoother à partir d'un microcontroleur PIC ou ATMEL,

Belov a écrit:Alex, à plusieurs on va pouvoir arriver à un résultat "universel"

Et dès lors la phrase

Belov a écrit:mais là peu de membres pourront le customiser.

...devient moins importante... Si le résultat est universel, plus (ou en tout cas, beaucoup moins) besoin de le customiser...

En tout cas, le sujet est passionnant !

Autre point : Quid lorsque la consigne change alors que l'on est en mouvement ? On ralenti plus vite et l'on repart dans la bonne direction ? On attend la fin du mouvement avant de prendre le nouveau en compte ?

Ce qui m'amène à la question suivante :
Si je comprends bien, dans la version actuellement discutée, la position du manche (du slider, du bouton..) détermine la position finale atteinte. Il faut donc déterminer le type de déplacement, (court ou long) et l’accélération d'entrée et de sortie de mouvement.
De plus, dans ce cas, se pose le problème  du changement de consigne avec décélération immédiate pour stopper (éventuellement) le mouvement et repartir vers la nouvelle consigne...

Ne serait-il pas plus simple de piloter la vitesse de rotation en fonction de la positon du manche ? Manche un peu incliné, vitesse lente, manche à mi-course:  vitesse moyenne, ... (Un peu comme un variateur de vitesse) Ainsi, l'opérateur Caméra a toujours le contrôle de ce qui se passe... Doit-il, pour une excellente raison, braquer à fond dans l'autre direction, il peut le faire à la vitesse qui lui semble appropriée.
(Je n'ai pas dit que ce serait plus simple à programmer dans la Taranis )

Bien à vous,

Coyotte

Ça c'est un sujet intéressant avec des moyens mis en communs pour résoudre la problématique.

ça me plait bien, vais suivre ce post assidûment.

CoyotteDundee a écrit:Ne serait-il pas plus simple de piloter la vitesse de rotation en fonction de la positon du manche ? Manche un peu incliné, vitesse lente, manche à mi-course: vitesse moyenne, ... (Un peu comme un variateur de vitesse) Ainsi, l'opérateur Caméra a toujours le contrôle de ce qui se passe... Doit-il, pour une excellente raison, braquer à fond dans l'autre direction, il peut le faire à la vitesse qui lui semble appropriée.

Certaines nacelles comme la Tarot ont 2 modes d'utilisation du tilt :
mode 1 : la position du slider indique la position finale (ce que veut JM)
mode 2 : la position du slider (ou stick) indique le sens de rotation et la vitesse de rotation. Plus le stick est à fond, plus la vitesse de rotation de la nacelle est rapide. (ce que tu décris Coyotte)

Dans le mode 1 : la variation de position implique la forme et la vitesse du mouvement. Ex Variation de plus de 15% (sur une échelle de -100 à +100%) on passe à la forme accélération/décélération sinon on reste sur une variation lente classique.

Dans le mode 2 : la variation de vitesse est asservie à l'amplitude du stick. Le retour au neutre signifie vitesse 0. Dans ce mode, on peut imaginer que lorsqu'on lache le stick pour un retour au neutre, le mouvement garde une inertie pour avoir le phénomène de ralenti.
Là ça devient compliqué d'expliquer que par des mots   

Bonjour Belov,
Non, c'est très clair... :-)
Dans le premier cas, c'est un ralenti; dans le deuxième, de l'inertie...

Coyotte

Enfin un tilt de nacelle Zenmuse H3-3D utilisable
Le concept de la config en bref.
- La somme de 50% des 2 sliders est envoyé en doublon vers 2 autres voies.
- Ces 2 voies sont ralentie à des vitesses différentes.
- Une soustraction est faite entre la rapide et la lente. Cette différence augmente sur un changement de consigne puis diminue a l'approche de la destination.
Reste a utiliser cette différence pour accélérer decelerer le mouvement.
Si on ajoute a la voie lente le produit d'une constante * par cet écart on a une accel pas mal mais pas une bonne decel.
Si on ajoute encore a cela une fraction de cet écart la decel est améliorée et on a un truc pas trop mal.
Mon fichier de config Compagnion pour Wookong pour un Naza seule la voie Zenmuse passe de voie 6(Wk-M) à 5(NZ-M).
Je vais utiliser cette config délirante en attendant le Bon firmware de DJI    (31 février 2060 normalement)
Ou via le script Lua, mais c'a c'est aussi pour plus tard.

Ma vidéo d'essais de variation de tilt.

Hello
après une nuit à trouver la solution pour envoyer les infos de tilt vers la sortie adéquate, voici un 1er script fonctionnel mais en version ALPHA (peu de tests réalisés)
F550, zenmuse H3 3D, Naza V2

Tilt1.lua.zip - 2 KB

Le script est à mettre dans le dossier SCRIPT/MIXES
Sur la taranis, modifier le mix de la voie concernée (voie 5 pour le Naza) et mettre en source LUA1a ou CH16 si vous voyez le nom de la variable.


Le tilt est géré par le slider de droite dans le programme.

Les limites du script :
- version alpha (ou même pré-alpha c'est dire !)
- Il faut laisser la course jusqu'au bout avant de changer de position car pas adapté lorsqu'on modifie le slider alors que le tilt est déjà en mouvement (dans le TODO)
- le ratio de 1 dans le programme signifie que la durée d'accélération = la durée du mouvement continu = la durée du ralentissement
- dureeCourse = 5, par défaut, cela veut dire que le tilt mettra 5s pour aller de -100% à +100%. Si on veut un mouvement plus lent, il faut augmenter ce nombre

Merci de vos retours

TODO :
- adapter intelligemment une modification de la consigne alors que la nacelle est en mouvement (il faut effectuer une diminution de la durée de mouvement continu T2 et non une réadaptation de toutes les durées)
- sécurisé le programme, variable, données, etc.
- universaliser si possible (décontextualiser les données)
- bâtir un set de courbes à présélectionner
- documenter et faire un tuto complet (à venir)
- poser le lambris car madame Belov me fait les gros yeux ;-)

Pas de retour ?

Si. Merci pour cette énergie sur le sujet.
Compagnion peut il permettre de tester le script?
J'ai essayé sans succès mais comme je débute sur Taranis j'ai forcément commis plusieurs erreurs.
J'ai mis le contenu de la µSD dans le dossier µSD de companion mis le ficher comme tu l'a dis, fait le mix comme indiqué, mais échec. Je vais prendre un moment pour y regarder car ton post m'a éclairci sur les capacités de la radio, et ca me botte bien pour m'y coller.

Actuellement comme j'ai une bonne solution qui me dépanne bien et que je vole tout les jours je ne vais pas risquer une update vers OpenTX qui vu les galères de certains risque de ma planter la radio.

Tes réglages sont complexes mais fonctionnent bien : la vidéo est très agréable.

Pour tester vraiment, il vaut mieux le faire sur la Taranis.
Avec Companion les temps sont multipliés par 10 ! J'ai cru à une erreur de calcul au début. Mais cela fonctionne quand même. Ce qui prend 5s sur la Taranis mais 50s sur Companion Mac

Mets la taranis en mode USB (les trim horizontaux à loucher au centre et switch on de la radio), puis connexion du cable USB
un disque NONAME (sur mac il s'affiche comme ça) est dispo.
dedans il faut créer le dossier SCRIPT, puis dedans le dossier MIXES (Murphi a fait un super tuto la dessus)
tu mets le fichier .LUA dans MIXES

Une fois la radio allumée à nouveau, tu choisis le modèle, tu peux le dupliquer par sécurité, dans la page 12/13, il faut choisir pour LUA1 le script tilt1.lua
Quand tu valides, il affiche les variables de sortie. Si tu joues sur le slider de droite, la variable CH16 va changer

ensuite tu vas dans MIXAGE, tu choisis la voie qui gère le tilt (5 sur Naza, 6 sur WK) et tu choisis pour Source soit "LUA1a", soit "CH16" (c'est à dire la sortie du script). Par défaut le programme utilise le slider droit comme point d'entrée.

Je travaille sur l'amélioration de ce script (il y a du boulot !) en particulier lorsqu'on change la consigne pendant que le tilt est en fonctionnement. Tu verras des effets indésirables.

Tes retours sont importants pour orienter les améliorations.

Actuellement ma radio est en FW v1.1.02 origine constructeur, donc je ne peu pas tester le script.
Comme je le disait, en pleine période de tournage aérien utilisant ma config imparfaite, je ne me risquerais pas a perdre du temps à la passer en OpenTX 2.x.x, vu les galères que j'ai lues. D'autan que j'ai essayé, il y a 15j, driver installé avec Zadig correct dans le gestionnaire de périphérique alors que Compagnon ne détecte pas la radio; DFU Erreur... La radio est bien éteinte. La méthode me semble bien hasardeuse, j'ai pas confiance.
Je regarderais ça durant ma prochaine période creuse. Un week end à la maison sans vol prévu.
J’espère ne pas être le seul intéressé afin que d'autres testent le script et apporte des retours.
Ce script suscite le plus grand intérêt pour moi et même mon seul espoir d'avoir quelque chose de parfait. Je ne compte plus sur le FW Zenmuse de DJI.

C'est vrai qu'en tournage, tu n'as aucun intérêt à modifier ce qui fonctionne.
En tant que pro, je te conseille une 2e radio pour un secours de la 1re au cas où et pour justement tester les mises à jour de firmware.

Je vais rédiger des spécifications car autant l'dée générale semble simple, autant la prise en compte de tous les cas de situation est vraiment complexe : modification de la consigne pendant la phase d'accélération, décélération, comportement si le sens change, etc. Je pense que là les attentes de chacun peuvent être différentes.

En évolution suivante : la 3D, tilt, roll, yaw.

Je ne suis pan encore pro mais c'est mon intention.
Exact une 2ème radio est une option que j'ai fortement envisagé vu le coût des Taranis