Robot-chat & synchronisation coude+épaule

Salut. Ca progresse! C'est un très bon début, même s'il reste encore du boulot.

J'aime beaucoup ton projet en tout cas!

Plusieurs commentaires

* ne surtout pas mettre de rampe, de filtre ou quoi que ce soit dans le contrôle moteur (chip allegro). Il ne doit y avoir aucun filtre entre la commande du PID et le moteur. Le moteur doit appliquer bêtement, le plus rapidement possible ce qu'a décidé le PID, sans retard. Sinon le PID fonctionnera mal. C'est pareil pour la mesure des capteurs, aucun filtre, ça doit être brut. De plus, il faut bien étudier les temps de transfert qui doivent être les plus courts possibles. Donc le conseil d'Ashira était vraiment mauvais.

* Si filtrage il doit y avoir, il se fait au niveau de la consigne, en amont du PID. C'est bien ce que j'ai proposé avec la limitation/saturation de vitesse et/ou d'accélération.

* je pense que tu n'as pas encore activé de stratégie de limitation en accel, ça explique partiellement l'accroche au changement

* Pour régler le PID, il faut impérativement le faire avec des courbes. Pas juste à l'oeil nu! Sans mesure, tu vas perdre énormément de temps. Fais sortir ça par liaison série par exemple, puis affiche le tout sous Matlab ou excel. On active d'abord kp (coef proportionnel), et on doit avoir en réaction à un échelon de consigne (consigne d'angle), un suivi rapide, avec un très léger dépassement de consigne, mais sans oscillation. Et après, il faut régler les autres paramètres. Et c'est seulement une fois les 3 coefs réglés que tu pourras obtenir des mouvements fluides.

* il faut être méthodique pour régler tout ça. Ne pas commencer comme tu le fais avec toute la stratégie activée. Personnellement, je commencerai par régler le PID (d'abord kP, puis kD, puis kI), 1 seul actionneur à la fois (coude puis épaule). Seulement après tu pourras activer les étapes 1 (lissage de consigne) et 2 (cinématique inverse). Attention à ne pas bruler les étapes, tu vas t'embrouiller.

* Pour que l'ensemble fonctionne, il faut impérativement que la consigne qui entre dans le PID soit réaliste. Si cette condition n'est pas remplie, tu auras des "accroches", l'asservissement essayant de rattraper son retard. A toi de vérifier, mais la consigne doit être suivie très précisément à tout instant. Et je pense que ça n'est pas le cas sur tes vidéos. A toi de sortir les courbes.

* question : où sont tes capteurs de positions? L'idéal, c'est d'avoir un codeur sur l'axe du moteur, et je n'en vois pas chez toi... C'est la seule méthode fiable pour mesurer la vitesse qui sert à la partie dérivée du PID.

* Pour les vidéos Youtube, il faut mettre l'URL comme ça directement dans le texte du message; donc prendre le lien "watch". J'ai modifié tes posts.

https://www.youtube.com/watch?v=RqkqbUmfJ5s

Leon.

Merci! Moi j'aime beaucoup l'aide que tu m'apportes!

Je nous ai d'ailleurs trouvé un gros point commun, en lisant tes notes sur SCRIBOT j'ai vu que tu avais horreur de reprendre un code déjà fait et que tu faisais tout à 100% maison!

Je suis exactement pareil!

Parce que les libs des autres ça marche jamais chez nous...

Et je préfère éviter d'avoir des boites noirs au milieux de mes projets.

----

Bref,

J'ai une limitation de vitesse seulement en effet.

Je vais essayer de désactiver les rampes de mes puces (impossible de les désactiver totalement cependant), je vais quand même garder le système qui permet à la puce de déplacer le rotor en une position connue, ça pourrait être pratique!

Pour la partie mesure, je regarderai au scope mon potar.

La valeur que le potar dépend directement de la consigne, donc je ferai un calcul pour avoir la bonne tension en guise de consigne et l'afficherai au scope (histoire d'avoir un repère sur l'erreur statique) à travers un pont de R par exemple, commandée par une broche qui sort de mon µC (pour le bon timing).

Je touche à Kp uniquement, j'ai bien compris que le reste dépend de celui-ci.

Pour la vitesse exacte des moteurs j'ai aussi la solution d'utiliser la sortie tacho de mes drivers.

Elle est propre et bien proportionnelle à la vitesse, j'ai vérifié. Et puis elle est déjà câblée au µC, c'est d'ailleurs prévu de rajouter un convertisseur fréquence/tension pour soulager mon µC.

Mes capteurs de positions sont des potars qui sont dans les boites (potar 360°).

Je me remet au boulot environ demain soir, j'ai des cours toute la journée.

Pour la vitesse exacte des moteurs j'ai aussi la solution d'utiliser la sortie tacho de mes drivers.

Elle est propre et bien proportionnelle à la vitesse, j'ai vérifié. Et puis elle est déjà câblée au µC, c'est d'ailleurs prévu de rajouter un convertisseur fréquence/tension pour soulager mon µC.

Attention à plusieurs choses:

* Déjà, soulager le microcontrôleur avec un convertisseur fréquence-tension, c'est une assez mauvaise idée. Faire une conversion fréquence->tensiion->numérique, c'est pas terrible du tout.

Essaye d'avoir un ordre de grandeur de la fréquence maxi du signal (mesure à l'oscillo). Un microcontrôleur peut mesurer des signaux très rapides : facilement à 10kHz. Plusieurs méthodes sont possibles : soit mesures par interruption (mesures à 10kHz et plus), soit si tu as des entrées de comptage dédiées (et là, tu peux souvent monter à 1MHz).

Ca dépend aussi du type de microcontrôleur (8bits, 16bits, 32 bits, fréquence d'horloge).

Au pire, si tu veux vraiment délester ton microcontrôleur, utilise un compteur, mais surtout pas un convertisseur fréquence/tension.

* Mais surtout, le plus gros problème que je vois, c'est l'absence du signe de la vitesse en sortie du module Allegro. Ton contrôleur moteur est avant tout fait pour contrôler la vitesse de rotation d'un truc qui tourne en continu et tout le temps dans le même sens: pompe, ventilateur. Or, tu te trouveras forcément avec des phases où tu pilotes ton moteur dans un sens, mais qu'il tourne encore dans l'autre à cause de l'inertie. Tu pourras peut-être estimer le signe (sens de rotation) à l'aide du potentiomètre.

* attention aussi, dans mes souvenirs, ce type de mesure fonctionne assez mal à très basse vitesse. C'est décrit dans le datasheet : à l'arrêt, on perd la position, et il faut au moins 1 tour moteur pour s'y retrouver. Rien ne remplace un capteur réel, au plus près du moteur. Mais à toi de voir. Un potentiomètre très précis et surtout monté sans jeu, avec un réducteur sans jeu, ça permet déjà de faire des choses.

Du coup, j'ai de gros doutes sur le choix du contrôleur moteur que tu as fait. A très basse vitesse, il y a de fort risques que ça accroche systématiquement. Car le contrôleur ne sait plus où en est le moteur, et ne sait pas quelle phase piloter. Dans mon industrie automobile (je suis ingé en électronique automobile), on utilise un mélange de moteurs à courant continu, moteurs brushless avec ou sans capteur de position.

Et dès qu'on veut utiliser du brushless avec asservissement en position et/ou capable de fournir un couple précis à 0rpm, alors il n'y a pas le choix : il faut un capteur de position au cul du moteur. Et ce capteur doit alimenter à la fois le driver moteur, et la logique. Or, ton allego est incapable de digérer des signaux capteur...

Un capteur moteur à courant continu est beaucoup plus simple à mettre en oeuvre, et ça fonctionne très bien! On choisi le brushless pour 2 choses:

* vitesse de rotation maxi très élevée (ce qui n'est pas ton cas)

* endurance énorme, car pas de charbons (pareil, je ne pense pas que ton montage va fonctionner des milliers d'heures)

A toi de voir ce que tu réussis à faire avec le montage actuel. Mais si tu as systématiquement des accroches autour de 0rpm, même avec tous les réglages possibles, alors je pense qu'il faudra changer des choses.

Leon.

Bon, on a un choix à faire à ce que je vois.

Le choix implique un changement de techno moteur. Il est vrai que pour notre cas, le choix du moteur brushless n'était pas une super idée!

Le choix se porte donc sur :

# Des moteurs brushless avec capteurs intégrés, implique un changement de puce. Il y en a plein chez Allegro qui gèrent ça.

Ca rendra, je l'espère, le démarrage plus facile et surtout plus fluide.

# Des moteurs courant continu.

Pour cette solution, on va chercher une puce un minimum sophistiquée plutôt qu'un simple pont en H. Il faudrait pouvoir au moins avoir quelques sécurités tel que température, court-circuit. N'oublions pas que notre structure est en PVC pour l'instant et que les brushless ont eu tendance à la faire légèrement fondre de temps en temps...

Quand je regarde l'avancée que j'ai fait avec les brushless j'ai tendance à croire que c'est possible. Il aura peut être pas une démarche super naturelle et fluide mais au moins il marchera. (Mais je serai loin d'être satisfait!)

Notre oral de projet c'est dans 50 jours, j'ai encore largement le temps de tester la techno brushless.

On fait nos calculs pour les moteurs CC.

Salut, de nouvelles remarques:

* mes conseils sur le changement de techno ne sont que des conseils. Je n'ai pas le montage en main, donc à toi de voir s'il est indispensable de changer de techno ou non.

* si tu utilises des moteurs à courant continu, je te conseille une nouvelle fois de prendre des moteurs avec un codeur (capteur) au cul du moteur. Codeur magnétique ou optique. Il en existe de plein de sortes. Ca donne une position et une vitesse avec une résolution énorme (geâce à la démultiplication du réducteur), ce qui est nécessaire quand tu fais un asservissement très rapide (une centaine de fois par secondes). Choisir des moteurs "tout fait" plutôt que d'acheter séparément les codeurs, c'est quand même plus pratique

* le codeur doit impérativement donner le sens de rotation. Codeur à 2 sorties en quadrature de préférence, ou codeur sortant 1 signal sens + 1 signal sens.

* côté acquisition des signaux des codeurs, encore une fois tu as plusieurs possibilités. Soit acquisition direct par ton microcontrôleur, selon la puissance de ton µc, le nombre de codeurs à gérer, etc... Soit tu utilises des composants dédiés au "comptage" des tops des codeurs pour décharger le µc. Sur mon robot bipède inachevé BOB5, j'utilisais des LSI7366 qui dialoguent en SPI. Mais il en existe d'autres.

* Si ton robot chat est destiné à marcher réellement, et donc que ta patte devra porter le chat, alors la mise au point du PID (=réglage des paramètres) ne doit pas se faire qu'à vide. Ton PID doit être suffisamment robuste pour suivre la consigne dans toutes les conditions d'utilisation : patte levée ou patte posée au sol.

Leon.

J'ai sortit les courbes du PID :

C'est le coude. On dirait que ça marche pas trop mal comme ça mais c'est vraiment moche en fait...

Je sais pas trop comment je vais faire pour régler ça!

Les conditions sont vraiment différentes :

- Pour remonter il a besoin de plus de force

- Quand la patte sera au sol c'est pareil

- ...

J'ai refais tout mon code, c'était le vrai bordel à force de rajouter des trucs partout!

C'est mieux maintenant et ça remarche comme avant.

Je bosse sur le bridage de l'accélération, c'est pas terrible pour l'instant. Je dois encore améliorer mon code.

Je tiens au courant!

Pour la techno des moteurs, je pense qu'on ne va pas changer les brushless. La méca va bouger par contre, on hésite à faire en sorte que le coude soit piloté par l'épaule.

Donc peut être plus de commande individuelle pour le coude. Ca retire la capacité de l'assoir, ou le faire marcher (ou courir) normalement. On travaille là dessus.

Pour le réglage du PID, il y a plein de cours qui trainent sur Internet. La méthode empirique est, de loin, celle qui fonctionne le mieux.

Pour régler, on règle d'abord kP, puis kD, puis kI.

Méthode pragmatique (il existe des méthodes empiriques beaucoup plus détaillées sur la toile) que j'applique.

* kP (avec kD et kI forcés à zéro): avec juste kP, tu dois converger "rapidement" face à un échelon, mais sans oscillation, en autorisant un petit dépassement de consigne dans certaines situations, en fin de mouvement. Dans tous les cas, ne pas chercher la perfection. Il est normal d'avoir des écarts avec la consigne (erreur d'offset). Rester le plus loin possible d'un kP qui provoque des oscillations.

* kD : avec Kp et kD activés : tu dois obtenir une bonne réactivité dans toutes les conditions, et annuler les dépassements de consigne en "fin de mouvement". L'idéal est de régler avec une rampe rapide, et non avec un créneau. ATTENTION : cette partie dérivée a besoin d'un capteur très précis. Un potentiomètre bas de gamme avec une micro-linéarité merdique empêchera d'obtenir de bons résultats. Le codeur au cul du moteur est encore une fois la solution optimale. Un potentiomètre de précision peut donner de bons résultats aussi.

* kI : les 3 coefs activés. On va chercher à compenser les erreurs "constantes", erreurs d'offset. Il faut régler pour avoir à la fois une compensation correcte des erreurs d'offset, avoir une réactivité suffisante face aux changements de configuration du système (transition patte posée/en l'air), tout en restant très en dessous des valeurs de kI qui amènent à des oscillations. C'est ce kI qui va permettre une différence d'effort entre la montée et la descente de la patte, ou entre patte posée/patte levée.

Un bon réglage s'adaptera naturellement à toutes les situations : jambe levée, jambe posée, mouvement vers le haut ou vers le bas. Une fois que ça fonctionne, c'est magique.

Et encore une fois, attention à un truc hyper important : le PID ne permet d'obtenir un résultat correct que si la consigne est atteignable! Si tu demandes une vitesse plus rapide que celle que ne savent fournir tes moteurs, dans certaines situations de vie (patte posée), alors ça fonctionnera très très mal. Pareil si les moteurs ne sont pas assez puissant pour juste porter la bestiole.

Je te conseille fortement de ne pas te contenter d'un oscillo pour observer le suivi de consigne. Si tu as un microcontrôleur et un moyen de communication entre ce microcontrôleur et un PC (câble de débug, port série), alors tu peux tout transmettre en temps réel au PC.

Perso, quand je règle un PID, je me fait un scénario de test avec 2 ou 3 mouvements représentatifs, et je stocke TOUTES les courbes résultantes avec les différents réglages de coef. Ca permet réellement de comprendre ce qu'il se passe en consultant toutes les courbes.

Il me faut en général une vingtaines de tâtonnements successifs, donc une vingtaines de courbes. C'est long, mais c'est nécessaire.

Leon.

J'avais bien compris comment régler le PID, mais la méthode d’acquisition des courbes restait un problème.

Je vais mettre en place un système de retour de valeur avec mon µ.

Je me demande si LA SOLUTION ultime serait pas de lâcher nos potar pour avoir une roue codeuse "au cul du moteur" comme tu le dis si bien.

Pour ça, on forme un pic à faire la conversion roue_codeuse->angle en faisant un apprentissage à la mise en marche...
On garde les potars pour les butées "urgentes" quand même!

Tu as raison, on va plutôt faire ça. Ca sera surement plus simple pour développer le système, les potars m'ont souvent rendu des valeurs étranges...

Les calculs sont fait pour qu'une patte puisse soulever la moitié du chat.

Titus