194 réponses à ce sujet

[Mike118]

Comme ça j'essayerait de faire des essais à couple résistant constant. 

( En gros le servo actionne une poulie qui enroule un câble ( rayon de poulie pour le calcul du couple supposé constant )  le câble étant lesté  par une masse variable pour les essais )
Le but étant de remplacer l'élastique par un outil permettant de caractériser le couple que peut fournir le système... 

 

Cela permettrai aussi de jouer un peu avec les paramètres de vitesse max atteignable pour un courant de consigne donné sous une charge donnée. L'idée derrière étant de voir si le système est suffisament précis pour servir de "capteur"  => Voir si on peut se servir des donnée pour détecter quand la patte du quadrupède touche le sol en réel, et vérifier si ça correspond à la théorie qu'on imagine au préalable en fonction du modèle cinématique qu'on se donne ... 

 

Je ne sais pas si je suis à 100% clair dans ce que je veux dire...

[Oracid]

Je me suis mis en plein écran. Où regarder pour voir la consigne et savoir si vraiment tu l'as atteinte ?

Par exemple, à 1'09", tu annonces un débattement de 90°. Comment connaitre la position de départ et celle d'arrivée ?

[pat92fr]

Je me suis mis en plein écran. Où regarder pour voir la consigne et savoir si vraiment tu l'as atteinte ?

Par exemple, à 1'09", tu annonces un débattement de 90°. Comment connaitre la position de départ et celle d'arrivée ?

 

Bonne question : 

 

Le débattement est de +/- 45° autour de 90° (position neutre).

 

Lorsque la consigne est à 45°, le servo tend l'élastique. La position courante est de 45° environ. Il arrive à la consigne avant de repartir dans l'autre direction.

 

Lorsque la consigne est de 135°, le servo est entrainé par l'élastique qui se détend. La position courant est de 142°. Il 'overshoot' un peu. Il dépasse un peu la consigne avant de repartir.

 

La courbe bleu correspond à la consigne transmise au servo.

La courbe rouge (et le cadre rouge) représente la consigne calculée par le servo à tout instant.

La courbe noire (et le cadre noir) représente la position réelle.

 

J'ai mis des limites en courant, vitesse et accélération pour faire ce test. Il doit y avoir un peu de marge pour augmenter les performances.

Pour l'overshoot, un meilleur réglage PID peut certainement améliorer un peu les choses.

 

En outre, le servo que j'utilise pour faire les tests est ruiné. Quand je le tourne à la main, on sent les dents cassées. Je ferai de nouvel essai avec un MG92b neuf.

 

Patrick.

[Oracid]

Pourquoi face à 'Goal position", il y a un champs de saisie avec 30°, alors que le champs, à droite, indique la consigne de 45° à 135°.

Mais je ne vois pas où tu saisies la consigne.

 

Tu es donc passé au 8,4V. Le MG90S avait des dents cassées, avant ou après le test ?

Economise plutôt tes MG92B, si tu as d'autres MG90S.

Au fait, as-tu reçu tes servos Feetech ?

[pat92fr]

C'est une case qui permet de saisir une consigne manuellement, puis de l'envoyer au servo.

 

Sur les dernières vidéo, c'est une fonction qui dépend du temps qui génère la consigne, et l'envoie au servo automatiquement (les cases à cocher en haut de la fenêtre).

 

J'ai cassé les dents en faisant les tous premiers tests de courant. Le servo a tapé sur ses butées mécaniques. J'ai d'autres MG90s pour faires les tests.

 

Au sujet des SCS2332, j'ai tout reçu rapidement de Feetech. Je m'en occuperai l'année prochaine.

 

Patrick.

[pat92fr]

Bonjour,

 

Les mesures de courant moteur (shunt) et de position (potentiomètre) sont bruités. Je mets en place des filtres pour obtenir une estimation exploitable pour l'asservissement. Ces filtres vont impacter les performances de l'asservissement, à cause du retard qu'ils vont introduire. Il ne faut donc pas trop filtrer les signaux pour conserver de bonnes performances.

 

Apres quelques essais, j'arrive au résultat suivant avec un servo de 0.1s au 60° :

 

Le courant et la position sont coupés à 100Hz. la vitesse est recoupée à 20Hz. Le signal PWM est coupé à 20Hz.

Les courbes de position vitesse courant sont assez bien lissées et je n'ai pas constaté de retard significatif.

