Hello la communauté !

D'abord merci et bravo pour tes tutos lobodol !

Confinement oblige, je me suis lancé dans la réalisation d'un petit drone....

J'essaie d'adapter le PID en fonction des mesures d'angle de mon système
et je n'arrive pas à saisir la diference entre les valeurs de
measures[] et angular_motions[] pour le calcul des erreurs. En gros j'ai
en sortie de mon AHRS les mesures déjà optimisées en degré (-90/+90
pour pitch/roll et 360 pour yaw) et je souhaite les utiliser pour
calculer les erreurs du PID.

je me demande aussi l'utilité des ces calculs:

    // To dampen the pitch and roll angles a complementary filter is used
    measures[ROLL]  = measures[ROLL]  * 0.9 + gyro_angle[X] * 0.1;
    measures[PITCH] = measures[PITCH] * 0.9 + gyro_angle[Y] * 0.1;
    measures[YAW]   = -gyro_raw[Z] / SSF_GYRO; // Store the angular motion for this axis

    // Apply low-pass filter (10Hz cutoff frequency)
    angular_motions[ROLL]  = 0.7 * angular_motions[ROLL]  + 0.3 * gyro_raw[X] / SSF_GYRO;
    angular_motions[PITCH] = 0.7 * angular_motions[PITCH] + 0.3 * gyro_raw[Y] / SSF_GYRO;
    angular_motions[YAW]   = 0.7 * angular_motions[YAW]   + 0.3 * gyro_raw[Z] / SSF_GYRO;

Si quelqu'un aurait pourrait m'éclairer, merci d'avance !

Salut GttbbCgvhhbv, bienvenue

measures est un tableau qui contient les angles en degré pour chacun des axes alors que angular_motions contient les vitesses angulaires en degré/seconde.

Le code dont tu parles est une implémentation d'un filtre passe-bas numérique. Ça sert à éviter d'avoir des valeurs fluctuantes.

Le calcul des erreurs se fait en comparant la vitesse angulaire set_points avec la vitesse angulaire angular_motions. Le calcul du set_point est fait à partir de la vitesse angulaire et de l'angle du drone, dans la fonction calculateSetPoint().

Avec l'inclinaison seule, tu ne pourras pas implémenter un régulateur comme je l'ai fait.

Merci pour ta réponse j'avoue avoir déjà mieux compris en relisant encore une fois. j'avais omis la notion de vitesse angulaire.
j'ai peut être posté un peu trop vite et désolé aussi pour le GttbbCgvhhbv faut que je pense à le modifier chez google

Je dois donc maintenant essayer de convertir mes inclinaisons en vitesse angulaire à l'inverse de ton algo a priori... ?
Alors comment faire...... 

j'ai pensé (trop rapidement ?) à un simple :
angular_motions[ROLL] = measures[ROLL]-measures_previous[ROLL]

en enregistrant donc les mesures précédentes..... ce qui me donne un angle en °/4ms ??

Si c'est trop simple c'est peut être que quelque chose m’échappe....
merci si tu as 2 min pour infirmer ma petite réflexion.. ou pas ;)

La vitesse angulaire étant la dérivée de la position angulaire, en théorie oui tu peux la calculer comme ça. A ceci prêt qu'il faut diviser par la période d'échantillonnage à savoir 4ms. Ainsi tu obtiens une valeur en dégrés/seconde.

Mais vérifie si tu n'as pas directement accès à cette information car à mon avis tu vas perdre de précieux cycles processeur à calculer une info dont tu disposes déjà.

je n'ai pas accès à la vitesse angulaire dans mon systeme, et en effet il lui faut 3.5ms pour effectuer tout les calculs.

trop long pour permettre en même temps de produire un signal de 250hz

J'ai donc opté pour un système à deux µc, un tiny85 qui s'occupe de l'IMU
le µc principal cadencé à 250hz lui demande d'effectuer les calculs toutes les 12ms (via les interruptions) et lui demande
les valeurs à la même intervalle via I2c.
le µc principal s'occupe ensuite de calculer le PID et de produire les 4 signaux vers les ESC

le temps disponible restant du µc pricipal (0.6ms)  et celui de L'IMU (6-8ms) pourront servir par la suite à d'autres fonctions

je n'ai pas pu tester car je n'ai pas recu les ESC/moteurs mais tout les timing semblent bons

je me pose la question de savoir si un ESC prevu pour fonctionner à 250hz fonctionnerait à une autre fréquence...
auquel cas je reviendrais sur mes choix....

à priori la consommation du tiny85 ne devrait pas trop impacter l'ensemble...

quand aux resultats du PID il m'est difficile de voir si le reslutat est bon,
difficile d'interpreter les courbes, en plus sur 4 sorties...... j'attend de recevoir le matos...

le µc principal cadencé à 250hz lui demande d'effectuer les calculs toutes les 12ms

Quel est l'intérêt d'avoir un µC cadencé à 250Hz dans ce cas ? Ta fréquence d'échantillonnage est au final de 83Hz...

De mémoire il me semble que la lib Servo.h génère des signaux de 50Hz. Dans mon code je génère des signaux de 250Hz et ça fonctionne bien. Je ne connais pas la fréquence max admissible par les ESC mais entre 50Hz et 250Hz normalement pas de problème.

La raison du 2eme UC était de pouvoir générer un signal de 250hz, mais effectivement si les esc fonctionnent à des fréquences inférieures ça n'a pas d'intérêt... ( Les spec de celui que j'ai commandé est donné à 250 Hz et je ne pensais pas que cela pouvait fonctionner même à 100hz...)

Maintenant je vais peut être rester sur ce choix afin de gérer un futur GPS, une commande en Arduino pure (jai quelques emmeteurs / récepteurs en stock....)
pourquoi pas des servos pour une caméra, soyons fou !...
rien n'est figé tout est câblé en l'air sur une breadboard... Je donnerais des nouvelles sur mon projet s'il abouti