Tête panoramique motorisée (V.2015)

[Mattpano]

Bonjour à tous,

Voilà la rencontre Panophoto 2015 qui s'achève, et pour ma part je repars dans un nouveau projet de tête panoramique motorisée. J'espère que celui-ci sera fonctionnel !

Pour rappel, le précédent fonctionne au niveau de l'électronique, mais au niveau mécanique, j'ai des soucis de maintien en position (pause de 30s...) . Je vais donc partir sur une autre solution. Je vais donc tout reprendre depuis le début, et essayer de tout construire moi-même (sauf les moteurs...)

Le but est toujours de pouvoir faire des panoramiques sphériques complets, sur une ou plusieurs rangées.

Pour concevoir cette tête panoramique, j'ai 2 options :
1 - une sorte de berceau "en U" dans lequel vient se loger l'appareil photo. Un des gros avantages est qu'il y a peu de porte-à-faux dans cette conception. Un inconvénient est la taille de ce berceau, pour peu qu'on souhaite y mettre un reflex et un gros objectif (pano HD ...)
2 - une rotule style Nodal Ninja. L'avantage cette fois-ci est que je peux essayer de concevoir quelque chose de repliable, donc facilement transportable. Le gros inconvénient devient tout de suite le porte-à-faux qui en découle.

Je sais bien qu'on n'est pas dans un forum de mécanique, mais je vous sollicite tout de même !

Si je m'oriente vers la 2° solution, il va falloir que je me concentre sur le porte-à-faux.
Si je souhaite faire quelque chose d'assez compact, je n'aurai pas la place d'installer 2 roulements à billes "simples", j'ai vu qu'il existait des roulements à 2 rangées de billes.

Voici un schéma :



Légende : (rien n'est à l'échelle ! )
- Orange : le trépied
- bleu : une pièce qui serait reliée au pas de vis du trépied, et qui maintiendrait le roulement à billes
- noir : le roulement à billes (simple rangée, ou double rangée, à voir)
- vert : le bras horizontal de la tête panoramique.
- Le reste n'est pas dessiné...

Quelle solution vous semble la plus logique et la plus résistante vis à vis du porte-à-faux ?
Dans la version de gauche, la pièce reliée au trépied maintient le roulement à billes par l'extérieur, et le bras horizontal est relié au centre du roulement.
Dans la version de droite, c'est l'inverse.

Merci

[llang57]

Bonjour Matthieu,

j'aurais tendance à privilégier le montage 2. Mais si tu veux contrer le porte à faux, motange avec deux roulements à rouleaux coniques (montage en O). Ou alors roulement à aiguilles.


Amicalement

[quoideneufdocteur?]

Pour l'instant on ne vois pas ou tu places le moteur pour activer cet axe là ..Il serait idiot d'envisager des "galets" en téflon (ou autre) pour limiter le frottement et se passer des roulements ?

[Mattpano]

Pour l'instant on ne vois pas ou tu places le moteur pour activer cet axe là ..Il serait idiot d'envisager des "galets" en téflon (ou autre) pour limiter le frottement et se passer des roulements ?

L'idée des roulements était de me guider l'axe de rotation. Je comptais mettre en plus un disque de téflon là où ça risque de frotter.
Si par contre je ne mets que des galets en téflon, comment est assuré mon guidage ?

Concernant la motorisation, c'est dans un coin de ma tête, mais je ne souhaite pas un maintien en position via le moteur (ou son éventuel réducteur). Je souhaite que ça tienne tout seul, que ça tourne bien, le moteur ne viendra que pour faire tourner.
C'est stupide comme raisonnement, ou ça se tient ?

[quoideneufdocteur?]

