Classroom troubleshooting¶

Individual faults — a motor that will not answer, a mis-set ID, a wrong HOME pose — are in the learner troubleshooting page. This page is about the ones that are specific to a room full of machines.

The lab machines cannot see the arm at all¶

Work through it in this order.

Is it Chromium? Chrome, Edge, Brave, Opera. Firefox and Safari cannot talk to hardware, full stop, and a managed fleet that standardises on Firefox will block the course entirely.
Is device access allowed? Enterprise browser policy can disable the serial and USB permission prompts. If the port chooser never appears, or appears empty on every machine while a personal laptop works, this is it — talk to whoever manages the policy.
Is the driver there? The board presents as a USB serial device. On a locked-down image the driver may not install for a standard user.
Is the cable a data cable? Test with a known-good one before escalating anything.

Test all four on a real lab machine under a real learner account, before the course starts. A test on the teacher's laptop with admin rights proves nothing.

Links arrive by email and expire in ten minutes. In schools, the usual causes are a filtered mailbox and pupils opening the link on a phone instead of the computer in front of them.

Mitigations: tell them to open the link on the lab machine, allow ten minutes for it in the first session, and if the institution supports Google accounts, prefer Continue with Google — it avoids the mailbox entirely.

Remote sessions never connect on the school network¶

The most common institutional blocker. The connection is peer-to-peer using a public STUN server with no relay fallback, so a firewall that blocks UDP or restricts NAT traversal stops it from forming, usually with no error message — it simply never connects.

Test it on the school network the week before.
If it fails, fall back to physical rotation with a shared calibration, which needs nothing from the network. See Sharing one arm.
If the network team will help, the traffic is standard WebRTC with STUN.

One arm behaves differently from the others¶

Almost always calibration. Arms are individually calibrated, and an arm that was rebuilt, dropped or had a servo swapped needs it again.

Keep a known-good exported calibration per arm, and label the arms physically. An unlabelled shelf of identical arms is how a class ends up calibrating the same one three times.

A pair is stuck and cannot say why¶

The four questions that resolve most of it:

Does the connection table show six motors OK?
Does the 3D twin follow when you move a joint by hand?
Has this arm been calibrated on this account?
Is the emergency stop latched from earlier?

The class is out of step with each other¶

Expected, and it is why the platform gates module by module rather than by the calendar. Two things help: run the hardware step as a rotation so the fast pairs are not idle, and let the fast pairs work ahead on the virtual arm rather than inventing extension tasks.

Something is wrong with the platform itself¶

Use Send feedback inside the Lab — it attaches a screenshot. Include the module and step, the browser and version, the connection method, and whether it reproduces on more than one machine. That last detail is the one that distinguishes a platform bug from a machine that needs a different cable.