Dépannage en classe¶

Les pannes individuelles — un moteur qui ne répond pas, un ID mal réglé, une mauvaise pose HOME — sont traitées dans la page de dépannage des apprenants. Cette page concerne celles qui sont propres à une salle pleine de machines.

Les machines de la salle ne voient pas du tout le bras¶

Procédez dans cet ordre.

Est-ce Chromium ? Chrome, Edge, Brave, Opera. Firefox et Safari ne peuvent pas dialoguer avec du matériel, point final, et un parc géré standardisé sur Firefox bloquera entièrement le cours.
L'accès aux périphériques est-il autorisé ? Une politique d'entreprise sur le navigateur peut désactiver les demandes d'autorisation série et USB. Si le sélecteur de ports n'apparaît jamais, ou apparaît vide sur toutes les machines alors qu'un portable personnel fonctionne, c'est cela — parlez-en à la personne qui gère la politique.
Le pilote est-il présent ? La carte se présente comme un périphérique USB série. Sur une image verrouillée, le pilote peut ne pas s'installer pour un utilisateur standard.
Le câble est-il un câble de données ? Testez avec un câble dont vous êtes sûr avant de faire remonter quoi que ce soit.

Testez ces quatre points sur une vraie machine de la salle, avec un vrai compte d'apprenant, avant le début du cours. Un test sur le portable de l'enseignant avec des droits d'administrateur ne prouve rien.

Le lien de connexion de tout le monde est lent ou absent¶

Les liens arrivent par e-mail et expirent au bout de dix minutes. Dans les établissements scolaires, les causes habituelles sont une boîte filtrée et des élèves qui ouvrent le lien sur leur téléphone au lieu de l'ordinateur devant eux.

Parades : dites-leur d'ouvrir le lien sur la machine de la salle, prévoyez dix minutes pour cela lors de la première séance, et si l'établissement prend en charge les comptes Google, préférez Continue with Google — cela évite complètement la boîte mail.

Les sessions à distance ne se connectent jamais sur le réseau de l'établissement¶

Le blocage institutionnel le plus courant. La connexion est de pair à pair via un serveur STUN public, sans relais de secours : un pare-feu qui bloque l'UDP ou restreint la traversée de NAT l'empêche donc de s'établir, généralement sans message d'erreur — elle ne se connecte tout simplement jamais.

Testez-la sur le réseau de l'établissement la semaine précédente.
En cas d'échec, repliez-vous sur la rotation physique avec une calibration partagée, qui ne demande rien au réseau. Voir Partager un bras.
Si l'équipe réseau veut bien aider, le trafic est du WebRTC standard avec STUN.

Un bras se comporte différemment des autres¶

Presque toujours la calibration. Les bras sont calibrés individuellement, et un bras qui a été remonté, qui est tombé ou dont un servo a été changé doit être recalibré.

Conservez pour chaque bras une calibration exportée réputée bonne, et étiquetez physiquement les bras. Une étagère de bras identiques non étiquetés, c'est ainsi qu'une classe finit par calibrer trois fois le même.

Un binôme est bloqué et ne sait pas dire pourquoi¶

Les quatre questions qui règlent l'essentiel :

Le tableau de connexion affiche-t-il six moteurs OK ?
Le jumeau 3D suit-il quand on bouge une articulation à la main ?
Ce bras a-t-il été calibré sur ce compte ?
L'arrêt d'urgence est-il encore enclenché depuis tout à l'heure ?

La classe n'avance pas au même rythme¶

C'est attendu, et c'est pour cela que la plateforme progresse module par module plutôt que selon le calendrier. Deux choses aident : organisez l'étape matérielle en rotation pour que les binômes rapides ne restent pas inactifs, et laissez-les prendre de l'avance sur le bras virtuel plutôt que d'inventer des tâches d'approfondissement.

Quelque chose ne va pas avec la plateforme elle-même¶

Utilisez Send feedback dans Lab — il joint une capture d'écran. Indiquez le module et l'étape, le navigateur et sa version, le mode de connexion, et si le problème se reproduit sur plus d'une machine. Ce dernier détail est celui qui distingue un bug de la plateforme d'une machine qui a besoin d'un autre câble.