Quand je regarde comment est foutue la tête merlin, je ne vois pas de roulement (je n'ai rien contre les roulements, je regarde si il y a plus simple pour arriver au même résultat) Demain je vais la dépouiller pour te mettre des photos...

[Mattpano]

Demain je vais la dépouiller pour te mettre des photos...

Je n'osais pas espérer mieux , merci merci

[quoideneufdocteur?]

La tête enlevée

Dans l'ordre, pour maintenir la tête sur le pied, roulement, rondelle cuvette, rondelles noires, écrou

La tête vue de dessous, à l'envers, posée sur le pied, on voit l'engrenage fixé sur l'axe du moteur, qui vient entrainer grande la roue dentée de la photo 1, sur l'autre bout de l'axe il y a la roue codeuse et la fourche optique

[quoideneufdocteur?]

tout ça est horriblement compliqué ! Dans le projet d'Amedee, entrainement direct dans l'axe du moteur, il n'y a rien à copier subrepticement ?

[Mattpano]

Merci pour les photos ! Je vais les étudier.

Dans le projet d'Amedee, si mes souvenirs sont bons, il y mets un full frame, donc une seule rangée de photos, puis tout est dans l'axe de rotation, il n'a que peu de porte à faux.

edit :non, il a fait une modification depuis, il fait bien du multi ! je vais tout relire, c'est ici
Tandis que moi, je souhaite pouvoir faire du multi-rangées, avec réglage du point nodal, donc si l'idée est de faire l'équivalent d'une Nodal Ninja motorisée, il faut soigner le maintient sur le trépied, car il y a un fort porte-à-faux, qu'on ne peut pas régler par une simple molette de serrage... Sinon le moteur va forcer !

[Mattpano]

En attendant d'avancer sur la partie mécanique, je me suis bien penché sur la partie programmation, et je remarque que je commence à être juste en stockage de variable avec le petit Arduino Nano que j'utilise.

Aussi, je vous liste les idées que j'ai eu concernant les paramètres potentiellement intéressants pour l'utilisateur :

• Les paramètres qui sont des nombres :
  Temps de pause
  nb positions rotation horizontale (pan)
  nb positions rotation verticale (tilt)
  rotation horaire ou anti - horaire (pan)
  
  nombre de photos à chaque position (bracketing)
  
  délais à la mise en route
  délais entre 2 photos
  délais après rotation, juste avant la photo (absence de vibration)
  délais pour faire la mise au point
  
  nombre de panoramas à réaliser
  délais entre les panoramas à réaliser
  
  Les paramètres qui sont des "mots"
  choix de la langue ( FR / EN / CAT ... )
  retour à la position initiale après la prise de vue ( oui / non )

Voyez-vous autre chose à ajouter ?
Car pour l'instant, j'ai "réservé" une grosse partie de mémoire, en pensant que j'aurai plus de "'mots" à stocker que ça, et au final, je me rends compte que la plupart des paramètres sont des nombres. Si c'est effectivement le cas, je vais revoir l'attribution de mes variables afin de libérer de l'espace. Je gérerais "à la main" les 2 variables textes si nécessaire.

[nickdan]

Si tu manque vraiment de place, le choix de la langue n'est-il pas superflue ? J'aimgine que ça doit prendre de la mémoire ça...
Je veux dire, ne vaut-il mieux pas pour toi d'avoir un programme par langue ? Car voyons la pratique : un utilisateur ne changera pas de langue comme ça du jour au lendemain. Il va la choisir au début, point. Donc autant la choisir au moment de la programmation. non ?
Sinon, après, faut attaquer l'optimisation... et là, pas de pitié, le moindre octet gagné compte (je vias pas dire qu'il compte double, mais c'est l'idée ).

[Mattpano]

Pour l'instant, j'ai encore un peu de place, mais le code n'est pas terminé.

Donc oui, l'idée est de lister les paramètres importants, de vois là où je fais des concessions, s'il y en a à faire, et on verra les paramètres les moins importants.
En effet, suivant comment je gère les variables de langue, je consacre plus ou moins de mémoire à ce paramètre.

[quoideneufdocteur?]

Vu le prix des Arduino ça ne vaut peut être pas la peine que tu te pressures le citron pour que ton code tienne sur le nano.
Il faudrait prévoir un bouton d'arrêt d'urgence aussi.
Je dois avoir un ou deux arduino Méga qui trainent et qui ne feront jamais rien, si ça peut te servir...

[Mattpano]

Les boutons, j'ai prévu.
Par contre, si je pars sur le Nano et que je me presse le citron, c'est pour avoir quelque chose de compact, de plus petit possible. J'ai l'impression que les Mega prennent un peu de place, non ?

[llang57]

Les boutons, j'ai prévu.
Par contre, si je pars sur le Nano et que je me presse le citron, c'est pour avoir quelque chose de compact, de plus petit possible. J'ai l'impression que les Mega prennent un peu de place, non ?

c'est sûr c'est pas la même taille.


Amicalement

[Mattpano]

Je n'ai pas le temps de chercher là de suite, je le ferrais plus tard, mais tant qu'à faire, j'essayerai de miniaturiser au maximum, pour essayer de trouver une puce du style attiny 85. Sauf que cette dernière ne comporte que 8 pattes, et il faudra quand même un peu plus d'entrées / sorties

[Kalain]

En attendant d'avancer sur la partie mécanique, je me suis bien penché sur la partie programmation, et je remarque que je commence à être juste en stockage de variable avec le petit Arduino Nano que j'utilise.