Note : Comme le servo peut faire 5 oscillations de 60° par seconde (5Hz), la fréquence minimale de filtrage doit se situer vers 10Hz. J'ai pris une marge en choisissant 20Hz.

 

Quelques liens utiles :

* Pour le filtrage d'un PID, j'ai trouvé cet article intéressant : https://controlguru....n-our-pid-loop/

* Pour l'implémentation d'un filtre de type EWMA : https://www.norwegia...stop-filtering/

* Pour le calcul de la fréquence de coupure d'un filtre EWMA : https://dsp.stackexc...t-off-frequency

      * Tableau Excel : https://docs.google....#gid=1625755230

 

 

Concernant l'asservissement, j'ai atteint un premier palier dans le déroulement de mon petit projet. Je vais maintenant m'occuper de l'interface de communication du servo. Le principe d'un bus de communication est de pouvoir piloter plusieurs servos en même temps via la même interface. Je vais assembler un second servo et faire des tests dans les prochains jours.

 

A suivre.

Patrick.

[pat92fr]

Comme ça j'essayerait de faire des essais à couple résistant constant. 

( En gros le servo actionne une poulie qui enroule un câble ( rayon de poulie pour le calcul du couple supposé constant )  le câble étant lesté  par une masse variable pour les essais )
Le but étant de remplacer l'élastique par un outil permettant de caractériser le couple que peut fournir le système... 

 

Cela permettrai aussi de jouer un peu avec les paramètres de vitesse max atteignable pour un courant de consigne donné sous une charge donnée. L'idée derrière étant de voir si le système est suffisament précis pour servir de "capteur"  => Voir si on peut se servir des donnée pour détecter quand la patte du quadrupède touche le sol en réel, et vérifier si ça correspond à la théorie qu'on imagine au préalable en fonction du modèle cinématique qu'on se donne ... 

 

Je ne sais pas si je suis à 100% clair dans ce que je veux dire...

 

Je vois.

 

Alors, j'ai besoin de fabriquer un banc de test pour mesurer précisément le couple/courant du servo.

 

Quand on lance une recherche sur le sujet, on tombe sur Oracid encore une fois !    https://www.youtube....h?v=QrZ3HRmbINs

 

En attendant, je fais quelques essais sur un coin de table !

 

Je ne pense pas qu'il soit possible de mesurer (avec précision) le couple avec un simple capteur de courant. En revanche, pour détecter le contact d'une patte sur le sol, je pense que la mesure est assez sensible et peut fonctionner.

 

 

Patrick.

[Oracid]

Quand on lance une recherche sur le sujet, on tombe sur Oracid encore une fois !    

 

Evaluer le couple en mesurant le courant me semble une bonne idée.

As-tu déterminé si le courant et le couple étaient proportionnels ?

[Mike118]

Théorie Pure en monde idéal :

Couple moteur = Kc * Intensité   

et

Vitesse de rotation = Kv * Voltage 

 

avec Kc et Kv des constantes.

Puissance moteur = Couple * Vitesse de rotation = Kc * Kn * Intensité * voltage = Kc * Kn * Puissance consommée = Puissance consommé * rendement ... 

