Affichage des diagnostics

Mesures de qualité d’ajustement

There are three numerical accuracy metrics that are computed with this tool: acceleration r-squared, simulated velocity r-squared, and the simulated velocity RMSE.

The acceleration r-squared is the fraction of the variance in measured acceleration (used as the independent variable in the SysId regression) explained by the linear model. This can be quite variable, because acceleration is very susceptible to system noise. Assuming the other fit metrics are acceptable, values near 1 indicate an « ideal » mechanism with few disturbances, while values near 0 indicate a noisy mechanism with substantial physical vibrations/losses.

La vitesse simulée r au carré est la fraction de la variance de la vitesse mesurée expliquée par une simulation sans bruit du mouvement du moteur avancé avec les constantes déterminées à partir de la régression. Une valeur au nord de .9 indique un bon ajustement.

La vitesse simulée RMSE est l’écart type de l’erreur de vitesse du modèle simulé. Il s’agit d’une bonne estimation de la quantité de bruit de processus présent pendant la routine de test, et peut être utilisée comme estimation basse pour le terme de bruit du modèle dans state-space control.

Parcelles diagnostiques

SysId produit également plusieurs diagrammes de diagnostic pour aider les utilisateurs à évaluer la qualité de l’ajustement de leur modèle.

Tracés temporels

Note

Pour améliorer la qualité des tracés, les tracés de diagnostic sont séparés par direction. Assurez-vous de visualiser à la fois les tracés avant * et * arrière lors du dépannage !

Les diagrammes de diagnostic dans le domaine temporel affichent la vitesse en fonction du temps au cours des tests analysés. Ceux-ci devraient ressembler à ceci :

Les tracés du domaine temporel de vitesse contiennent trois ensembles de données : données brutes, données filtrées et simulation. Les données brutes sont les données enregistrées de votre robot, les données filtrées sont les données après qu’un filtre médian a été appliqué aux données, et la simulation représente les prédictions de vitesse d’un modèle basées sur les gains anticipés de l’outil (ce sont utilisé pour calculer les métriques d’erreur « sim » mentionnées ci-dessus).

Un graphe quasistatique réussi sera presque linéaire, tandis qu’un graphe dynamique réussi sera une approche approximativement exponentielle de la vitesse constante.

Un écart par rapport à ce comportement est le signe d’une erreur, soit dans la configuration de votre robot, les paramètres d’analyse ou votre procédure de test.

Graphique Accélération-Vitesse

Le tracé de l’accélération par rapport à la vitesse affiche la vitesse du mécanisme par rapport à la partie de l’accélération correspondant à des facteurs autres que le frottement (idéalement, cela ne laisserait que la force contre-électromotrice) et la tension appliquée sur * tous * les tests.

Ce tracé devrait être assez linéaire, avec des patchs de données quasi-statiques relativement silencieuses mélangées à des données dynamiques assez bruyantes. Le bruit sur les sections dynamiques du tracé peut être réduit en augmentant le paramètre Taille de la fenêtre.

Cependant, si votre robot ou mécanisme a une masse faible par rapport à la puissance du moteur, cela peut « entamer » le peu de données d’accélération significatives dont vous disposez. Dans ces cas, kA tendra vers zéro et peut être ignoré à des fins d’anticipation. Cependant, si kA ne peut pas être mesuré avec précision, les gains de rétroaction calculés sont susceptibles d’être inexacts et un réglage manuel peut être nécessaire.

Modes de défaillances courantes

Lorsque quelque chose s’est mal passé avec l’identification, les tracés de diagnostic et la sortie de la console fournissent des indices cruciaux sur * ce qui * s’est mal passé. Cette section décrit certains échecs courants rencontrés lors de l’exécution de l’outil d’identification du système, les caractéristiques d’identification de leurs tracés de diagnostic et les étapes qui peuvent être prises pour les résoudre.

Seuil de mouvement mal défini

L’une des erreurs les plus courantes est le choix d’une valeur inappropriée pour le seuil de mouvement.

Seuil de vitesse trop bas

La présence d’une « queue avant » (accentuée par un cercle rouge ajouté) dans le tracé quasistatique du domaine temporel indique que le paramètre Velocity Threshold est trop bas, et donc les points de données avant que le robot ne commence à se déplacer sont en train d’être inclus.

Pour résoudre ce problème, augmentez le seuil de vitesse et réanalysez les données.

Seuil de mouvement trop élevé

Bien qu’il ne soit pas aussi problématique qu’un seuil trop bas, un seuil de vitesse trop élevé entraînera un grand « écart » dans le tracé de l’accélération par rapport à la vitesse.

Pour résoudre ce problème, diminuez le seuil de vitesse et réanalysez les données.

Signaux de vitesse bruyants

Note

Il existe deux types de bruit qui affectent les systèmes mécaniques : le bruit du signal et le bruit du système. Le bruit du signal correspond à une erreur de mesure, tandis que le bruit du système correspond à un mouvement physique réel qui n’est pas pris en compte par votre modèle (par exemple, des vibrations). Si SysId suggère que votre système est bruyant, vous devez déterminer lequel des deux types de bruit est en jeu - le bruit du signal est souvent plus facile à éliminer que le bruit du système.

De nombreuses configurations FRC souffrent d’encodeurs mal installés - des erreurs de concentricité de l’arbre (pour les encodeurs optiques) et d’emplacement de l’aimant (pour les encodeurs magnétiques) peuvent toutes deux contribuer à des signaux de vitesse bruyants, tout comme des paramètres de filtrage inappropriés. Le bruit de l’encodeur sera immédiatement visible dans vos tracés de diagnostic, comme on peut le voir ci-dessus. Le bruit de l’encodeur est particulièrement courant sur les boîtes de vitesses toughbox mini fournies dans le kit de pièces.

Les paramètres système peuvent parfois être déterminés avec précision même à partir de données polluées par le bruit du codeur en augmentant le paramètre de taille de fenêtre. Cependant, ce type de bruit d’encodeur est problématique pour le code du robot de la même manière qu’il l’est pour l’outil d’identification du système. Comme la cause profonde du bruit n’est pas connue, il est recommandé d’essayer une configuration d’encodeur différente si cela est observé, soit en déplaçant les encodeurs sur un arbre différent, en les remplaçant par un type d’encodeur différent, ou en augmentant l’échantillon par moyenne dans la génération de projet (ajoute une couche supplémentaire de filtrage).