Documentation des classes
classe abstraite utilisé par AdvancedAccelerationLimiter et SimpleAccelerationLimiter. Communalise le code qui permet d'appliquer une limite à l’accélération uniquement.
La limite d’accélération est une constante
J'ai observé avec plusieurs de nos robots, qu'on peut accélérer plus fort une fois le robot en mouvement qu'a l’arrêt. J'ai donc bricolé un petite algo pour faire varier l’accélération en fonction de la vitesse actuelle et donc accélérer plus fort une fois en mouvement tout en ne burnant pas au départ. Pour cela, on défini une accélération minimale (Acc_min) et une maximale (Acc_max) ainsi qu'une vitesse à partir de laquelle on considère qu'on peut appliquer l’accélération max (high_speed_threshold). Si la vitesse actuelle est nulle, on va utiliser Acc_min, si la vitesse actuelle est supérieure ou égale à high_speed_threshold, on va utiliser Acc_max, et entre 0 et high_speed_threshold, on va faire varier linéairement l’accélération max entre Acc_min et Acc_max.
Permet de contrôler finement l’accélération et la décélération en marche avant et arrière. Cette classe est basée sur une version modifié de l'algo présentée ici : https://www.mdpi.com/1996-1073/12/7/1222/pdf L'algorithme tire parti du fait que le correcteur de distance est un proportionnel pur, et est donc prévisible. L'algorithme calcule d'abord une vitesse max atteignable avec une accélération/deceleration défini pour la consigne actuelle, puis en déduit une courbe qui va être soustraite à la sortie du régulateur P, de manière à générer une belle courbe qui permet de decellerer à la bonne vitesse, depuis le bon endroit, pour atteindre la cible. Comme toujours dans ce genre de cas, cela ne fonctionne pas de manière magique, il faut régler un coeff d’amortissement (dampling) qui permet de décélérer plus tôt, car (entre autre) l'inertie du système n'est pas prise en compte dans le calcul.
Demandez à Cho de PM-Robotix
Demandez à Cho de PM-Robotix ##QuadratureEncoder : Exploite les décodeur de quadrature hardware du microcontrôleur de la nucleo. On n'est donc pas pollué par des interruptions dans le flot d’exécution.
Cette classe permet de contrôleur en vitesse une des roues du robot. La régulation est basé sur un PI avec une protection antiWindup, dont le principe a été repris de l'ODrive.
Comme le speedController, cette classe régule en vitesse une des roues en utilisant un PI. A la différence prêt qu'il y a plusieurs set de (Kp;Ki) qui vont être utilisé en fonction de la vitesse actuelle de la roue. On s'est rendu compte qu'il est difficile de trouver un set de (Kp;Ki) qui permette à la fois de suivre des consignes de vitesse faibles et fortes ( sans un overshoot de taré hein :-D ). Actuellement j'ai 3 set de (Kp;Ki) possible dans la classe, mais en utilisation je me suis rendu compte que 2 suffisent en général. Cette classe est un enfant de SpeedController, ce qui permet de la substituer et de ne pas dupliquer le code du PI. Mais le résultat n'est vraiment pas fou en terme d'ingénierie logiciel, donc je pense faire une vrai interface SpeedController.
Interface qui permet d'ajouter d'autres carte moteur...
Carte de puissance (https://www.robot-electronics.co.uk/htm/md22tech.htm) qui date de temps imémoriaux (d'avant notre vénérable président, c'est dire !). Qui est grosse, pas pratique, ne peut pas fournir beaucoup de courant, mais à l'avantage d'être quasi idiot-proof :)
Demandez à Cho de PM-Robotix
Estimation de la position en (x,y,thêta) du robot en partant du principe qu'entre 2 calcul, le robot a suivi une trajectoire en forme d'arc de cercle. ===> Lien vers une des docs sur le sujet
Régulateur proportionnel pur qui permet de réguler la distance ou l'angle.
Estimateur de vitesse inspiré de celui codé dans l'Odrive. C'est un estimateur basé sur une boucle de régulation PI, j'avoue que c'est un peu magique mais ça a le bon goût de marcher :) Pourquoi utiliser un estimateur de vitesse? Augmenter la frequence d'asservissement a beaucoup d'avantages, mais lorsque la vitesse est faible, la vitesse minimale estimée devient grande.
Exemple, pour une frequence d'asserv de 500hz, soit Dt=0.002s, des roues de 3cm de rayon, soit un perimetre de 188.5 mm. Pour un encodeur de 4096ticks par tour, on a 0.04 mm/tick. Donc 1 tick mesuré sur une période d'asserv donne : (0.041)/0.002=20mm/sec et pour 2 : (0.042)/0.002=40mm/sec On comprends bien qu'on ne peut pas s'asservir sur ce genre de mesure... D'où l'estimateur, qui permet de lisser tout ça ! Si vous voulez aller plus vous pouvez lire ce thread : https://discourse.odriverobotics.com/t/rotor-encoder-pll-and-velocity/224
Il faudra par contre régler la bande passante de cet estimateur, et pour cela je n'ai rien trouvé de très cadré. Je l'ai toujours réglé de manière empirique en utilisant plotjuggler pour superposer la courbes des ticks codeurs brute et l'estimation de la vitesse. Plus la bande passante est faible, plus la vitesse estimée sera lissée, mais plus elle aura du retard! A l'inverse plus la bande passante est grande, plus l'estimation de vitesse sera réactive, quitte à devenir instable !
Cette partie permet de gérer le déplacement du robot sur la table , elle prend en entrée des commandes de haut niveau de déplacement sur table et en sort des consignes en distance et angle. J'ai fais un découpage assez strict pour bien séparer les sujets et factoriser le code :
Une classe simple qui permet de gérer une liste de Commandes. L’implémentation ne nécessite pas de lock, ce qui est mieux pour notre cas d'utilisation temps réel.
Classe centrale qui permet d'ajouter de nouvelles commandes dans la liste, de mettre ou enlever un arrêt d'urgence, de remonter un statut pour le haut niveau et de lancer le calcul de nouvelles consignes pour le régulateur de distance et d'angle.
Comme son nom l'indique, cette commande permet d'avancer tout droit, en faisant varier la consigne du régulateur de distance uniquement
Comme son nom l'indique, cette commande permet de tourner d'un angle spécifié, en faisant varier la consigne du régulateur d'angle uniquement
Permet d'aller à une position en (x;y) sur la table. L'algorithme fonctionne en 4 étapes,
- tant que le robot n'est pas suffisamment aligné vers le point cible, on donne uniquement des consignes d'angles.Par exemple, si on donne une cible derrière nous, cela évite de faire un grand arc de cercle non maîtrisé sur la table.
- Calculer en temps réel une consigne d'angle et de distance en fonction de notre position actuelle par rapport a la cible
- Une fois que le robot est en dessous d'une certaine distance, on ne calcule plus que des consignes d'angles. Sans cette étape, si on passe un mm à droite de la cible, le delta de distance sera de 1mm mais le delta d'angle sera de 90°, et donc le robot va se mettre à tourner autour de la cible.
- Une fois que la distance par rapport au point cible est en dessous d'un seuil, on se considère comme arrivé, et on peut donc passer à la commande suivante.
Il y a donc 3 paramètres à régler :
- arrivalDistanceThreshold_mm : Distance en mm en dessous de laquelle, on considère qu'on est arrivée sur la cible, pour l'étape 4
- gotoReturnThreshold_mm : Distance en mm à partir de laquelle, on ne calcul plus de consigne d’angle pour l'étape 3
- gotoAngleThreshold_rad : Angle en radian au delà du quel, on ne génère pas de consigne de distance pour l'étape 1
Permet de faire face à un point en (x;y) sur la table. Il n'y a qu'un seul paramètre à régler, m_arrivalAngleThreshold_rad, angle en radian en deçà du quel, on considère le but atteint.
Cette commande offre le même service qu'un Goto, mais tente de ne pas s’arrêter sur le point mais de passer proche en ralentissant si le point suivant est enchainable. Cette commande reste un peu du bricolage, et n'est pas facile à appréhender ni régler.