( Bien entendu il faut exprimer les grandeurs dans les bonnes unités, et cela n'est que de la théorie sans frottement, sans prendre en compte le modèle dynamique du moteur ( inertie , échauffement etc ... ) 

Le bras robot avec fonctionnalité cobot mesure le couple de leurs articulations en fonction du courant consommé par leurs différents moteurs.

[pat92fr]

J'ai remplacé la balance par le pèse bagage et j'obtiens quelques mesures. Ca donne une tendance qui confirme le fait que ce soit linéaire.

 

Ca bug un peu sur la fin.

 

Patrick.

[pat92fr]

Bonjour,

 

J'ai finalement remplacé le servo qui m'a servi à faire tous les tests depuis le tout début ! R.I.P.

Je dispose maintenant de deux MG90s neufs hackés, que je peux mettre en réseau sur le même bus de communication et la même alimentation 8.4V. 

A cet effet, j'utilise les accessoires du commerce (cordons, hubs, adaptateur USB/Serie) pour faire les raccordements (produits Dynamixel et Feetech par exemple).

 

 

Coté API, j'ai commencé par faire celle en Python sur PC. Les instructions suivantes sont implémentées et ca fonctionne correctement :

- reboot

- ping

- read

- write

- sync write

- factory reset

 

La dessus, j'ai fait des instructions plus simples à utiliser :

- torque_enable(id)

- torque_disable(id)

- get_position(id)

- set_position(id,pos)

- get_current(id)

etc.

 

Avec le PC, j'obtiens un cadence de l'ordre d'une commande par ms. Si la commande consiste à lire ou écrire de nombreux registres d'un coup, ca prend jusqu'à 2ms (lecture RAM ou EEPROM complète).

Dans le cas d'une écriture dans un registre de type EEPROM, il faut compter un délai de 20ms pour que le servo finisse la programmation en Flash.

 

A partir de là, je me suis amusé à coder deux petites applications :

- mirror : un servo imite la position d'un autre servo.

- stall-guard : un servo tente d'atteindre une position donnée et fait demi-tour s'il rencontre un obstacle.

 

 

Pour vous donner une idée de l'API Python, voici le code source de ces petites applications (codées "vite fait") :

Code de mirror :

def mirror():
        servo = servo_protocol2('COM3',576000) # open com port
        servo.torque_enable(1) # use 1 as servo
        servo.torque_disable(2)# use 2 as position sensor
        counter = 5000 # 10-second loop
        while counter:
                counter -= 1
                pos = servo.get_position(2) # retrieve position of servo 2
                servo.set_position_velocity_current_pwm(1,pos,800,350,99) # set position of servo 1
                time.sleep(0.002) # wait for 10ms
        servo.torque_disable(1)

Code de stallguard :

def stallguard():
        servo = servo_protocol2('COM3',576000) # open com port
        servo.torque_enable(1) # use servo 1
        servo.torque_disable(2) # don't use servo 2
        counter = 0
        state = 0
        servo.set_position_velocity_current_pwm(1,30,360,150,99) # set position of servo 1 (default position)
        time.sleep(1.000)
        servo.set_position_velocity_current_pwm(1,120,30,150,99) # set position of servo 1 (target position)
        while 1:
                if state == 0:
                        current = servo.get_current(1)
                        if current > 100:
                                servo.set_position_velocity_current_pwm(1,30,360,350,99) # set position of servo 1 back to default position
                                state = 1
                        if counter > 300:
                                servo.set_position_velocity_current_pwm(1,30,360,150,99) # set position of servo 1 back to default position
                                state = 1
                else:
                        if counter > 400:
                                break
                counter += 1
                time.sleep(0.010) # wait for 10ms
        servo.torque_disable(1)

La prochaine étape est de faire une API compatible Arduino. Amazon vient de me livrer une Mega !

 

A suivre...

Patrick.

[Oracid]

Bravo !

J'aime bien la Motion Capture.

La détection d'obstacle est vraiment d'une grande sensibilité. La mesure de l'intensité fonctionne vraiment bien !

[pat92fr]

Bonjour,

 

Merci !

Oui, c'est plutôt sensible.

Dans la dernière vidéo, j'ai oublié de monter la séquence durant laquelle je faisais un enregistrement des mouvements des servo manipulés à la main, puis un replay de la trajectoire à vitesse accélérée !  Ce sera pour la prochaine fois !

 

 

Je viens de faire un essai avec une Arduino MEGA. 

 

Le principe de câblage est le suivant (source Feetech) :

 

J'ai raccordé le TTLinker sur l'UART1 de la MEGA, sachant que l'UART0 est réservée pour la communication avec l'ordinateur via USB.

 

En vrai, ca donne ca :

 

Je partais pessimiste quant au débit atteignable avec un microcontrôleur aussi faible (8bits, 16MHz). J'ai comméncé avec 115200bauds et puis j'ai augmenté en suivant le guide :

 

Et bien, j'ai été surpris ! Le débit max de 1Mbps passe pour les instructions simples comme un ping du servo par la MEGA.

Ping... reply delay:408us
model_number:92
firmware_version:0

Ping... reply delay:428us
model_number:92
firmware_version:0

Ping... reply delay:424us
model_number:92
firmware_version:0

Ping... reply delay:424us
model_number:92
firmware_version:0

L'API Arduino sera identique à l'API Python.

#include "MyServoProtocol2.h"

MyServoProtocol2 servo(1000000); // 1Mbps
uint16_t model_number = 0;
uint8_t firmware_version = 0;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

void loop() {
  Serial.print("Ping... ");
  
  int error = servo.pingCommand(1,&model_number,&firmware_version); // Ping servo ID = 1, Return model and version
  if(error !=0)
  {
    Serial.print("rx_packet_error:");
    Serial.println(error);
  }
  else
  {
    Serial.print("model_number:");
    Serial.println(model_number);

    Serial.print("firmware_version:");
    Serial.println(firmware_version);
    Serial.println("");
  }

  delay(1000);
}

Les délais en fonction du débit sont les suivants :

* 115200 bauds ==> 1.4ms

* 250000 bauds ==> 0.7ms

* 500000 bauds ==> ~440us

* 1000000 bauds ==> ~430us

 

Le temps de réponse est grandement lié à la vitesse d'exécution des piles protocolaire sur le STM32G4 et sur le MEGA.

 

 

Je termine de coder l'API Arduino et je passe à .... et bien je ne sais pas. Je commence à avoir fait le tour pour ce premier prototype !

 

A suivre...

[Oracid]

Je ne suis pas sûr d'avoir tout compris. En fait, je suis sûr du contraire.

Peux-tu nous faire un résumé des fonctionnalités, de ce que peut faire, ton prototype et ta bibliothèque ?

 

Si tu cherches du blé à moudre, j'ai des tas d'idées . . .

[pat92fr]

Bonsoir,

 

Pour résumer, la petite carte associée à un servo modélisme (micro ou supérieur) offre les fonctionnalités suivantes :

- Activer ou désactiver le moteur du servo

- Contrôler la position du servo

- Limiter les débattements min et max (ou pas)

- Limiter la vitesse de rotation (ou pas)

- Limiter l'accélération (ou pas)

- Limiter le couple (ou pas)

- Récupérer la position courante,

- Récupérer la vitesse courante,

- Récupérer le couple courant,

- Récupérer la température du moteur (optionnel, si thermistance installée),

- Récupérer la tension d'alimentation,

- Régler les coefficients PID de la boucle d'asservissement (compliance)

- Programmer des seuils d'alarme (température, courant, tension batterie, erreur de communication)

- Allumer/éteindre une LED située sur la carte.

 

Du point de vue matériel, la carte est compatible d'une tension d'alimentation 8.4V (Lipo 2S) en direct (10V maximum), et elle peut piloter un moteur jusqu'à 3.6A maximum (bridée à 1A pour un micro servo). Le capteur de position doit être un potentiomètre (analogique) ou un encodeur magnétique (à sortie PWM). 

 

La carte fonctionne de manière autonome ; c'est à dire que la dernière consigne reçue est mémorisée et s'applique jusqu'à la prochaine consigne reçue. Pas besoin de renvoyer une consigne périodiquement pour maintenir la position du servo.

 

Plusieurs cartes peuvent être raccordées en parallèle sur une même UART, via un adaptateur (TTLinker ou équivalent).

Ainsi, il est possible de piloter jusqu'à 252 cartes en parallèle. Chaque carte dispose de son propre identifiant configurable (1..252) . Le débit de la liaison série est validée jusqu'à 1Mbps. Le maximum doit se situer autour des 4Mbps.

 

Quelques fonctionnalités avancées permettent :

- d'interroger une carte pour vérifier son bon raccordement/fonctionnement (ping),

- de restaurer la configuration usine de la carte (factory reset),

- de redémarrer une carte (reboot).

 

Si l'UART est configurée à 1Mbps, il est possible d'envoyer au moins 1000 messages par seconde. 

La carte supporte les communication en mode "broadcast". Un même message peut contenir plusieurs consignes destinées à plusieurs servos.

 

 

C'est grosso modo ce que fait n'importe quel servo intelligent du commerce, du genre Dynamixel, Feetech, Lynxmotion, Lewansoul, etc.

Mais je ne prétends pas que mon code soit aussi fiable et performant que les produits du commerce actuels. Cela reste un prototype bricolé sur un coin de table !

 

 

La première fonctionnalité qui me semble particulièrement intéressante est de pouvoir récupérer la position et la vitesse des servos à tout instant :

- C'est utile pour calibrer un robot multipatte (mesure des neutres des articulations)

- C'est utile pour vérifier la trajectoire réelle d'une patte par rapport à la trajectoire planifiée dans le code, voire de l'optimiser.

 

La seconde fonctionnalité intéressante pourrait être la récupération du couple afin de détecter le contact d'une patte avec le sol.

 

La troisième est la capacité à ajuster le PID de l'asservissement en position/vitesse/couple :

- Suppression des phénomènes de tremblement des membres et réduction des grésillements en charge !

- Programmation d'une légère "compliance" (logicielle).

 

 

Je pense que le plus gros défaut pour l'instant est que la carte est trop grande par rapport au micro servo. En janvier, je pense faire une troisième itération de conception matérielle pour essayer de compacter le design. En outre, fin décembre, je m'attends à recevoir une carte similaire adaptée aux servos standards à fort couple, permettant de tenir des courants plus forts (5 à 10A). Les fonctionnalités seront identiques à la version micro servo.

 

 

Petit à petit je me rapproche de la conception d'une carte de contrôle pour servo à base de moteur brushless et d'encodeur magnétique... pas à pas. Je ne me vois pas utiliser 12 cartes Tinymovr ou Moteus, ou encore 6 cartes Odrive, pour l'instant, sans passer par une phase préalable prototypage par moi même, pour comprendre comment ca fonctionne.

 

Patrick.

[pat92fr]

Bonsoir,

 

Si je retire la connectique pour le capteur de température et l'encodeur magnétique, qui n'est pas utile pour piloter un micro servo MG9x ou un servo de taille standard basique, et si je tasse un peu l'électronique, je passe d'un PCB de 24x22 à 22x16mm. La carte peut alors être soudée à la façon d'un ESC, en coupure sur le cordon servo et recouvert d'une gaine thermo. Il y aura 3 fils vers l'Arduino (serial, vin, masse) et 5 fils vers le servo (Moteur A/B, et potard A/B/C). Il faudra souder la carte à proximité du servo pour limiter les perturbations sur les fils du potentiomètre. J'ai aussi retiré la mesure de tension batterie qui n'apporte pas grand chose et qui peut être implémentée ailleurs dans un robot.

 

Voici le TOP :

 

Au dos, il n'y a que le STM32G4.

 

Malheureusement, je ne peux pas optimiser plus avec le catalogue de composants disponible pour profiter du montage chez JLCPCB. Les composants en boitiers QFP et SOP sont volumineux, et les versions QFN/DFN/BGA ne sont pas disponibles. Je me laisse un petit délai de réflexion et je passe commande. Ce sera certainement la version finale de la partie matérielle de ce prototype.

 

Patrick.

[Oracid]

La carte peut alors être soudée à la façon d'un ESC . . .

Aujourd'hui, les ESC's, sur un drone, sont regroupés au centre du drone et constitue un étage de l'électronique qui souvent en comporte plusieurs; carte de distribution d'alimentation, carte ESC's, carte microcontrôleur et batterie. Cette organisation est sans doute le résultat d'une réflexion sur la meilleure répartition des masses.

Peut-être faudrait-il s'en inspirer ?

Un exemple : Tcmrc 50A ESC contrôleur de vol pour pilote Novice 50A ESC 2 6S Dshot600 4 en 1 pilote de Drone de course FPV | AliExpress

Dans ce type de montage, il n'y a qu'un seul STM32 pour l'ensemble des moteurs. Là, encore, est ce qu'un STM32 par servo est vraiment nécessaire ?

[pat92fr]

Intéressant !

 

Pour un quadrupède, une seule carte pour 8 ou 12 servos risque d'être pénalisant en termes de poids, à cause du nombre de fils (5 fils par servo) et de leur longueur pour converger vers une seule carte au centre du robot. 

 

Une seule carte par patte, permettant de piloter jusqu'à 3 servos, est peut-être le bon compromis.  Je peux essayer de faire un design d'une carte à 3 servos pour voir.

 

A suivre.

[Oracid]

Les fils, ce n'est pas ce qu'il y a de plus lourd. De plus, il faudra quand même, au moins 2 fils pour l'alimentation.

De toute façon, libre à chacun de positionner les cartes où bon lui semble. 

Par exemple, j'imagine très bien un râtelier de distribution d'alimentation.

Le problème, c'est que les connecteurs de la tension et de la masse ne sont pas isolés sur un coté.

[pat92fr]

Le problème, c'est que les connecteurs de la tension et de la masse ne sont pas isolés sur un coté.

Qu'est ce que tu entends par là ?

 

En fait, ma petite carte peut etre empilée par le connecteur de droite. Le connecteurs de gauche et du centre, reste propre à un servo.