Fehlerbehebung im Klassenraum

Einzelne Fehler – ein Motor, der nicht antwortet, eine falsch gesetzte ID, eine falsche HOME-Pose – stehen auf der Fehlerbehebungsseite für Lernende. Auf dieser Seite geht es um die Probleme, die typisch für einen Raum voller Rechner sind.

Die Rechner im Raum sehen den Arm überhaupt nicht

Geh es in dieser Reihenfolge durch.

1. Ist es Chromium? Chrome, Edge, Brave, Opera. Firefox und Safari können nicht mit Hardware sprechen, Punkt – und ein verwalteter Gerätepark, der auf Firefox standardisiert ist, blockiert den Kurs vollständig.
2. Ist der Gerätezugriff erlaubt? Unternehmensrichtlinien für den Browser können die Berechtigungsabfragen für seriell und USB deaktivieren. Erscheint die Anschlussauswahl nie, oder ist sie auf jedem Rechner leer, während ein privater Laptop funktioniert, liegt es daran – sprich mit den Verantwortlichen für die Richtlinie.
3. Ist der Treiber vorhanden? Die Platine meldet sich als USB-Seriell-Gerät. Auf einem stark abgesicherten Image lässt sich der Treiber für ein Standardkonto möglicherweise nicht installieren.
4. Ist das Kabel ein Datenkabel? Teste mit einem bekannt guten Kabel, bevor du irgendetwas eskalierst.

Teste alle vier Punkte an einem echten Rechner im Raum unter einem echten Konto einer lernenden Person, bevor der Kurs beginnt. Ein Test auf dem Laptop der Lehrkraft mit Administratorrechten beweist nichts.

Bei allen kommt der Anmeldelink spät oder gar nicht

Die Links kommen per E-Mail und laufen nach zehn Minuten ab. In Schulen sind die üblichen Ursachen ein gefiltertes Postfach und Schülerinnen und Schüler, die den Link auf dem Handy statt auf dem Computer vor ihnen öffnen.

Gegenmaßnahmen: Sag ihnen, sie sollen den Link auf dem Rechner im Raum öffnen, plane in der ersten Sitzung zehn Minuten dafür ein, und wenn die Einrichtung Google-Konten unterstützt, bevorzuge Continue with Google – das umgeht das Postfach komplett.

Remote-Sitzungen verbinden sich im Schulnetz nie

Der häufigste institutionelle Blocker. Die Verbindung läuft Peer-to-Peer über einen öffentlichen STUN-Server ohne Relay als Rückfallebene; eine Firewall, die UDP blockiert oder NAT-Traversal einschränkt, verhindert also den Aufbau, meist ohne Fehlermeldung – es verbindet sich einfach nie.

• Teste es in der Woche davor im Schulnetz.
• Schlägt es fehl, weiche auf die physische Rotation mit geteilter Kalibrierung aus; sie braucht nichts vom Netzwerk. Siehe Einen Arm teilen.
• Falls das Netzwerkteam helfen will: Der Datenverkehr ist Standard-WebRTC mit STUN.

Ein Arm verhält sich anders als die anderen

Fast immer die Kalibrierung. Arme werden einzeln kalibriert, und ein Arm, der neu aufgebaut, fallen gelassen oder mit einem neuen Servo versehen wurde, braucht sie erneut.

Halte pro Arm eine bekannt gute exportierte Kalibrierung bereit und beschrifte die Arme physisch. Ein unbeschriftetes Regal identischer Arme ist der Grund, warum eine Klasse am Ende denselben Arm dreimal kalibriert.

Ein Team steckt fest und kann nicht sagen, warum

Die vier Fragen, die das meiste klären:

1. Zeigt die Verbindungstabelle sechs Motoren auf OK?
2. Folgt der 3D-Zwilling, wenn du ein Gelenk von Hand bewegst?
3. Wurde dieser Arm in diesem Konto kalibriert?
4. Ist der Not-Halt noch von vorhin verriegelt?

Die Klasse ist nicht im Gleichschritt

Erwartbar – und der Grund, warum die Plattform Modul für Modul freischaltet statt nach Kalender. Zwei Dinge helfen: Organisiere den Hardware-Schritt als Rotation, damit die schnellen Teams nicht untätig sind, und lass die schnellen Teams am virtuellen Arm vorarbeiten, statt Zusatzaufgaben zu erfinden.

Mit der Plattform selbst stimmt etwas nicht

Nutze Send feedback in Lab – es hängt einen Screenshot an. Nenne Modul und Schritt, Browser und Version, die Verbindungsart und ob es sich auf mehr als einem Rechner reproduzieren lässt. Dieses letzte Detail unterscheidet einen Plattformfehler von einem Rechner, der ein anderes Kabel braucht.