appRobotHoming
appRobotHoming ist die browserbasierte Bedienoberfläche für die WebCam-gestützte
Ermittlung der Roboterpose. Das Frontend bleibt der Einstieg; die eigentliche
Bildverarbeitung läuft hinter der Firewall auf eigenen Services (WebCam,
BodyTracker), die der Homing-Backend als schlanker Proxy anspricht.
Architektur im Überblick
Browser ──HTTPS──▶ Reverse-Proxy ──HTTPS/WSS──▶ appRobotHoming-Backend
(statisches UI) (öffentliches TLS) (server/server.js, Port 2093)
│
intern (hinter der Firewall, HTTP):
├──▶ WebCam-Service (Bilder)
├──▶ BodyTracker-Service (Pose)
└──▶ … weitere Schritte (später)
- Frontend (
public/) – statische Seite: zeigt Infos, Buttons und die Rückmeldungen (Result als JSON + Tree-View, Snapshot-Tabelle, Bilder). Kein direkter Zugriff auf die internen Services. - Backend (
server/server.js) – BFF-Proxy. Liefert das statische Frontend aus und stellt eine kleine API bereit, über die das UI an die internen Services kommt. Läuft auf HTTPS, Port 2093.
Ablauf
- Das UI lädt den aktuellen Stand über
GET /api/latest-snapshot. - Bilder und Kamera-Intrinsics kommen vom WebCam-Service (eigener Server hinter der Firewall; die Kamera ist Source of Truth ihrer eigenen Kalibrierung).
- Auf Knopfdruck schickt das UI eine Pose-Anfrage an
POST /api/estimate. - Der Backend reicht Bilder + Intrinsics zur Verarbeitung an den BodyTracker weiter und erhält die Roboterpose zurück.
- Das Ergebnis wird im UI ausgegeben (JSON, Tree, Tabelle, annotierte Bilder).
- Eventuell folgen weitere Schritte (z. B. Pose an
appRobotDrivergeben).
Fällt der BodyTracker aus, rechnet das Frontend ersatzweise lokal mit
public/calculateAngles.js.
HTTPS (bewusste Entscheidung)
Der Backend läuft selbst auf HTTPS – auch wenn davor schon ein Reverse-Proxy die öffentliche TLS-Terminierung übernimmt. Grund: WebSocket-Verbindungen (WSS) kommen nur sauber durch den Proxy, wenn auch der Backend-Hop TLS spricht.
- Das verwendete Zertifikat ist self-signed (
https/, Passphraseabcd). Das ist Absicht: Dieser Hop ist nur Proxy ↔ Backend, nie öffentlich. Die vertrauenswürdige Kette stellt der vorgelagerte Reverse-Proxy bereit. - Zugriff im internen Netz z. B. über
https://thinkcentre.local:2093/.
API (Backend)
| Endpoint | Methode | Zweck |
|---|---|---|
/api/health |
GET | Status + konfigurierte Service-URLs |
/api/latest-snapshot |
GET | Aktuelle Bilder/Daten (vom WebCam-Service bzw. lokalem Fallback) |
/api/estimate |
POST | Bilder an BodyTracker geben → Pose zurück |
Konfiguration (Umgebungsvariablen)
| Variable | Bedeutung |
|---|---|
HTTPS_PORT |
Port des Backends (Default 2093) |
WEBCAM_URL |
Basis-URL des internen WebCam-Services |
BODYTRACKER_URL |
Basis-URL des internen BodyTracker-Services |
HTTPS_KEY_PATH / HTTPS_CERT_PATH / HTTPS_PASSPHRASE |
self-signed Cert für den Proxy-Hop |
Ist WEBCAM_URL nicht gesetzt, nutzt der Backend lokale Dateien aus
public/snapshots als Fallback (Entwicklung ohne Kamera).
Dateien & Struktur
public/– statisches Frontend (UI, Client-Logik, Anzeige).server/server.js– HTTPS-Backend / BFF-Proxy.https/– self-signed Zertifikate für den Proxy-Hop (nicht eingecheckt).doc/README_WebCam.md– WebCam-Service (Bildquelle).doc/README_BodyTracker.md– BodyTracker-Service (Pose-Ermittlung).doc/ToDo.md– offene Punkte & nächste Umsetzungsschritte.test/– Tests für Berechnung und Auswertung.
Nutzung
npm install
npm test
npm start # startet den HTTPS-Backend auf Port 2093
Danach im internen Netz https://<host>:2093/ öffnen (self-signed → einmalige
Zertifikatswarnung im Browser bestätigen).
Hinweis: Das Frontend ist auf den Backend angewiesen –
/api/latest-snapshotund/api/estimatefunktionieren nicht, wenn manindex.htmlrein statisch öffnet. Immer übernpm start(bzw. den Container) laufen lassen.
Geplante Erweiterungen
- Pose an
appRobotDriverweitergeben. - Wenn die Hand nicht erkannt wird: Vorschlag für eine bessere Arm-/Foto-Position.
- Manuelle Eingabe von
x, y, z, a, b, c, e. - Erkennungsergebnis und Pose klarer im UI ausgeben.
Konkrete nächste Schritte und offene Schnittstellen-Fragen: siehe
doc/ToDo.md.