Nano! ok mais quelle version.
La version Nano 3.0 basé sur un Atmega 328 comporte 2 fois plus de mémoire Flash et Eeprom que la version Nano 2.3 (Atmega 168)
Cf paragraphe "spécifications" en début de page :
https://www.arduino.cc/en/Main/ArduinoBoardNano
Cela peut faire la différence, surtout si tu utilises la V2.3, tu vas pourvoir envisager large, même avec des textes en chinois...

[Mattpano]

Et bien je pense bien avoir la version Atmega 328.
Voici les informations quand je compile, j'ai fait un grand ménage dans mes variables, il faut que je continue :

Le croquis utilise 12 040 octets (39%) de l'espace de stockage de programmes. Le maximum est de 30 720 octets.
Les variables globales utilisent 1 008 octets (49%) de mémoire dynamique, ce qui laisse 1 040 octets pour les variables locales. Le maximum est de 2 048 octets.

J'étais monté à plus de 65% d'occupation de l'espace de stockage, et 82% de mémoire dynamique. J'avais alors un message d'alerte me disant qu'il pouvait y avoir des problèmes de mémoire. (je n'ai pas noté les termes exacts)

[Philooo]

Voici un schéma :



/.../Quelle solution vous semble la plus logique et la plus résistante vis à vis du porte-à-faux ?

La solution la plus simple : la 2, dans laquelle la pièce bleue est débarrassée de presque toute sa partie inférieure : un simple petit cylindre plein en alu, avec un épaulement en bas pour le maintien. Taraudé à 3/8" sur toute sa longueur pour recevoir à un bout la vis du trépied et à l'autre une vis en 3/8" avec une rondelle.
La pièce verte peut aussi être débarrassée de la partie supérieure : un simple cylindre creux, avec la cage extérieure du roulement emmanchée à force dedans. Un cache en plastique pour faire joli si tu ne veux pas qu'on voie le roulement et la vis qui le maintient sur la pièce bleue.

Côté roulement, un roulement conique ou à aiguilles est très résistant, mais oblige à multiplier les pièces de maintien, indispensables dans un montage comme celui-ci dont on ne veut pas qu'il bouge. Un roulement à billes suffit : il sera un peu plus gros et plus lourd mais pour des contraintes de quelques kilos comme ici, on parle en dizaines de grammes.

délais pour faire la mise au point

Un changement de mise au point en cours de panorama, est-ce bien raisonnable ? Mise au point manuelle une fois pour toutes picétou, non ?

[Mattpano]

Merci Philooo pour tes remarques intéressantes !

J'aurai une question de programmation sur Arduino :

La série de paramètres est stockée dans deux "array". L'une contient des "mots", et l'autre les "valeurs".

Code : Tout sélectionner

char voc[14][16] = {  "FR",  "Tps pause (h)", "Tps pause (min)", "Tps pause (s)",  "Nb rangs", "Nb Photos / rg",  ... };
int param2[14] = {  4, 3, 4, 6, 0, 6,  ...};

Sauf que je ne sais pas au début quelle sera la taille de ces listes : je les initialisent à 14 valeurs, car je suis sur une phase de test. C'est l'utilisateur qui va choisir (par exemple) le nombre de rangées à effectuer : je veux donc pouvoir adapter cette liste en fonction du nombre qu'entrera l'utilisateur.

Sur excel, c'est facile, il suffit de faire "ajouter une colonne" ou "ajouter une ligne", et hop, magie, on a la colonne ou la ligne en plus.

Et là, avec Arduino, j'avoue que je suis perdu :

- j'ai essayé de conserver mes 2 listes initiales, et d'en créer une autre avec les paramètres du nombre de rangées, mais lors de l'affichage, intercaler cette nouvelle liste au milieu de l'autre, c'est beaucoup trop galère à gérer.
du coup :
- j'ai essayé de sauvegarder les paramètres dans une liste intermédiaire, de supprimer la liste principale, d'en recrééer une nouvelle à la bonne taille, et d'y ranger la sauvegarde, sauf que cette nouvelle liste est crée dans une fonction, et donc, comme tous les paramètres, elle "reste" dans la fonction, et je ne peux pas la ré-exploiter après. (j'ai dû louper quelque chose, non ? )

J'ai donc 2 questions dont les réponses pourraient me sauver :
- peut-on redimensionner une array à la volée ?
un truc du genre :
new dim param2 = 15; je rêve

- ou alors, comment faire pour, au sein d'une même fonction, "sortir" 2 listes nouvelles, exploitables partout, comme si elles avaient été déclarées au tout début du programme, en dehors de toute fonction ?
Si ce n'est pas possible de "sortir" 2 nouvelles listes pour une seule fonction, je ferrais 2 fonctions, ce n'est pas grave.

Merci