Quelle liste de contrôle de démarrage permet aux sessions OpenArm de rester suffisamment répétables pour les téléopérations, les démonstrations et la collecte de données ultérieure ?
Nous voulons un fil de discussion de liste de contrôle OpenArm convivial pour les débutants, axé sur l'étalonnage et le référencement.\n\nQuel ordre de démarrage exact suivez-vous et qu'enregistrez-vous lorsque quelque chose semble différent de la session précédente ?\n\nSi vous répondez, incluez une vérification qui a évité un débogage inutile plus tard.
La meilleure liste de contrôle est suffisamment courte pour être suivie à chaque fois. Si cela devient trop long, les équipes arrêtent de l'utiliser lorsqu'elles sont pressées.
Les changements d'outils et les événements de transport méritent leur propre note car ils expliquent souvent des dérives qui semblent à première vue sans rapport.
Partagez la plus petite liste de contrôle d'étalonnage qu'une autre équipe OpenArm pourrait copier dans son carnet de laboratoire aujourd'hui.
Choisissez votre symptôme le plus proche pour suivre le bon chemin de dépannage.
Commencez par une vérification reproductible des symptômes pour « [OpenArm] Liste de contrôle d'étalonnage et de référencement pour les constructeurs intégrateurs (débutant) », puis confirmez l'état de l'hôte/du service avant de modifier le matériel ou le micrologiciel.
journalctl -b | rg -n "error|warn|openarm|can"
ip -details link | rg -n "can|state"
python tools/preflight_check.py --quickAjoutez une simple porte de contrôle en amont et une courte liste de contrôle de démarrage afin que les régressions soient détectées avant le début du mouvement.
Utilisez-les d’abord comme modèle de liste de contrôle. Confirmez les noms d’interface, les identifiants d’appareils et les conditions de sécurité dans votre propre cellule avant l’exécution.