88 lines
2.7 KiB
Markdown
88 lines
2.7 KiB
Markdown
## Roadmap - Optionale Punkte ##
|
||
|
||
---
|
||
|
||
## Control integrieren
|
||
|
||
Das aktuelle `appRobotVideoControls` koppelt zwei unabhängige Verantwortlichkeiten:
|
||
|
||
1. **Video-Streaming** (USB-Kameras → Browser)
|
||
2. **Robot-Control** (Browser → G-Code → Robot-Server)
|
||
|
||
### Warum wir trennen
|
||
|
||
| Problem | Auswirkung |
|
||
|---------|------------|
|
||
| Control-Code-Änderung → Video-Server-Restart | Stream unterbricht, Operator verliert Bild |
|
||
| Grosser Docker-Container | OpenCV + Python + FFmpeg + Control-Libs |
|
||
| Schwer testbar | Video-Stream nicht einfach simulierbar |
|
||
| Latenz-Konflikte | Video-Tuning ≠ Control-Anforderungen |
|
||
| Robot-Server offline | Video-Server wirft Fehler |
|
||
|
||
### Vorteil der Kopplung
|
||
|
||
Ein Browser-Tab für alles: Video + Steuerung zusammen – sehr bequem für den Operator.
|
||
|
||
---
|
||
|
||
### Optionen für Control
|
||
|
||
**Option A: Getrennt bleiben (empfohlen für Phase 1–2)**
|
||
|
||
```
|
||
appRobotWebcam → Port 8444 (nur Video + Snapshots)
|
||
appRobotControl → Port 8445 (nur G-Code, Gamepad, Keyboard → Robot)
|
||
```
|
||
|
||
- Browser öffnet beide als Tabs oder iframe-Dashboard
|
||
- Nachteil: Zwei Services deployen und warten
|
||
|
||
**Option B: Control als optionales Modul in appRobotWebcam**
|
||
|
||
- Env var `ENABLE_CONTROL=true/false` schaltet Control-Code ein/aus
|
||
- Control-Code ist in der Codebase, aber inaktiv wenn nicht konfiguriert
|
||
- Nachteil: Code-Komplexität steigt, trotzdem ein Container
|
||
|
||
**Option C: Vollintegration wie bisher**
|
||
|
||
- Alles in einem Container – wie `appRobotVideoControls`
|
||
- Einfachste UX, einfachstes Deployment
|
||
- Nachteil: Monolith, schwer zu warten und zu testen
|
||
|
||
### Empfehlung
|
||
|
||
Für Phase 1–2: **Option A** – sauber trennen.
|
||
Wenn UX zum Problem wird (Operator-Feedback): **Option B** evaluieren.
|
||
Option C nur wenn Deployment-Einfachheit absolut dominiert.
|
||
|
||
---
|
||
|
||
## Homing-Projekt Anbindung
|
||
|
||
Das Homing-Projekt braucht Standbilder der Kameras für ArUco-Erkennung.
|
||
|
||
**Schnittstelle**: `GET /api/snapshot/cam{n}` → JPEG-Bild
|
||
|
||
`appRobotWebcam` liefert genau das. Keine weitere Kopplung nötig.
|
||
Das Homing-Projekt ist Consumer, `appRobotWebcam` ist Producer.
|
||
|
||
```
|
||
Homing-Projekt
|
||
└── HTTP GET http://approbotwebcam:8080/api/snapshot/cam0
|
||
└── HTTP GET http://approbotwebcam:8080/api/snapshot/cam1
|
||
↓
|
||
ArUco-Erkennung → Kamera-Pose → Weltkoordinaten
|
||
```
|
||
|
||
---
|
||
|
||
## Dashboard / UI Konsolidierung
|
||
|
||
Wenn mehrere Services (Video, Control, Homing-Status) parallel laufen:
|
||
|
||
- **Option**: Leichtes Dashboard als eigene statische Seite (nginx) mit iframes
|
||
- **Option**: Portainer-UI zeigt alle Container-Status
|
||
- **Option**: Control-Panel in `appRobotWebcam` einbetten (Option B oben)
|
||
|
||
Dies ist bewusst aufgeschoben – erst wenn klar ist welche Services produktiv laufen.
|