Analyse du temps de réponse des systèmes temps réel

[Argii]

Bonjour à tous.

Nous avons commencé les projets depuis peu et un problème me fait face!

Nous travaillons sur une caméra de type webcam qui nous permettra de prendre des images sous-marines. Celle-ci suspendue à un filin, dotée d'un prototype de boitier pour caméra immergé, possédant un dispositif de stabilisation actif permettant de limiter le « ballottement » du aux mouvements de l’eau.
La caméra sera liée à deux servomoteurs disposés de manière à ce que la caméra puisse tourner autour de deux axes différents, ceux-ci programmés sous arduino.

J'essais, à l'heure actuelle, de prévoir le temps que va mettre le système à réagir à une commande.
J'ai fais quelques recherches et j'ai pris connaissance de quelques notions comme : - la pire durée d'exécution / - l'échéance / - la période entre deux réveils.. Mais tout ça reste flou.

Comment dois-je faire pour prévoir le temps de réaction de mon système?
Merci d'avance.
-----

[PIXEL]

du point de vue électrique , devant l'inertie du systéme dans la viscosité de l'eau...
c'est cette dernière qui "pendra le contrôle" ce qui dépendra donc du poids du bathyscaphe , de son hydrodynamisme , et de la puissance des moteurs.

[Argii]

Bonjour et merci pour votre réponse.

Je pense que nous nous sommes mal compris. Notre système est une caméra à l'intérieure d'une demi-sphère fermée par un cube contenant du matériel propre à notre projet.
Ce système sera plongé dans l'eau. Mais la caméra et les servomoteurs ne seront donc pas en contact avec l'eau.

Le but de notre projet est de pouvoir stabiliser la caméra pour avoir une image nette à l'aide de deux servomoteurs (d'axe X et Z).
Le soucis est que je dois prévoir le temps de réponse du dispositif (Carte Arduino; Servomoteurs; Gyroscope) permettant de faire pivoter la caméra pour de stabiliser l'image.

Le fichier ci-joint donne un visu solidworks de notre système.

[gabuzo]

Et si le déplacement de l'ensemble est supérieur à l'espace interieur du cube, ispasqua ?

[A voir en vidéo sur Futura]

[PIXEL]

y'a , toutefois , un truc qui me turlupine ....

une caméra type "webcam" communique donc en USB.

et l'USB passé 10 mètres.... c'est à la ramasse.

ce qui fait court pour une cam sous-marine.

[Argii]

Nous nous sommes posé la question Gabuzo, et voici le rendu à l'intérieur du cube ( ci-joint ). Merci tout de même

Pixel, je suis tout à fait d'accord, j'ai d'ailleurs oublié de préciser que le but de notre projet est d'immerger ce système à 50/100 cm de profondeur environ, pour le moment. Nous améliorerons surement le projet par la suite.

[Argii]

A l'intérieur de la sphère* et non du cube ( Il faut que j’apprenne à être plus clair.. )

[Argii]

Du coup, Comment dois-je faire pour prévoir le temps de réaction de mon système svp?

[Argii]

Quelqu'un ?

[DeConinck]

Bonjour,

Pour moi, le temps de réponse de tes servos ne te permettra jamais de stabiliser correctement l'image.
Voir également le moment inertiel du capteur qui commande le mouvement (Gyroscope 2 axes?).

Dans votre cas, je ne pense pas que l'électronique soit la meilleure des solutions. (A moins que ce ne soit une contrainte imposée).
Un système de balancier à contrepoids mécanique (Désolé, je ne sais plus le nom exacte) aurait certainement de meilleurs résultats sans aucune prise de tête (hors conceptions mécanique ). Çà ne tombe jamais en panne, et le temps réponse est parfaitement métrisable (Fonction de la masse du contrepoids).

Cordialement.
Dimi

[nornand]

regarde du coté de steadicam . c'est une stabilisation mécanique .

[Zenertransil]

Effectivement, en photo, les stabilisateurs (côté capteur chez Sony et Pentax, côté objectifs chez Canon et Nikon par exemple) utilisent des actionneurs piezoélectriques, qui permettent des temps de réponse bien plus courts et des erreurs statiques bien plus faibles (meilleure résolution)... Mais là, ce n'est plus la même paire de manches!

[gedonet]

Bonjour

Le temps de réponse sera facteur du temps de réponse du servo, la vitesse de déroulement dans l'arduino doit être très faible. Je connais peu l'arduino, mais s'il s'agissait de faire la même chose avec un pic et en ayant préparé à l'avance le module PWM, je dirais que le temps de réponse correspond à charger une variable et lancer le PWM environ 5 ou 6 cycles en comptant large, pour un 16F avec un quartz de 20MHz on a 1.2µs.
Je ne sais pas comment sont faites les routines servo sur l'arduino mais en comptant une demi ms on doit être très large, ce qui est probablement faible à coté du temps de réaction du servo en charge lui même .

