Quickstart¶

Zehn Minuten von „nichts" zu „der Roboter fährt". Alles hier ist an einem echten Gerät gemessen, nicht aus einer Herstellerbeschreibung übernommen.

Fahrbefehle bewegen einen echten Roboter

Jeder Aufruf in Abschnitt 4 setzt ein Fahrzeug in Bewegung. Löse ihn nur aus, wenn jemand beim Roboter steht und der Weg frei ist. Das ist keine Formalie — das Fahrgestell nimmt den Befehl an, ohne zu fragen.

1. Was wo liegt¶

Drei Ebenen, drei Adressen:

Ebene	Adresse	Wer spricht damit
Fahrgestell	`http://<ip>:8090`	der uGo-Server, sonst niemand
uGo-Server (unser)	`http://<ip>:5173/api/**`	die Bedienoberfläche, Partner, Werkzeuge
uSuite (Cloud)	MQTT über TLS	der uGo-Server

Programmiere gegen den uGo-Server, nicht gegen das Fahrgestell. Das Fahrgestell hat keine Anmeldung, keine CORS-Kopfzeilen, uneinheitliche Einheiten und einen Schrägstrich am Ende, dessen Regel der Erwartung zuwiderläuft. Der uGo-Server nimmt dir all das ab und ist die Fläche, die wir stabil halten.

2. Anmelden¶

Zwei Rollen: techniker darf alles, bediener sieht Fahrtenbuch und Anzeigen. Lesende Aufrufe brauchen meist keine Anmeldung, jeder schreibende Aufruf verlangt die Rolle techniker.

curl -c keks.txt -X POST http://<ip>:5173/api/anmeldung \
     -H 'Content-Type: application/json' \
     -d '{"kennwort":"<das Kennwort des Kunden>"}'
# → {"rolle":"techniker"}

Der Keks ist httpOnly und sameSite=strict. Er läuft nach zehn Minuten ohne Zugriff ab und verlängert sich bei jedem Aufruf.

Note

Ist am Gerät gar kein Kennwort eingerichtet, stehen die geschützten Seiten offen und GET /api/anmeldung sagt das mit {"kennwortEingerichtet":false}. Das ist ein Prüfaufbau, kein Auslieferungszustand.

3. Zustand lesen¶

curl -b keks.txt http://<ip>:5173/api/chassis/chassis/status
curl -b keks.txt http://<ip>:5173/api/chassis/battery-state
curl -b keks.txt http://<ip>:5173/api/chassis/maps/

Für laufende Änderungen gibt es einen Ereignisstrom statt Abfragen im Takt:

curl -N -b keks.txt http://<ip>:5173/api/funk

4. Ein Ziel anfahren¶

curl -b keks.txt -X POST http://<ip>:5173/api/chassis/chassis/moves \
     -H 'Content-Type: application/json' \
     -d '{"creator":"quickstart","type":"standard",
          "target_x":1.5,"target_y":-2.0,"target_ori":1.5708}'

Grad oder Bogenmass — die häufigste Fehlerquelle

Das Fahrgestell rechnet uneinheitlich. target_ori beim Fahrbefehl und ori beim Setzen der Lage nehmen Bogenmass. /tracked_pose meldet dagegen Grad. Gemessen am 19.08.2026: 1.5708 gesendet, 90 gelesen.

Wer das verwechselt, bekommt keinen Fehler, sondern eine falsche Fahrt. Im uGo-Code liegt die Umrechnung deshalb an genau zwei Stellen. Führe keine dritte ein.

5. Die vier Dinge, die uns Tage gekostet haben¶

Der Schrägstrich am Ende ist Teil der Adresse. Listen verlangen ihn (/maps/), Einzelabrufe vertragen ihn nicht (/mappings/16/ → 404, /mappings/16 → 200). Bei POST gibt es keine Rettung durch eine Umleitung: Django wirft RuntimeError … APPEND_SLASH.

Langsam ist nicht kaputt. Vier Aufrufe laufen regelmässig über fünf Sekunden und kommen dann fälschlich als 504 zurück: GET /mappings/, GET /maps/, POST /chassis/pose, POST /chassis/current-map. Der uGo-Server gibt diesen vieren 45 Sekunden.

Eine Zeichnung wirkt erst nach „Karte neu laden". Wer Zonen oder eine Ladestation nach dem Aktivieren der Karte schreibt, muss die Karte erneut laden, sonst kennt das Fahrgestell sie nicht. Gemessen: derselbe Ladepunkt scheitert vorher und trägt nachher.

Die Ladestation ist ein Paar, nie ein einzelner Punkt. Station und Andockpunkt 0,899 m davor, gegenläufiger Winkel, wechselseitig verknüpft. Fehlt der Partner, meldet das Gerät failed to find charger with pos(...).

6. Weiter¶

:octicons-arrow-right-24: Fahrgestell — alle Endpunkte, Zonen, Punktarten, WebSocket · :octicons-arrow-right-24: uGo-Server — alle Routen und das Anmeldemodell · :octicons-arrow-right-24: Cloud — MQTT, Themenbaum, Ausrollen