1

Salut,
Qu'existe-il comme moyens d'asservissement pour un grand nombre de servomoteurs (de 3 à + d'une vingtaine triso) et pour pas trop cher. (les kits en robotique sont simplement hors de prix)
Je ne cherche pas un plan (pas encore) mais les differentes solutions possibles, avec et sans pic, en utilisant le port // et ou serie, avec leurs avantages et inconvenients.
Le but etant la creation du cahier des charges d'un robot (donc 3 à +20 axes) pas trop cher et facile à modifier afin de pouvoir réutiliser cette carte.
Merci d'avance pour toutes vos suggestions.

2

Je te donnerais bien ma suggestion, mais elle est totalement partiale, à savoir PIC forever, prog Assembleur.

Les avantages sont :
- le très bas prix résultant (dans la mesure où on peut en avoir en échantillons gratuits chez Microchip)
- le contrôle total et absolu de ce qui se passe
- la vitesse de traitement atteinte (puisque l'on a une architecture massivement parallèle)
- la facilité de programmation quand on connaît l'Assembleur
- l'ICSP (In-Circuit Serial Programming, pour programmer les PIC sans les démonter du circuit) quand il marche

Les inconvénients sont :
- le nombre de PIC nécessaires (je conseille un PIC par effecteur, d'où l'architecture parallèle)
- le protocole de communication entre PIC à faire avec soin
- la difficulté de programmation quand on ne connaît pas l'Assembleur
- l'ICSP quand il ne marche pas


De plus, plutôt que les servomoteurs, je préfère les moteurs pas-à-pas, qui ont quelques avantages, mais aussi quelques inconvénients, par rapport à ces derniers.

Les avantages sont :
- possibilité de faire plusieurs tours dans un sens ou dans l'autre, avec un contrôle précis de la position
- programmation de commande beaucoup plus simple que le PWM (Pulse Width Modulation) utilisé pour commander les servos

Les inconvénients sont :
- faible vitesse de rotation
- plus encombrants que les servos


Voilà voilà, je ne peux pas en dire beaucoup plus, à moins que tu ne sois plus précis dans tes questions hehe ...

@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

3

Tout d'abord, merci pour ta réponse.

"un PIC par effecteur" : je n'y connais rien en PIC, c'est quoi 'effecteur' ?
Plusieurs PIC, aïe, tu dis ça pour me faire peur?
D'ailleur la mise en oeuvre du PIC m'inquiete un peu, je regarde donc vers des modules comme çeux là, mais avec ça, le robot ne serait plus autonome, en plus d'avoir un fil à la pate. Mais, cela parait beaucoup plus simple, qu'en penses tu?

Je suppose que pour un néophyte, c'est pas l'idéal, mais que penses tu des gros PIC comme les ARM en 50mhz ou plus? Est ce qu'au final on a pas des prix equivalents à un système qu'il faudrait upgrader avec plus ou moins de bonheur?

Pour les moteurs pas à pas, merci du tuyau, je regarderais, mais je pense que les servos reviennent moins cher et je n'ai pas specialement besoin de precision.

4

Un effecteur, c'est un moteur, un pas-à-pas, un servo, etc., bref, un système qui transforme l'information venant du centre de décision (les PICs) en effet (d'où le terme effecteur) mécanique.
Et plusieurs PICs, ça se fait très bien : pour Yokozuna (cf. ce topic), il y a 3 moteurs pas-à-pas, donc 3 PICs, et en 1 semaine, je suis passé du stade 'je ne connais rien du tout aux PICs' au stade 'chaque PIC commande son moteur pas-à-pas d'après ce que lui disent des capteurs, et communique avec les autres PICs'.
Les PICs sont des 16F84A à 20 MHz, et cette année, on va peut-être utiliser des 16F877, bien que je les trouve un peu gros ...

La différence entre un PIC 16F84A et les modules dont tu parles, c'est qu'il faut programmer toi-même le PIC.
Certes, je conseille un seul PIC par effecteur (donc par servomoteurs par exemple), mais comme un servo se commande par un seul fil, donc une seul patte, on peut sans autre problème que la programmation commander 8 servos avec un 16F84A.
De plus, ce qu'il y a sur le premier module, c'est un 16F84A ou équivalent, donc coûte au grand maximum 4 ou 5 € si tu n'en prends pas en échantillon gratuits, donc à 46,60 €, on te fait payer le programme et les quelques composants de la plaquette.
Concernant le dernier module de la page : Le Circuit intégré "SI2C20" est un microcontrôleur "PIC16F872" pré-programmé pour la commande de servomoteurs.
Un 16F872 coûte $2.81, donc à 17 €, on te fait payer uniquement le programme ...

Maintenant, c'est à toi de voir si tu te sens capable d'apprendre et d'appliquer l'Assembleur PIC.
Si tu décides de le faire, c'est avec plaisir que je t'aiderai dans la programmation du PIC.

@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

5

Pourquoi conseilles tu d'utiliser un PIC par effectueur?

6

Pour un pas-à-pas (unipolaire ou bipolaire), il faut 4 fils de commande, et un 16F84A n'en a que 12 disponibles (en fait 13, mais RA4 ne compte pas).
Or, bien souvent, l'action d'un effecteur (pas-à-pas ou servo) dépend de l'état de plusieurs capteurs, lesquels sont branchés sur les 8 pattes libres du PIC (en fait 6, puisque j'utilise RB0 et RB1 pour communiquer avec les autres PICs).
Pour un servo, comme ça n'utilise qu'un seul fil, je peux éventuellement en mettre plusieurs sur un seul PIC, mais le programme devient alors monstreux pour pouvoir gérer en parallèle tous les effecteurs.
Je préfère largement un seul effecteur par PIC, avec éventuellement communication avec un PIC de niveau décisionnaire supérieur, le PIC se contentant alors de transformer l'information (qui tient souvent sur un seul octet, donc se transmettant rapidement sans prendre toutes les ressources temps du PIC effecteur) du PIC au dessus en une commande de l'effecteur, commande qui prend bien souvent 99% des ressources temps, puisqu'il faut en permanence fournir la bonne commande au moteur.

Euh ... je suis assez clair, là hehe ?
Si tu as un exzemple plus concret, je pourrais peut-être être plus explicite.

@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

7

Un exemple concret de ce dont nous parlons, non.
En tout cas, merci de prendre le temps de m'expliquer tout ça.
Je peux donner un exemple simple de ce que je vais faire pour commencer:
-controler le robot 'rob' de la nes (3 axes seulement, mais pas de capteur)
-quand je maitriserais le premier point, je compte faire pareil avec un Robotarm (bras manipulateur, jouet d'il y a qq années encore trouvable sur EBAY, sans capteur ni butée, je compte donc l'asservir avce des servo)
-plus tard...j'y suis pas encore comme tu vois wink

8

-controler le robot 'rob' de la nes (3 axes seulement, mais pas de capteur)
Et si, du point de vue du PIC, il y a des capteurs : la manette hehe !
Pour être plus précis, il y a 3 capteurs, 1 par axe (un potentiomètre par axe dans les manettes classiques, mais le détail importe peu.

@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

9

Pour connaitre la position des differents moteurs, à part le cas des moteurs pas à pas (pour une raison d'encombrement et de prix) et le cas des servo-moteurs (cher aussi) qu'est ce que je peux faire?
Les codeurs sont à mon avis ce qu'il y a de mieux, mais ca parait compliqué, long à faire, et cher (decidemment).
Je pense donc à des potentiomêtres, mais je ne sais pas comment m'y prendre...

10

Pour les PàP et les servos, tu n'as pas à connaître la position, puisque c'est toi qui l'impose hehe.
Sinon, comme moteur, il reste celui à courant continu, sauf que tu as ici une commande en vitesse (servo : commande en position absolue / PàP : commande en position incrémentale), donc il faut en effet un capteur pour stopper le moteur à la position voulue.
Ceci a déjà été discuté ici, tu devrais y trouver quelques pistes ...
Mais il n'est aucunement question de potars qui sont trop contraignants à cause du maintien mécanique et de la limitation de la course du moteur.

@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

11

J'ai juste survolé le lien que tu m'as donné car j'ai moi aussi motorisé un telescope, donc je vois un peu de quoi il est question.

Je souhaiterais en revenir aux potentiomêtres, car les moteurs pas-à-pas et les codeurs, c'est cher, et encombrant : (Je met de coté l'aspect mécanique, qui pourrait être reglé par une bonne démultiplication.)
Les robots ludiques (aibo, Icybie...) utilisent des potentiomêtres, plus une protection mécanique, avec un étalonage au démarrage. Ce choix est sans aucun doute tres rentable et semble efficace. D'ailleur les servomoteurs utilisent également un potentiomêtre, donc je reste tres interressé par la question, ayant là un bon rapport précision/cout. Malheureusement, je ne sais pas comment les faire lire par le PIC.

Je ne vois toujours pas pourquoi tu prefères utiliser un pic par effecteur, ça implique autand de cartes, la création d'un protocole de communication, et que tout ça marche ensemble. Tu as dit:"Le Circuit intégré 'SI2C20' est un microcontrôleur "PIC16F872", donc je ne vois pas pourquoi utiliser 16 X PIC16F872 quand il est possible de le faire avec 1 seul ?

Avec le multiplexage, theoriquement, on peux augmenter le nombre de sortie avec peu de composants, mais par quoi est on limité (pour 1 pic) ?

L'assembleur j'ai bien envie de m'y mettre, j'ai vus un bout de code pour un pic, ça m'a presque paru aussi clair qu'en C. Si je peux en profiter pour apprendre l'asm pourquoi pas karate .

12

Les robots ludiques (aibo, Icybie...) utilisent des potentiomêtres, plus une protection mécanique, avec un étalonage au démarrage.
Outre l'aspect mécanique, le plus gros problème des potentiomètres est que ça limite la course du moteur.
Or, du moins pour Aïbo qui est sur pattes, les moteurs ne font pas un nombre indéterminé de tour, donc effectivement ça passe.

D'ailleur les servomoteurs utilisent également un potentiomêtre, donc je reste tres interressé par la question, ayant là un bon rapport précision/cout.
Un servomoteur a une course limitée à environ 180°/190°, donc là aussi, les potentiomètres passent sans problème.

Malheureusement, je ne sais pas comment les faire lire par le PIC.
Si tu veux plus qu'un simple seuillage (pour te caler sur une position précise) faisable avec un AOp, il faut utiliser un CAN ... ce qui est intégré dans le PIC 16F877 !

Je ne vois toujours pas pourquoi tu prefères utiliser un pic par effecteur, ça implique autand de cartes, la création d'un protocole de communication, et que tout ça marche ensemble.
J'utilise des 16F84A (12 fils) pour commander des PàP (4 fils), donc je ne peux physiquement pas mettre beaucoup d'effecteurs par PIC.
De plus, je préfère bien séparer toutes les actions élémentaires ... une conséquence de mon étude approfondie des Réseaux de Neurones Formels ^^ ?
Les PICs tournent alors en parallèle, ce qui donne une vitesse théorique maximale de nombre de PICs x 20 MHz.

Tu as dit:"Le Circuit intégré 'SI2C20' est un microcontrôleur "PIC16F872", donc je ne vois pas pourquoi utiliser 16 X PIC16F872 quand il est possible de le faire avec 1 seul ?
Là, oui, on peut utiliset un seul PIC, mais c'est parce que le 872 a beaucoup plus de pattes, et que les servos n'utilisent qu'un seul fil.

Avec le multiplexage, theoriquement, on peux augmenter le nombre de sortie avec peu de composants, mais par quoi est on limité (pour 1 pic) ?
Le programme devient très vite monstrueux, d'où en partie le prix élevé des modules tous faits.

L'assembleur j'ai bien envie de m'y mettre, j'ai vus un bout de code pour un pic, ça m'a presque paru aussi clair qu'en C. Si je peux en profiter pour apprendre l'asm pourquoi pas karate .
Dans mes bras !!!
Enfin quelqu'un que l'Asm ne rebute pas ! Surtout que, contrairement à la légende, ce n'est pas compliqué du tout, il suffit de savoir exactement ce que l'on veut faire faire au PIC.
en 1 semaine, je suis passé du stade 'je ne connais rien du tout aux PICs' au stade 'chaque PIC commande son moteur pas-à-pas d'après ce que lui disent des capteurs, et communique avec les autres PICs'.


@++
avatar
Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

13

(mirdouille j'av pas vu ces topics ^^)

Bon alors GUNNM laisse moi rire ce circuit qu'ils vendent la peau du fondement n'est pas quelque chose d'extraordinaire si tu apprends quelques notions d'assembleur PIC.

En effet le programme n'est pas "monstrueux" (tiens Ethaniel j'ai souvenance d'un programme ASM (auquel j'ai modestement contribué) qui faisait un certain codage ... il était comment cui là si les servos c monstrueux hehe ? )

Alors voila.
Laisse moi te rappeler comment fonctionne un servo.
C'est un moteur asservi en boucle fermée par un potentiomètre: La commande extérieure fournit une information de position, qui est comparée en permanence avec la position du potard interne solidaire de l'axe de sortie, et la position est réactualisée en permanence par le moteur pour suivre la commande.

La commande extérieure prend la forme d'un signal logique TTL, modulé en largeur d'impulsion. La période du signal est de 20 ms (50 Hz). Le rapport cyclique varie entre 5 et 10 %. Pratiquement, pour mettre le servo à "gauche" tu envoies une impulsion de 1 ms toutes les 20 ms, et pour le mettre à "droite" tu envoies une impulsion de 2 ms toutes les 20 ms. Toute position intermédiaire se réalise avec des impulsions de durée intermédiaire.

La feinte pour commander plusieurs servos à la fois, c'est de les commander en séquence l'un après l'autre.
Comme tu dois envoyer au max des impulsions de 2ms toutes les 20ms, tu peux commander 10 servos avec un pic.

Voila le truc écrit en pseudo-code

variables:
pos[10]
compteur

programme_principal:
2ms -> période_interruption_timer
0 -> compteur

interruption_port_série:
lire num_servo
lire position
position -> pos[num_servo]

interruption_timer:
maj_servo(compteur)
compteur++
compteur==10 => 0->compteur

maj_servo:
active_sortie(compteur)
délai(1ms + pos[compteur]/256 * 1ms)
désactive_sortie(compteur)

Bon:
Chaque servo est MAJ toutes les 10 IRQ du timer, soit toutes les 20 ms
Chaque servo reçoit une impulsion de 1 à 2 ms en 256 pas
Bah c tout.
10 servos sur 1 pic.