Gilles

[ftorama]

Bonjour

Le temps de réponse sera facteur du temps de réponse du servo, la vitesse de déroulement dans l'arduino doit être très faible. Je connais peu l'arduino, mais s'il s'agissait de faire la même chose avec un pic et en ayant préparé à l'avance le module PWM, je dirais que le temps de réponse correspond à charger une variable et lancer le PWM environ 5 ou 6 cycles en comptant large, pour un 16F avec un quartz de 20MHz on a 1.2µs.
Je ne sais pas comment sont faites les routines servo sur l'arduino mais en comptant une demi ms on doit être très large, ce qui est probablement faible à coté du temps de réaction du servo en charge lui même .

Gilles

L'Arduino utilisé avec son langage, il faut le voir comme du BASIC. C'est lent, mais ça fait le job. Maintenant, c'est un AVR normalement cadencé à 16 MHz donc si on se base aussi sur 5 instructions, on a 0.3µs.

Mais dans ce cas précis, cela n'a à peu près aucun intérêt. A supposer qu'on utilise un PWM pour piloter le servomoteur (ce qui est plus que probable), la mise à jour de la largeur de pulse ne sera effective qu'après celui en cours. Vu qu'un servomoteur doit être actualisé toutes les 20ms. C'est alors cette valeur qu'il faut prendre en compte. Histoire de compliquer la chose, 20ms est une valeur max et on peut rafraichir les servos à une fréquence supérieure, j'ai déjà fait du 15ms sans problèmes et il faut tester pour voir jusqu'à combien on peut descendre), mais même en descendant très bas, il faudra encore tenir compte du temps de latence interne au servo lui-même et j'ai dans l'idée que ça doit varier énormément d'une marque à l'autre et d'une puissance à l'autre.

Tout cela suppose évidemment que la caméra soit parfaitement équilibrée et donc que seule son inertie mécanique soit à prendre en compte dans les calculs.

Autre point important, qui va décider de la correction à apporter? Le micro lui-même ou un autre? Selon le cas, il faut prendre en compte la communication.

Idem sur le calcul du temps de latence du capteur et du temps de transmission au micro chargé de bouger les servos.

Pour conclure, perso, j'aurais déjà laissé tomber la calculatrice pour faire des essais concrets et surtout je prendrais une approche bien plus globale que le simple temps de réaction de l'Arduino qui sera de toutes façons négligeable devant le reste.

Et pour ce qui est de parler de "temps-réel", ce n'est qu'un terme marketing, on devrait plutôt parler de déterminisme ou de "temps reproductible". Dans une gestion de température, du temps-réel qui réagit en 1 à 2 minutes sera largement suffisant.

Pour du contrôle de servo, je dirais que le but est que toute la chaine acquisition-calcul-mise à jour PWM doit tenir dans le temps de rafraichissement du servo soit 20 ms par défaut

[arsene de gallium]

Pas besoin de processeur et de servo moteur pour faire ça ... sauf si c'est obligatoire pour un devoir.
Un simple système mécanique, comme proposé par deconinck ou nornand est largement suffisant ... surtout dans l'eau où les mouvements sont longs.
Voila le genre de stabilisateur mécanique utilisable pour un appareil reflex (600 g avec objectif):
GENESIS-Yapco-stabilisateur.jpg
Une webcam ne pèse pas lourd donc c'est encore plus facile à réaliser.
Il faut juste un montage à cardan sous la webcam et un contre-poids fixé sur le support de celle-ci.
Maintenant vous pouvez aussi utiliser ça:
36091-museum-1.jpg

[gedonet]

Bonjour

Le système, que Argii semble vouloir faire, ressemble beaucoup à ce que l'on nomme en aéromodélisme, une gimbal ( https://www.google.fr/search?q=gimba...2&ved=0CDoQsAQ ).
C'est:
Soit avec des servos et géré par une carte type arduino qui doit en plus controler le vol d'un multimoteur et c'est remarquable d'efficacité pour garder la stabilité sur deux axes d'une caméra.
Soit une carte autonome, toujours type arduino, avec une IMU genre MPU6050 qui controle la stabilité d'une caméra grace à des moteurs brushless en prise direct. La, c'est la perfection est cela existe aussi en 3 axes.
Dans mon club nous avons les deux modèles et il faudrait pratiquements fixer un théodolite pour mesurer un temps de retard sur la correction du mouvement.

Gilles