Aller à : navigation, rechercher

Tête panoramique motorisée

Cette page a pour but de regrouper les résultats des discussions autour de la fabrication d'une tête motorisée pour la prise de vue de panorama.

Plusieurs pistes sont étudiées et voici le résultats de nos recherches.

Projets

  • une tête plus simple plutôt orientée petit/moyen shoot mais qui doit être nettement plus transportable et pratique pour la prise de vue rapide d'une sphère VR.
  • une tête robuste qui permet toutes les folies (simple shoot au fisheye comme l'utilisation d'un 300mm sur un gros reflex)

Mécanique

Cadre

Moteurs

Trois types de moteurs pourraient être utilisés :

  • A courant continu avec des codeurs sur l'arbre pour connaître la position et l'asservir (comme sur les souris à boule), c'est la solution la plus luxueuse mais ces moteurs ont du couple, sont rapides et l'asservissement est très précis. Ces moteurs sont très utilisés en robotique pour ces raisons.
  • Avec des moteurs pas à pas, c'est moins cher mais ces moteurs ont moins de couple, et sans codeurs la position ne peut pas être aussi précise. Ils sont utilisés dans les chariots d'imprimantes par exemple, où le couple du moteur n'a pas besoin d'être énorme pour entrainer le chariot. Le problème est que la rotule avec l'appareil va faire au moins 2 Kg...
  • Des servos treuils de voiliers radio-commandés, la mécanique est faite fiable et robuste, le couple est important, ils ont un débatement de 360° ou plus et peuvent se commander très facilement avec une électronique très peu couteuse ! La solution !!! Mais il faut adapter la mécanique de la rotule en conséquence, il faudrait faire une sorte de cardan avec un servo sur chaque axe de rotation (lacet et tangage). Le prix est raisonable, environ 50€ pour l'entrée de gamme.

Fabricants de moteurs :

Idées de moteurs/mécaniques toutes faites :

Électronique

Il existe des positionneurs numériques dans le commerce très bien faits :

  • Galil permet d'embarquer des programmes qui pourront être exécutés lors du changement d'état d'une entrée. Dispose de plusieurs E/S.

Solution maison :

  • À base de Palm ; une électronique dédiée et pas très chère peut asservir la rotule sur les deux axes. La communication pourrait-être en infrarouge ; les Palms en sont équipés, ça pourrait piloter l'électronique sans acheter un câble avec un connecteur hors de prix et aussi l'appareil photo, car il faudra impérativement synchroniser les mouvements de la rotule avec les prises de vues. Les Nikon D80, Coolpix 8800... peuvent se commander en IR, il sufit juste d'enregistrer le signal émis par la télécommande et de le reproduire avec le palm... Le programme sur le Palm permmetrait de programmer simplement la rotation en fonction de la focale et de l'angle de la sphère voulue...

Contrôle

Cahier des charges

L'interface doit pouvoir décrire des cas standards :

  • (A) 1 row de 6 images sur 360° (cas typique fisheye nikkor 10.5)
  • (B) 2 ou 3 row de 12 images sur 360° (cas 360° au 18mm sur plusieurs rangées)
  • (C) N sur P partiel de 180° horizontal / 60° vertical, tous les cas d'un panorama d'un paysage en haute résolution.
  • (D) cas tricky : prise de vue en hélice. La tête fait plusieurs fois le tour complet. A chaque nouveau tour, le pitch se trouve juste au-dessus de celui du tour précédent. J'impose ce cas qui n'est pas courant car il permettra de faire aussi tous les cas de prise de vue en biais. Si votre sujet n'est pas horizontal mais qu'il monte un peu. Il faut que les colonnes de prise de vues soient décalées.

Tous les cas standards peuvent être résolus avec ces données initiales uniquement :

  • h_fov total : champ angulaire horizontal à couvrir (150°, 360°, par exemple)
  • v_fov total : champ angulaire vertical à couvrir (par exemple 50°)
  • h_npv : npv, nombre de prises de vues horizontales
  • v_npv : pareil en vertical

Exemple :

  • (A) h_fov = 360°, v_fov (on s'en fout), h_npv = 6, v_npv = 1
  • (B) h_fov = 360°, v_fov = 90°, h_npv = 12, v_npv = 3 (3 rows : -45°, 0°, 45° => v_fov=90°)
  • (C) h_fov = 180°, v_fov = 60°, h_npv = N, v_npv = P

Par contre, le cas tricky ne peut pas être modélisé uniquement avec ces parametres. Il faudrait introduire un décalage fin de colonne / fin de rangée en degrés pour cela. Il y a d'autres questions qui se posent aussi. As-t-on besoin d'une référence absolue (pour l'instant ce modèle simple est totalement relatif à la position de départ : celle-ci peut être yaw=0,pitch=0 comme yaw=-90,pitch=-90 et cela ne donnera pas du tout le même panorama). On peut tout à fait imaginer que cette position de départ ne soit codée nulle part et ça marche comme décrit précédement. Par contre si on l'a, il y aura d'autres possibilités enviseageables (genre : fait le panneau, revient à la position de départ, refait le panneau, là, l'ordi indique à la caméra de se mettre à IL-2...) [Note de fma38 : dans ce dernier cas, ne vaut-il pas mieux enchaîner les 2 prises de vues à la même position, pour limiter les problèmes de sujet qui change de place ?]

Programme de pilotage

Détournement de tête pour l'astronomie

Une idée assez répandue est d'utiliser des têtes faites pour l'astronomie.