Débogage des modèles et contrôleurs d’espace d’état
Vérification des signes
L’une des causes les plus courantes de bogues avec les contrôleurs d’espace d’état est le mauvais agencement des signes (+ ou -). Par exemple, les modèles inclus dans WPILib s’attendent à ce qu’une tension positive entraîne une accélération positive, et vice versa. Si l’application d’une tension positive ne fait pas accélérer le mécanisme vers l’avant, ou si le déplacement «vers l’avant» fait diminuer le codeur (ou d’autres lectures de capteur), ils doivent être inversés de sorte qu’une entrée de tension positive entraîne une lecture de codeur positive. Par exemple, si j’applique une entrée de \([12, 12]^T\) (vitesse maximale vers l’avant pour les moteurs gauche et droit) à ma base pilotable de type différentielle, mes roues devraient propulser mon robot « vers l’avant » (le long de l’axe + X), et pour mes encodeurs de lire une vitesse positive.
Important
Le WPILib DifferentialDrive
, par défaut, n’inverse aucun moteur. Vous devrez peut-être appeler la méthode setInverted(true)
sur l’objet contrôleur de moteur pour inverser afin que l’entrée positive crée un mouvement vers l’avant.
L’importance des graphiques
Des données fiables de l’état du système, entrées et sorties en fonction du temps sont importantes lors du débogage des contrôleurs et des observateurs d’espace-état. Une approche courante consiste à envoyer ces données sur les NetworkTables et à utiliser des outils tels que le Shuffleboard, qui nous permettent à la fois de représenter graphiquement les données en temps réel et aussi bien que les enregistrer dans un fichier CSV pour un traçage ultérieur avec des outils tels que Google Sheets, Excel ou Python.
Note
Par défaut, les NetworkTables sont limités à un taux de rafraîchissement de 10 hz. Pour les tests, cette limitation peut être contournée avec l’extrait de code suivant pour soumettre des données jusqu’à 100hz. Ce code doit être exécuté périodiquement pour forcer la publication de nouvelles données.
Danger
Cette opération enverra des données supplémentaires (jusqu’à 100hz) sur NetworkTables, pouvant ainsi causer des retards avec le code utilisateur et les dashboards des robots. Ce qui augmentera également l’utilisation du réseau. C’est souvent une bonne idée de désactiver cette fonctionnalité pendant les compétitions.
@Override
public void robotPeriodic() {
NetworkTableInstance.getDefault().flush();
}
void RobotPeriodic() {
NetworkTableInstance::GetDefault().Flush();
}
from ntcore import NetworkTableInstance
def robotPeriodic(self):
NetworkTableInstance.getDefault().flush()
Compensation du retard d’entrée
Souvent, certaines données d’entrée du capteur (c’est-à-dire les lectures de vitesse) peuvent être retardées en raison du filtrage intégré que les contrôleurs de moteur intelligents ont tendance à effectuer. Par défaut, le gain K du LQR ne suppose aucun retard d’entrée, donc l’introduction d’un retard significatif de l’ordre de dizaines de millisecondes peut provoquer une instabilité. Pour lutter contre cela, le gain K du LQR peut être réduit, échangeant les performances contre la stabilité. Un exemple de code permettant de compenser cette latence de manière mathématiquement rigoureuse est disponible :ref: ici <docs / software / advanced-controls / state-space / state-space-intro: LQR and Measurement Latency Compensation>.