module inscription newsletter haut de page forum mobile

Rejeter la notice

formations etalonnage sur davinci resolve

Nos Formations Etalonnage avec Forest reviennent en octobre !
Adoptez une réelle méthodologie d'étalonnage professionnelle et atteignez vos objectifs créatifs avec nos formations intensives sur 3 jours
Toutes les infos
Rejeter la notice

Formation Lumière - Pratique Intensive du 14 au 16 octobre à Paris
Formez-vous avec cet atelier de pratique intensive dans des conditions exceptionnelles ! Formation finançable.
Toutes les infos

Ateliers et Formations

Construction de tête motorisée: votre avis!

Discussion dans 'Archives moteurs' créé par Diego.26, 21 Août 2006.

Tags:
  1. Gilles 87

    Points Repaire:
    1 520
    Recos reçues:
    5
    Messages:
    442
    Appréciations:
    +0 / 0 / -0
    salut Diego 26

    jette un oeil sur ce site pour les cartes électroniques, j'ai réalisé de gros servos avec leur carte analogique et un peu de méca de chez HPC (roues dentées) les potars voir chez Radiospare ou Spectrol. Ceci dit tes résultats seront meilleurs en pas à pas mais au prix d'une électronique moins facile à comprendre et réaliser, du moins pour moi. l'avantage du CC c'est de plus forts couples à volume équivalent.

    http://www.milinst.com/
     
  2. jlucdv

    Points Repaire:
    1 000
    Recos reçues:
    0
    Messages:
    157
    Appréciations:
    +0 / 0 / -0
    Je suis allé dans une boutique qui vend la carte commande (KEIR 120) de moteurs pas à pas présentée par Diego 26.
    J'ai donc regardé la doc. Malheureusement il est précisé qu'il ne faut pas utiliser un joystick à potentiomètres mais à commutateurs et la vitesse est sélectionnée par un autre commutateur. Dommage.
     
  3. Pascal22

    Points Repaire:
    1 700
    Recos reçues:
    0
    Messages:
    1 489
    Appréciations:
    +0 / 0 / -0
    Commande de moteur Pas à Pas

    Pour contrôler un moteur Pas à Pas
    une impulsion va faire tourner le moteur d'un pas dans un sens ou dans l'autre, selon le bit de configuration.

    Premiere remarque :
    le positionnement de l'axe se fera au pas près donc le cadre de la prise de vue aussi ; à savoir que pour un Moteur de 400 p/tours (0,9°/Pas)le cadre se déplacera donc de env. 1,6 Cm à 1 mètre - 16 Cm à 10 Mètres...
    Il faut donc une réduction.
    Avec le même moteur et une reduction de 50 on porte la Résolution à 20000p/tours (0,018°/pas) soit un déplacement du cadre par pas de environ 0,03 cm à 1 Mètre - 0,3 Cm à 10 Mètres...
    Ce qui induit une Seconde remarque :
    Quelle doit être la vitesses Max ?
    Admettons que nous voulions balayer 180° (10000 pas) en 4sec : soit 2500 Pas/sec -> 1 pas toutes les 400µs
    Pour la commande nous devons mettre en place un compteur qui déclanchera une impulsion toutes les X periodes.
    Premier essais :
    la periode du compteur est de 400µs (soit la vitesse maxi)
    V[Max] -> impulsion toutes les périodes -> 2500p/sec
    V[Max-1] -> impulsion toutes les 2 périodes -> 1250p/sec
    V[Max-2] -> impulsion toutes les 3 périodes -> 833,33p/sec
    V[Max-3] -> impulsion toutes les 4 périodes -> 625 p/sec
    ...
    V[4] -> impulsion toutes les 252 périodes -> 9,92p/sec
    V[3] -> impulsion toutes les 253 périodes -> 9,88p/sec
    V[2] -> impulsion toutes les 254 périodes -> 9,84p/sec
    V[1] -> impulsion toutes les 255 périodes -> 9,80p/sec

    avec cette approche on constate plusieurs problèmes :
    - la vitesse ne varie pas de façon linéaire
    - elle varie beaucoup trop rapidement aux abords de la vitesse maxi
    - elle varie beaucoup trop lentement aux abords de la vitesse mini
    Solutions :
    -> augmenter la resolution en haute vitesse -> reduire la periode du compteur (20µs)
    -> stoker une table des vitesses dans la mémoire du µcontrôleur (en selectionnant les différentes vitesses qui nous intéressent).

    si par exemple on réduit la période du compteur à 20µ :
    V[Max] -> impulsion toutes les 20 périodes -> 2500p/s
    V[Max-1] -> impulsion toutes les 21 périodes -> 2380p/s
    -> soit une variation maxi de 120p/s
    ainsi de suite...

    Programme :
    On construit un tableau VITESSE[256] (256 valeurs de vitesses (dont la vitesse 0 representant l'arret du moteur), dans lequel on stocke pour chaqune des vitesses retenues le nombre de periode que l'on doit attendre avant d'envoyer une impulsion (le valeurs devront être stockées sur 16 bits).
    On initialise un compteur courant : CURCOMPT (qui servira à compter le nombre de périodes à attendre).
    On initialise un compteur de pas : POSMOTEUR (qui servira à connaitre la position du moteur).
    On initialise une interruption devant être déclenchée à chaque période (toutes les 20µs).
    1 variable sera utilisée, pour la vitesse courante : CURVITESSE
    Pour envoyer l'impulsion on initialise un port (de 1 bit) du µcontrôleur en sortie : IMPMOTEUR, et pour le sens de rotation du Moteur : SENSMOTEUR


    Le programme de gestion du moteur (appelé par l'interruption) sera du type :
    pap000.jpg

    ce court programme executé toutes les 20µs exactement fait avancer le moteur à la vitesse courante, le temps restant peut donc être employé pour des opérations moins critiques : relevé des vitesses, calcul des rampes d'acceleration/descélération...

    Reste à gérer :
    - Les fins de course (2 par Moteur) -> ceux-ci doivent générer une interruption commandant l'arret immédiat du moteur. Il peuvent également servir dans une phase d'initialisation à configurer la course des moteur (pour un Positionnement)
    - le système de commande : le plus simple étant des switch permetant d'incrementer/décrementer la vitesse, mais par adjonction de convertisseurs Analogique/numérique il est également possible de gérer une manette (type modelisme) que l'on trouve couramment.
    - la limitations de l'accélération ou la déscélération, en imposant par exemple un ecart maxi entre la vitesse courante et celle demandée
    - la mémorisation de position
    - la memorisation d'un vitesse de plateau
    - l'execution de segment : déplacement entre 2 positions

    Très loin d'être exaustif ce post est juste une première approche de ce que pourrait être un système de contrôle des moteurs pas à pas d'une tête de Caméra.
    Je pense qu'il convient de prendre des moteurs assez puissant, car il est préférable pour certaines applications de positionner les axes de la tête sur le centre optique de la camera plutôt que sur le centre de gravité.
     
    #18 Pascal22, 17 Septembre 2006
    Dernière édition: 21 Septembre 2006
  4. over06

    Points Repaire:
    550
    Recos reçues:
    0
    Messages:
    20
    Appréciations:
    +0 / 0 / -0
    Bonjour, je suis également en train d'établir un projet de construction de grue avec tête motorisée 2 axes.
    Après 9 mois de recherches, il apparait que l'utilisation des moteurs pas à pas est déconseillée en raison des vibrations à l'arrêt, inconcevable pour notre utilisation.
    Les moteurs DC sont préconisés mais reste le problème du maintien de couple à l'arrêt, surtout pour l'axe tilt même si la camera est bien réglée sur son centre gravité, l'élan provoqué par le mouvement ne permet pas un arret net.
    Je viens de découvrir recemment l'existence des freins éléctromagnétiques ou freins à manque de courant que l'on peut placer sur l'axe et connecté en parralelle au niveau alimentation moteur et qui se bloque lorsque il n'y a plus de courant aux bornes.
    Liens:
    MDP Accueil
    Ogura Industrial Corp. - Electromagnetic Clutches and Brakes

    En ce qui concerne l'éléctronique de commande et après avoir visité des milliers de sites web je pense que je vais me tourner ce fabriquant qui propose un controlleur 2 axes pour moteur DC 12V à 48V qui peut être commandé directement par joystick, par PC, par radio commande de modelisme et par reseau ethernet. Le modèle AX2850
    Lien:
    Welcome to Roboteq

    Le choix du joystick n'est pas encore fait car je n'ai pas encore trouvé la solution pratique pour piloter la grue et la camera en même temps avec une seule personne.
    Je verrais bien un systeme qui ressemblerait en gros à un guidon de moto avec les commandes aux pouces des mains droites et gauche pour tilt et pan histoire de pouvoir controller les mouvements de la grue correctement.

    La fleche de la grue sera en tube aluminium rectangulaire et modulable en longueur avec possibilité de placer des haubans pour eviter les mouvements intempestifs.
    Les liaisons mobiles sur le fleches se feront bien entendu par l'intermediaire de roulements à billes. La solution la plus pratique pour moi est d'utiliser des paliers à roulement que l'on peut visser sur la fleche. Les axes peuvent etres bloqués par deux vis.
    Cette solution a quand même plusieurs inconveniants: Prix, poids, volume.

    Si des membres ont des indées pour fixer des roulements autrement je suis preneur.

    Le trepied sera de fabrication maison.

    Je suis preneur de toute infos, remarque, suggestion, conseil, idée qui pourrait améliorer mon projet et je peux également fournir aux membres qui le désirent des précisions sur mon projet.
     
  5. Pascal22

    Points Repaire:
    1 700
    Recos reçues:
    0
    Messages:
    1 489
    Appréciations:
    +0 / 0 / -0
    over06,
    Avec quelle type de de commande as-tu fait tes essais ? Car mis à pas pour un arret entre 2 pas, je n'ai pas constaté cet inconvéniant.
     
  6. BEBE

    Points Repaire:
    1 000
    Recos reçues:
    0
    Messages:
    121
    Appréciations:
    +0 / 0 / -0
    Bonjour,
    Petites remarques de ma part,
    A l'arret un moteur pas a
     
  7. over06

    Points Repaire:
    550
    Recos reçues:
    0
    Messages:
    20
    Appréciations:
    +0 / 0 / -0
    Je n'ai pas fait de test de commande avec un moteur pas à pas. C'est à force de me renseigner sur des forums spécialisés français et internationaux que je penche vers le moteur DC. Mais comme je le disais dans precedent message, rien n'est définitif dans mon projet et c'est pour ce la que je fait appel à ceux qui veulent bien me guider dans la bonne voie.
     
  8. Pascal22

    Points Repaire:
    1 700
    Recos reçues:
    0
    Messages:
    1 489
    Appréciations:
    +0 / 0 / -0
    Interface utilisateur :

    Commande :
    Le plus simple à mettre en œuvre pour commander un moteur est ensemble de Boutons permettant de contrôler la vitesse, le sens, l’arrêt immédiat, l’arrêt progressif.
    Bien que moins Sexy qu’une commande analogique de type manette, ce type d’ interface a 2 avantages :
    1. elle peut se connecter directement à n’importe quel µContrôleur,
    2. la mise en œuvre d’une limitation de l’accélération / décélération est simple.
    On peut imaginer :
    Un bouton < : chargé, soit de réduire la vitesse quand le moteur tourne dans le sens des aiguilles d’une montre, soit, dans le cas contraire, de l’augmenter.
    Un bouton > : chargé, soit d’augmenter la vitesse quand le moteur tourne dans le sens des aiguilles d’une montre, soit, dans le cas contraire, de la réduire.
    Un bouton STOP : chargé, d’arrêter immédiatement le moteur.
    Un bouton ARRET : chargé d’arrêter le moteur progressivement (respectant la limite de décélération).

    Pour ce faire, on va initialisé 4 entrées du µcontrôleur : INTERF_< , INTERF_>, INTERF_S, INTEF_A, que l’on va consulter périodiquement. C’est la longueur de cette période qui va limiter l’accélération et la décélération.
    Pour ce faire le plus simple est d’ajouter ces tests à la routine d’interruption destinée au moteur. Comme celle-ci intervient toutes les 20µs, il est nécessaire d’initialiser un compteur (16bits) COMPTINTERF et une constante DELAIINTERF qui vont nous permettre de limiter la fréquence des Tests.
    On affecte à DELAIINTERF une valeur représentant le nombre de périodes qu’il va falloir attendre avant de tester à nouveau les boutons (par ex : 20000 (20µs x 20000 = 400 ms)).
    Il nous faut également une variable pour savoir si un arrêt progressif a été demandé : MODEARRET (initialement à 0)

    Voici ce que pourrait être le sous-programme d’interface :
    pap001.gif
    Sous-programmes :
    pap002.gif [

    Le bouton Stop étant traité différemment : testé à chaque interruption.

    Le programme appelé par l’interruption devient :
    pap003.gif

    Récapitulation :
    Ports du µcontrôleur :
    Moteur : 2 bits en sortie (IMPMOTEUR, SENSMOTEUR)
    Interface : 4 bits en entrée (INTERF_<, INTERF_>, INTERF_A, INTERF_S)
    Variables :
    CURVITESSE (8 bits) : index de la vitesse courante du moteur
    CURCOMPT (16 bits) : compteur de période pour les délai d’attente moteur
    POSMOTEUR (16 bits) : compteur de pas effectués par le Moteur (inutilisé pour l’instant)
    COMPTINTERF (16 bits) : compteur de période pour les delais d’attente interface
    DELAIINTERF (16 bits) : nombre de périodes à attendre pour tester l’interface
    MODEARRET (1 bit) : marqueur du mode d’arrêt
    Tableau :
    VITESSE[256] (16x 256 bit) : stocke les délai d’attente de périodes pour les différentes vitesses moteur

    Il faut donc pour contrôler un moteur un µcontrôleur possédant au moins un port de 6 bits en E/S , au moins 9 octets de RAM et (512+le Programme) octets de mémoire programme. Il faut également qu’il supporte une programmable irq. (pour 2 moteurs : 12 bits en E/S, 18 octets de RAM).


    Voilà pour la théorie.
     
  9. jlucdv

    Points Repaire:
    1 000
    Recos reçues:
    0
    Messages:
    157
    Appréciations:
    +0 / 0 / -0
    Mouai, mais je doute que le suivit par ex d'un parcours erratique d'un personnage, soit aisé.

    Avec un µproc qui possède une entrée ana on peut lire la position d'un joystick à potentiomètres, de fixer des min, max et point milieu, suivit d'un PID …
    Ca me semble être le plus ergonomique et donné un résultat plus "naturel". Tu auras toujours un décalage avec des boutons. Et le temps passé en programmation doit être équivalent.

    Pour ma part, comme je possède déjà une radiocommande proportionnelle, je vais tenter de remplacer les servos par des moteurs pas à pas. Donc convertir le signal PWM en sortie du récepteur, en commande proportionnelle du pas à pas, toujours par l'intermédiaire d'un µproc. C'est plus facile (mesure de temps) et ce fait directement sur une entrée logique.

    Dans le monde du modélisme ca déjà été réalisé en partie: En faite le circuit analogique spécialisé pour la commande du moteur du servo a été remplacé par un µproc, ce qui permit d'avoir une plus grande fluidité de mouvement (meilleur gestion du moteur DC) et d'une meilleure immunité par filtration numérique des aléas analogiques. On pourra s'en inspirer pour une commande de moteur pas à pas …
    Tout ca en supposant que le signal PWM est très stable, ce que je me dois de vérifier avant tout. Et puis si les résultats sont honorables avec ce montage pour un moteur DC alors mes moteurs pas à pas récupérés resteront dans leur tiroir.
    Et je me contenterai de mes motoréducteurs, un peu bruyant.
    Il faut que je retrouve le site.

    Une petite radiocommande proportionnel d'occasion à 2 manches + récepteur 5 à 8 voies ce n'est pas bien chère. Avec les autres voies on peut piloter d'autres paramètres de la caméra (marche/arrêt, map, …).
     
  10. Pascal22

    Points Repaire:
    1 700
    Recos reçues:
    0
    Messages:
    1 489
    Appréciations:
    +0 / 0 / -0
    effectivement... c'est parfaitement possible, même sans entrées analogiques (juste avec 2 resistances et un condo), ceci dit les temps de conversion sont plus proches des 3ms et imposent un traitement multitache plus poussé.... de plus la programmation est assez différente si l'on veut limiter l'acélération/décélération des moteurs.
    Le but de mes interventions n'était pas de fournir un prog 'clé en main' pour une tête motorisé, mais plutôt une approche, réalisable simplement sur beaucoup de µctrl (Pic, SX (ayant ma préférence),...), et évolutive vers : les fins de courses,les commandes analogique, le positionnement relatif et absolu, l'enregistrement/lecture de segments, le contrôle de 4 axes (5 qui sait ?), commandes lanc...
    Mais peut être m'y suis-je mal pris, ou que bidouille et compréhention ne sont pas à cet ordre du jour ?.. si c'est le cas c'est bien de le savoir, car ca peut m'éviter de perdre mon temps...
     
  11. pepsouinen

    Points Repaire:
    550
    Recos reçues:
    0
    Messages:
    15
    Appréciations:
    +0 / 0 / -0
    je comprends pas trop l'anglais mais ca peut etre une piste a envisagé
    ici
     
  12. jlucdv

    Points Repaire:
    1 000
    Recos reçues:
    0
    Messages:
    157
    Appréciations:
    +0 / 0 / -0
    Bravo pepsouinen
    Bonne pioche

    En regardant quelques minutes:
    Pas mal pour celui qui veut une solution toute faite et à base de servo.
    Pas mal de données sur les vitesses angulaires maximum, à vérifier en détail.
    Les servos utilisés sont de qualité (roulements, roues dentées métal)
    L'achat des ensembles pan et tilt est facilité par un bon de commande où l'on choisit le type (couple) et la qualité de servos, le ratio (vitesse max), la plage angulaire et la version kit ou tout monté. Reste à voir l'excursion possible de la vitesse …
    Je retiens ce site dans mes favoris et y reviendrai un peu plus tard.

    Une chose importante qui pourrait bien solutionner certains problèmes rencontrés lors de mes expérimentations: Le potentiomètre de recopie est "extrait" du servo pour être en prise directe avec l'axe de sortie du système. Ceci doit surement procurer un effet favorable sur l'ajustement ainsi qu'une meilleure fluidité.
    J'y avais bien pensé mais pas assez fort. Encore un point qui me réconcilie avec les servos! Faut que je réexpérimente.



    Pascal22: je mets seulement le mode de commande en doute, il me semble qu'un joystick soit le plus approprié pour obtenir le meilleur suivit.
    D'ailleurs il faudrait jeter un œil sur les version professionnel, à moins que quelqu'un l'a déjà fait.
     
  13. Pascal22

    Points Repaire:
    1 700
    Recos reçues:
    0
    Messages:
    1 489
    Appréciations:
    +0 / 0 / -0
    ce ne fait aucun doute... Mais la programmation de ce type d'interface, est plus compliquée. De plus, faisant appel au même hardware ( Parallax, Inc-StoreFront Product Detail Page par ex) rien n'empèche de l'implémenter dans un second temps, car il y a beaucoup d'autres aspect à maitriser avant.
    Il est à noter également, que généralement une prise de vue avec ce type de matériel (Grue+Tête) est un minimum prévue à l'avance (voir scénarisé), je priviligiais donc l'assistance dans les mouvements plutot que le suivi. En effet il ne manque que les fins de courses et des boutons de mise en mémoire au prog précédent pour gérer le positionnement.
     
  14. over06

    Points Repaire:
    550
    Recos reçues:
    0
    Messages:
    20
    Appréciations:
    +0 / 0 / -0
    Pour revenir à mon message precedent et après lecture des differents messages des membres du forum, je m'apperçois que la tache est beaucoup plus compliquée que prevue.

    J'ai vraiment du mal à m'y retrouver mais je persiste dans mon projet et redemande votre aide dans tous les domaines de construction de cette fameuse tête de grue.

    Je récapitule les possibilités qui sont envisageables:

    Motorisation:
    Moteur DC
    Moteur pas à pas
    Servomoteur
    Motoreducteur

    Controleur:
    Par l'intermédiaire d'un joystick via un PC
    Par l'intermédiaire d'un joystik sans PC
    Programmable ou pas

    Joystick
    Potentiométrique ou non


    Je suis encore très hésitant concernant le choix définitif vu que je n'ai pas envie de faire des achats qui ne correspondraient pas à mes besoins.

    En fait je veux pouvoir commander le moteur de chaque axe (pan et tilt) depuis deux joysticks (1 pour chaque axe).
    Je dis joysticks mais cela peut prendre la forme d'une molette, ou autre dispositif actionable au doigt, pour permettre d'être installé du côté des contrepoids de la grue, une fois de plus imaginez un guidon de moto avec les commandes à la place des clignos, klaxon, feux.....

    Quand on relache la commande elle revient dans sa position centrale et les moteurs se bloquent. Plus on s'ecarte du centre et plus les moteurs tournent vite.

    Une autre méthode serait interessante aussi.
    Celle ou la commande ne revient pas à son centre quand on la relache.

    Enfin je ne sais pas si je m'exprime vraiment bien sur le sujet, j'espere que vous serez indulgent à mon égard et que vous voudrez bien m'aider dans ma démarche.

    Voici mon mail perso:
    over06@9online.fr
     
  15. jlucdv

    Points Repaire:
    1 000
    Recos reçues:
    0
    Messages:
    157
    Appréciations:
    +0 / 0 / -0
    Over06:
    Je ne pense pas que ce soit bien compliqué si l'on a le bon cahier des charges. C'est-à-dire bien définir ce que l'on veut obtenir et la meilleur méthode pour y parvenir. Ca parait compliqué par ce que l'on manque d'expérience et que l'on a peut de moyen d'investiguer. Donc ils nous restent à observer et profiter de nos différentes expériences.

    A ce propos quand tu dis "je n'ai pas envie de faire des achats …", quelque part il faut bien se lancer:
    - Diego 26 à comme moi expérimenter des servos moteurs de modélisme
    - girouf à investit dans une carte spécialisée pour moteur dc
    - Pascal22 c'est creuser la tête coté programmation.
    Et j'en oublie …

    Les commandes coté contrepoids parait le plus intéressant, s'il n'y a qu'un "pilote".
    Il pilote manuellement le pivot de grue sur les deux axes et télécommande la tête. Il existe une version professionnel de ce que tu présentes pour un petit model de grue (vue dans C.V.) dont toutes les commandes sont mécaniques. Peut être même qu'il est plus facile de diriger la caméra qu'à deux personnes. Car rien ne vaut un pilotage manuel de la flèche de grue (qu'il y est un ou deux pilotes), les masses à déplacer demandent une motorisation à fort couple pour avoir du répondant.
     
Chargement...

Partager cette page