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

Reliable data of the system’s states, inputs and outputs over time is important when debugging state-space controllers and observers. One common approach is to send this data over NetworkTables and use tools such as Shuffleboard, which allow us to both graph the data in real-time as well as save it to a CSV file for plotting later with tools such as Google Sheets, Excel, or 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.

JAVA

@Override
public void robotPeriodic() {
   NetworkTableInstance.getDefault().flush();
}

C++

void RobotPeriodic() {
   NetworkTableInstance::GetDefault().Flush();
}

PYTHON

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>.