Bonjour,
Je cherche un servo moteur tres silencieux (<30db) pour faire tourner (a distance et sans fil) une bague de mise au point d'objectif d'appareil photo dslr (type canon 5d mark2).
Ce servo devra pouvoir fonctionner sans gêner l'ingénieur du son et le perchman pour la réalisation d'un documentaire.
Ce servo ne doit pas être trop lourd (<100g) ni trop long (<50mm) et simple a connecter a une carte arduino uno.
Merci d' avance pour votre aide
Bonjour,
Sur un 5D mkII j'utilise un moteur pas à pas Nanotec en direct drive et micro-pas pour piloter le follow focus en déporté ou en programmé.
C'est précis, fluide et silencieux. AMHA c'est beaucoup mieux qu'avec des servos.
Avec une Arduino on peut gérer avec fiabilité le backlash, le ramping et des time keys, mais ce n'est pas simple en programmation (!).
Merci bcp Ekaki pour cette réponse rapide et enthousiasmante.
Je souhaite adapter ce wireless follow focus sur un steadycam pilot. Les solutions actuelles de wireless follow focus sur le marché sont chères (bartech >4500 €, hocus focus >1500€) ou décevantes (okii, jag35). Il y a donc une opportunité pour une solution peu chère, silencieuse et précise. Je suis débutant sur arduino. Je cherche un partenariat pour ce projet. Idéalement sur Paris...Mon tel : 06 85 085 794.
Peux tu être plus précis sur le modèle de moteur pas a pas de chez nanotec? (Le plus petit et léger sera le mieux). Avec quel capteur puis je le contrôler? J'envisage la connexion wireless par xbee pro.
Prasamoe:
Bonjour,Je cherche un servo moteur tres silencieux (<30db) pour faire tourner (a distance et sans fil) une bague de mise au point d'objectif d'appareil photo dslr (type canon 5d mark2).
Ce servo devra pouvoir fonctionner sans gêner l'ingénieur du son et le perchman pour la réalisation d'un documentaire.
Ce servo ne doit pas être trop lourd (<100g) ni trop long (<50mm) et simple a connecter a une carte arduino uno.
Merci d' avance pour votre aide
bonjour
en complément de la réponse de Ekaki
je ne connais pas le follow focus, mais basiquement je pense que l'on peut réduire ça à du micro-deplacement à vitesse variable ?
peut être voir du coté des petits moteurs CC à encodeur en bout d'arbre, ça se commande facilement avec un arduino en PWM pour la vitesse et la precision du déplacement par lecture de l'encodeur et dans ce genre d'application un seul canal suffit puisque le sens de déplacement est connu (action de l’opérateur)
par exemple avec ça
http://shop.snootlab.com/adafruit/93-adafruit-motor-shield-for-arduino.html
ou ça
http://www.lextronic.fr/P5073-platine-de-commande-de-moteurs-dc.html
exemple de moteurs
Prasamoe:
Merci bcp Ekaki pour cette réponse rapide et enthousiasmante.Je souhaite adapter ce wireless follow focus sur un steadycam pilot. Les solutions actuelles de wireless follow focus sur le marché sont chères (bartech >4500 €, hocus focus >1500€) ou décevantes (okii, jag35). Il y a donc une opportunité pour une solution peu chère, silencieuse et précise. Je suis débutant sur arduino. Je cherche un partenariat pour ce projet. Idéalement sur Paris...Mon tel : ****.
Pas de soucis, c'est avec plaisir -.^
Mais pour ton téléphone, si j'étais toi je modifierais les message pour ne pas qu'il apparaisse ici, c'est un forum public et il y a moyen de voir cela en privé via les messages.
Pour les détails, j'utilise un système avec mattebox, rings et follow focus RedRock en intégrant la commande sur l'axe démultiplié de ce dernier et en me servant du ring adjacent comme support pour le moteur. Ce qui en fait un ensemble loin du poids plume mais homogène et assez rigide.
En partant de la base du steadicam Pilot il y a certainement moyen si l'on fait attention au poids comme tu le mettais en avant, mais il faut compter le poids du moteur (celui que j'utilise fait 200g), de son système de fixation (en aluminium cela peut être assez léger, genre 50g) et du système mécanique/électronique de liaison.
Prasamoe:
Peux tu être plus précis sur le modèle de moteur pas a pas de chez nanotec? (Le plus petit et léger sera le mieux). Avec quel capteur puis je le contrôler? J'envisage la connexion wireless par xbee pro.
Pour le moteur que j'utilise, voici la référence :
-> http://en.nanotec.com/steppermotor_st4209.html
En version ST4209S1404 pour une question de couple/inductance.
Je l'ai choisi aussi pour question de taille (il est relativemant petit; 42x33mm), et de poids/couple/précision (pour un moteur il est relativement léger et efficace).
Et Nanotec pourquoi (je n'ai pas d'actions chez eux) : Parce qu'après en avoir eu pas mal entre les mains (une partie de mon taf') c'est ce que j'ai trouvé de mieux en rapport qualité/prix. Les moteurs équivalents "no name" ou autre perdent beaucoup trop de pas pour les utiliser dans un système de MAP, ce n'est pas assez fiable, et il sont loin d'être aussi silencieux.
On pourrait imaginer en prendre un plus petit encore, et donc moins puissant, mais avec certaines optiques comme les Zeiss ou les Iscorama cela risque d'être très(trop) juste car la bague à une certaine résistance (fluide). De plus j'utilise un autre moteur pour le focal shift, donc j'ai pris les deux mêmes, tout en sachant que les bagues de focale sont dures elles aussi (même sur un 24-70).
Pour le capteur, en utilisant des moteurs PàP il n'y en a aucun à prévoir, à la base.
On peut mettre en place un système d'asservissement en fonction de la température afin de corriger la MAP en fonction de la dilatation de l'optique, mais pour des travaux "normaux" ce n'est pas utile. J'utilise cela uniquement pour les prises de vue scientifiques.
Et pour le système de pilotage à distance sans fil, XBee c'est bien, pas de soucis avec l'Arduino. On peut aussi utiliser un système BT. En fait tout dépend de la distance prévue.
Sur ce point je ne suis pas super calé, je pense que d'autres membres ici pourront donner des solutions optimales ^.^" Perso' je pilote à distance en filaire via une machine, qui elle-même peut être piloter par WIFI si elle est à distance mais c'est un peu l'usine; il y a moyen de faire plus simple.
Artouste:
bonjour
en complément de la réponse de Ekaki
je ne connais pas le follow focus, mais basiquement je pense que l'on peut réduire ça à du micro-deplacement à vitesse variable ?
peut être voir du coté des petits moteurs CC à encodeur en bout d'arbre, ça se commande facilement avec un arduino en PWM pour la vitesse et la precision du déplacement par lecture de l'encodeur et dans ce genre d'application un seul canal suffit puisque le sens de déplacement est connu (action de l’opérateur)
(...)
L'utilisation d'un moteur CC est possible mais il faut un encodeur très précis. La MAP (Mise Au Point) variant du "net" au "pas vraiment net" sur une fraction de degré sur la bague de l'optique, et aussi pouvoir balayer tout un secteur angulaire et ensuite pouvoir revenir précisément au point d'origine. Il faut donc un encodeur ayant une précision de l'ordre de la minute d'arc (au moins), ce qui est assez onéreux. Cela revient quasiment à acheter une solution toute faite d'un point de vue financier.
ekaki:
Artouste:
bonjour
en complément de la réponse de Ekaki
je ne connais pas le follow focus, mais basiquement je pense que l'on peut réduire ça à du micro-deplacement à vitesse variable ?
peut être voir du coté des petits moteurs CC à encodeur en bout d'arbre, ça se commande facilement avec un arduino en PWM pour la vitesse et la precision du déplacement par lecture de l'encodeur et dans ce genre d'application un seul canal suffit puisque le sens de déplacement est connu (action de l’opérateur)
(...)L'utilisation d'un moteur CC est possible mais il faut un encodeur très précis. La MAP (Mise Au Point) variant du "net" au "pas vraiment net" sur une fraction de degré sur la bague de l'optique, et aussi pouvoir balayer tout un secteur angulaire et ensuite pouvoir revenir précisément au point d'origine. Il faut donc un encodeur ayant une précision de l'ordre de la minute d'arc (au moins), ce qui est assez onéreux. Cela revient quasiment à acheter une solution toute faite d'un point de vue financier.
Bonsoir
pas de probleme, je n’émettais qu'une idée sur un domaine que je ne connais pas (contraintes) , ceci étant on trouve couramment des encodeurs optiques "cheap" de 200 ou 400 CPR .
Mais puisque le pap evoqué rempli bien sa fonction, c'est inutile de réinventer la poudre. 
le PAP est drivé par quoi ? tu gère le micro pas sur quelle profondeur 2,4/8 ?
Artouste:
Bonsoir
pas de probleme, je n’émettais qu'une idée sur un domaine que je ne connais pas (contraintes) , ceci étant on trouve couramment des encodeurs optiques "cheap" de 200 ou 400 CPR .
Mais puisque le pap evoqué rempli bien sa fonction, c'est inutile de réinventer la poudre.
le PAP est drivé par quoi ? tu gère le micro pas sur quelle profondeur 2,4/8 ?
Y'a pas de mal non-plus -.^
Et tout à fait, on trouve des encodeurs de quelques centaines de marques par tour pas trop cher, mais pour bien faire la MAP il faudrait plusieurs milliers. On pourrait aussi imaginer utiliser une moto-réduction cheap aussi mais les jeux induits sont trop importants, ainsi que le bruit.
Dans le système que j'utilise les PàP sont piloté en puissance par un IC Allegro. Je trouve qu'il est assez flexible et facile à mettre en oeuvre, performant et adapté à l'utilisation. En même temps il y en a d'autres, c'est juste une préférence personnelle car j'ai pas mal développé sur EasyDriver à un moment ^.^
Le pilotage se fait en quart ou 8ème de pas en mode lent pour une précision optimale (position encodée sur 16bits pour les tracking de sujets ou lorsqu'il est piloté par l'avance de l'ensemble de prise de vue sur un chariot de traveling ou sur un boom numérique) et en demi pas pour les utilisations en mode haute vitesse (12bits pour une variation de la MAP du minimum au maximum en moins de 2s). Les deux modes pouvant être basculés de manière transparente grâce au positionnement référentiel possible avec les moteurs PàP.
Bonsoir,
Ça va p-e paraître bizarre mais pourquoi vouloir utiliser un moteur externe alors qu'il y en a un dans le caillou, a fortiori encore plus si il est ultra-sonic donc théoriquement fin/précis et silencieux 
Je parle de ça parce que j'ai testé Google Code Archive - Long-term storage for Google Code Project Hosting. avec mon 7D pour la MaP à fine granularité.
En adaptant légèrement le code il serait tout a fait possible d’asservir avec un téléphone (cas présent), un PC via liaison USB ou un module XBee, non ?
D.
ekaki:
Dans le système que j'utilise les PàP sont piloté en puissance par un IC Allegro. Je trouve qu'il est assez flexible et facile à mettre en oeuvre, performant et adapté à l'utilisation.
3967 ?
Si oui, c'est bien sympa à gérer
bbs:
Bonsoir,Ça va p-e paraître bizarre mais pourquoi vouloir utiliser un moteur externe alors qu'il y en a un dans le caillou, a fortiori encore plus si il est ultra-sonic donc théoriquement fin/précis et silencieux
Bonjour bbs,
Tout à fait; c'est une solution très pratique.
Cependant, il faut une optique USM pour que cela soit vraiment valable et en vidéo il est plutôt courant d'utiliser des optiques sans cette technologie, voir même courant d'utiliser des optiques qui ne sont pas AF (MAP manuelle).
bbs:
Je parle de ça parce que j'ai testé Google Code Archive - Long-term storage for Google Code Project Hosting. avec mon 7D pour la MaP à fine granularité.
En adaptant légèrement le code il serait tout a fait possible d’asservir avec un téléphone (cas présent), un PC via liaison USB ou un module XBee, non ?D.
J'ai déjà vu ce genre de manip' et il m'arrive quelques fois d'utiliser un ordinateur pour piloter tout cela via un soft maison, mais à ma connaissance je n'ai pas entendu parlé de portage du SDK Canon sur Arduino. Je ne sais même pas si c'est possible, pour une question de puissance de traitement (?). Et cela complique l'affaire, avec la nécessité d'un port USB maître etc.
Artouste:
ekaki:
Dans le système que j'utilise les PàP sont piloté en puissance par un IC Allegro. Je trouve qu'il est assez flexible et facile à mettre en oeuvre, performant et adapté à l'utilisation.3967 ?
Si oui, c'est bien sympa à gérer
(...)
A3967, A3977, ... De manière général la série A39xx ^.^
En fonction des besoins en puissance ou du cahier des charges.
Je confirme que ce sont des IC vraiment sympa', le seul reproche que j'ai tendance à leur leur faire serait leur inadaptation à recevoir un refroidissement passif correct.
Même le A3992 dont je suis fan (1/32ème de pas, 1.5A, osc. interne 4MHz, DAC 6bits, etc.) en version DIP24 n'est pas forcément facile à refroidir.
ekaki:
J'ai déjà vu ce genre de manip' et il m'arrive quelques fois d'utiliser un ordinateur pour piloter tout cela via un soft maison, mais à ma connaissance je n'ai pas entendu parlé de portage du SDK Canon sur Arduino. Je ne sais même pas si c'est possible, pour une question de puissance de traitement (?). Et cela complique l'affaire, avec la nécessité d'un port USB maître etc.
En fait ça utilise le shield USB et ça pilote l'APN via le standard PTP (avec la lib faite par le monsieur qui a fait le shield).
Oleg a aussi fait un assistant pour le "focus stacking".
Seul regret, le 7D + l'objo n'exposent pas la distance de MàP, cela aurait grandement facilité l'opération avec un calcul de DoF 
Il y a aussi http://www.instructables.com/id/Building-the-YaNis-EOS-Controller/sur le même thème.
Les sources coté arduino sont sur github. Pour ce que j'en ai vu, l'arduino prends des commandes simple sur le port série (chez Yanis) ou plus complexes chez Crisp Concept (il faut encore que je reverse enginer les commandes envoyé par le téléphone, la partie Android n'étant pas OS).
D.
[/quote author=ekaki link=topic=78926.msg598276#msg598276 date=1321458117]
il m'arrive quelques fois d'utiliser un ordinateur pour piloter tout cela via un soft maison, mais à ma connaissance je n'ai pas entendu parlé de portage du SDK Canon sur Arduino. Je ne sais même pas si c'est possible, pour une question de puissance de traitement (?). Et cela complique l'affaire, avec la nécessité d'un port USB maître etc.
[/quote]
L'Okii follow focus permet de faire la MAP et bien d'autres fonctions (vitesse, iso, diaph...). Okii est developpé en Arduino. La société okii envoie le code a tous les acheteurs et je l'ai reçu, mais ce code est assez compliqué.
Piloter l'AF via le protocole PTP ?
Mhmm... Compliqué tout ça, non ?
En tout cas je n'aurai pas imaginé utiliser le PTP pour faire ça, et je n'ai pas vu d'infos sur l'envoi/réception des commandes AF via PTP dans le SDK Canon (?). Mais il n'est pas super bien documenté et j'avoue que j'ai été au plus simple pour mon cas ^.^"
Prasamoe:
L'Okii follow focus permet de faire la MAP et bien d'autre fonctions (vitesse, iso, diaph...). Okii est developpe en Arduiyno. La société okii envoie le code a tous les acheteurs et je l'ai reçu, mais ces assez complique.
Tu disais que c'était décevant comme système, c'est que cela ne doit pas fonctionner comme espéré ?
Sinon, question bête qui me vient; tu filmes uniquement avec des optiques AF Canon ?
ekaki:
Prasamoe:
L'Okii follow focus permet de faire la MAP et bien d'autre fonctions (vitesse, iso, diaph...). Okii est developpe en Arduiyno. La société okii envoie le code a tous les acheteurs et je l'ai reçu, mais ces assez complique.Tu disais que c'était décevant comme système, c'est que cela ne doit pas fonctionner comme espéré ?
Sinon, question bête qui me vient; tu filmes uniquement avec des optiques AF Canon ?
Pour l'okii, mon principal problème est de le rendre Wireless (tout câble USB connecté au canon, déséquilibre le steadycam). J'ai les codes de l'okii mais cela demande une compétence qui me dépasse largement. Peut-etre y a-t-il une solution pour remplacer le cable USB par une connection BT sans rentrer dans les codes?
La deuxième limite de l'okii pourrait être liée au processeur du Canon 5d2 qui ne permet pas de traiter trop de commandes d'un coup.
Enfin - tout comme pour le système Android ( merci bbs pour tes infos!) - on ne peut pas reproduire les graduations de distance de l'objectif sur l'okii, ce qui constitue une limite pour un assistant opérateur.
Sinon l'okii serait utilisable et même pratique car on peut le fixer sur le bras du steadicam: le cadreur lui même pourrait s'en servir directement sans assistant pour faire le point (avec un diaph fermé á 8 pour avoir une profondeur de champs suffisante).
Reste qu'un wireless follow focus classique permet d'utiliser d'autres boitiers (je teste un gh2 hacké en deuxième camera) et d'autres optiques (j'ai un 35mm USM Canon mais j'utilise surtout des optiques fixes Nikon). Ton Wireless Follow Focus, Ekaki, m'intéresse énormément par sa polyvalence.
Si la solution de l'Okii peut te satisfaire quelque part, il y a moyen de moyenner une translation de technologie entre l'USB du boitier et l'USB de l'Okii. Sous réserve d'une certaine vitesse de réponse.
Peut-être que des spécialistes ici du BT over USB ou WIFI over USB pourraient aider (Skywodd ?). Mais cela sort un peu du context Arduino.
Sinon pour le coup du moteur PàP sur le follow focus, c'est justement l'idée : De pouvoir le mettre en place quelque soit l'optique, comme pour un follow focus manuel. Partout où le follow focus manuel pourra aller, la commande avec le moteur pourra fonctionner aussi.
Dans ton cas, le seul point qui me parait complexe sorti de la programmation du système est la gestion du poids.
As-tu vérifier physiquement quel est la limite, précisément (100g ?).
Car il faut fouiller les infos techniques afin de trouver une solution qui tienne dans la limite. Cela concerne le moteur, le système mécanique de liaison du moteur (entre l'arbre du follow focus et l'axe du moteur) et le système de liaison électrique (juste les câbles car l'Arduino et tout le reste peut être localement déporter sur l'opé steadi, genre comme une ceinture batterie).
Un moteur de <100g est un idéal mais le moteur Nanotech de <250g que tu proposes est satisfaisant en terme de poids et de taille. (Il y a chez Nanotech un moteur Pap ultra plat et léger mais j'imagine que sa puissance est insuffisante).
Sur la base du SLED du Steadicam, il y a une batterie v-lock de 14,4v/60w qui alimente l'ecran de contrôle egalement situé en base du sled. Cette même batterie peut alimenter facilement le wireless follow focus car un raccord de type 5.5mm/2.1mm permet d'alimenter (sous réserve d'une tension compatible) la camera ou tout autre accessoire située sur le plateau supérieur du SLED. Reste donc a prévoir les autres elements.
A l'origine je me suis inspiré du projet "DIY" de phillip James http://www.phillipjamesproductions.com/60
Un projet tres astucieux, mais laissant a désirer coté design et finitions. Son code arduino est simple, mais... je n'arrive pas a connecter les xbee entre eux a partir d'un MacBook Air. Enfin le petit servo hitech 55 fait du bruit.
Cote moteur PAP j'imagine : le nanotech relié à l'IC allegro 39xx relié a une carte arduino (uno, nano?) et une liaison wireless (BT, xbee?).
coté encodeur j'imagine : un encodeur optique relié à une carte arduino et une liaison wireless également
l' IC Allegro A39xx permet-il d'augmenter la précision et la fiabilité de moteur Pap?
Dans la même gamme de moteur (série ST4209xxx/NEMA 17) chez Nanotec il y a le ST4209X1004 qui pèse 150g avec un couple légèrement inférieur. Cela fait gagner quelques grammes.
Par contre ceux des autres séries, plus fins ou moins coupleux je pense que tu peux mettre de coté; cela va patiner dans le vide lors des mouvements rapides de MAP (physiquement il va y avoir des pas qui vont sauter) à cause de l'inertie de friction des bagues des optiques.
En fait, c'est difficile de dire précisément quel moteur serait optimal car je ne connais pas précisément tes optiques. Je peux juste te donner les références des moteurs que j'utilise et qui fonctionnent bien avec les optiques que j'utilise (si tu veux je peux te faire une liste). On ne va pas dire que c'est du bricolage, mais on peut dire que c'est empirique (j'en ai essayé pas mal avant de me fixer sur les Nanotecs, même s'ils étaient sous mes yeux depuis le début).
Pour la batterie, impec'. Si elle délivre du 14.7V il y a de quoi alimenter tout ce qu'il faut.
Il faudra peut-être prévoir une régulation à 5V avec découplage pour la partie informatique (Arduino etc.) afin de lui donner un courant bien propre, mais rien de sorcier.
Pour le projet de Phillip James, cela ressemble assez au but rechercher.
Avec, comme tu le dis, un moteur PàP à la place du servo.
Il y a certainement moyen de s'inspirer de la partie sans fil et juste modifier la partie motorisation.
Pour la partie réalisation, le plus optimal pour ton projet serait AMHA de ne placer que le moteur (et la petite mécanique) sur le bras du steadicam, et tout le reste (Arduino, électronique de pilotage du moteur, etc.) à distance sur l'opérateur (tout peut tenir dans une petite boite). A moins que 4 fils souples soient gênant pour la stabilisation du bras (?).
Pour le choix de l'Arduino, une version mini ou nano est tout à fait suffisante, juste pour le pilotage du moteur. Il faut par contre prendre en compte la compatibilité physique avec un éventuel shield XBee ou BT et que sur la version mini il n'y a pas de port USB. Ainsi que travailler sur ces versions réduites nécessite d'être plus... "Méticuleux".
Pour l'IC Allegro, en faisant simple; c'est un circuit qui permet de piloter le moteur PàP.
Les versions dont nous parlions avec un autre membre dans cette conversation sont même des circuits spécialement fait pour ça, intégrant quasiment tous les composants nécessaires au bon pilotage des moteurs PàP, et ce de manière fine. Il y a juste quelques condensateurs de découplage/filtrage à ajouter.
Ceci car l'Arduino ne peut pas piloter directement des moteurs de ce type en raison du courant demandé par ces derniers (en gros 1A) mais aussi car ils intègrent des fonctions assez élaborées comme le pilotage en fraction de pas. C'est ça de moins à coder coté Arduino, et ces circuits sont fiables donc on ne se prend pas la tête pendant des semaines à développer une interface (je l'ai déjà fait, et pour arriver au même résultat c'est assez pointu).
Du reste, il y a un module (ce n'est pas un shield) qui utilise ces IC, c'est le projet Easy Driver.
Cela fait un petit billet en dépense et c'est limité à 750mA/phase, mais pour ceux qui veulent se simplifier la vie c'est royal; tout y est, il n'y a plus qu'à connecter à l'Arduino et à l'alimentation.