ETSIIT Technical Challenge: Vom Studenten zum Unternehmer mit Locaviewer

Dieser Beitrag wurde von den Gewinnern der TechChallenge verfasst: Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García und Benito Palacios Sánchez.

Vor einem Jahr starteten wir bei der IV. ETSIIT Technical Challenge (Video). Wer sind wir? Wir sind vier Studenten der Elektrotechnik und Informatik an der Universität Granada, Spanien.

Unser Team Prometheus gewann die RTI-gesponserte Tech Challenge. Teams von vier bis fünf Studenten sollten ein Produkt entwickeln, das ein reales Problem eines externen Partners löst. Diesjähriges Thema: „Multi-Agent Video Distributed System“.

Wir traten an, um praktische Erfahrung zu sammeln. Ein Jahr später, noch während des Studiums, erkannten wir eine kommerzielle Chance, entwarfen das wettbewerbsfähige Produkt Locaviewer, entwickelten eine Markstrategie und bauten einen funktionsfähigen Prototyp – alles neben unseren akademischen Pflichten.

Locaviewer

Viele Eltern sorgen sich um Gesundheit und Fortschritt ihrer Kinder in Kitas. Locaviewer gibt Eltern Echtzeit-Einblick in ihr Kind. Wir produzierten ein Promo-Video und stellen unseren Quellcode unter MIT-Lizenz auf GitHub bereit.

Teamorganisation & Zeitplan

Das Projekt erforderte ca. 250 Stunden. Wir trafen uns wöchentlich für mindestens vier Stunden, in der Endphase bis zu 20 Stunden pro Woche. Zur Effizienzsteigerung teilten wir uns in zwei Sub-Teams: eines fokussierte auf den Indoor-Bluetooth-Lokalisierungsalgorithmus, das andere auf Video-Capture, Encoding/Decoding und Distribution via RTI Connext DDS.

Lokalisierungsalgorithmus

Kern unserer Lösung war die Ortung jedes Kindes in der Kita. Jedes Kind trug ein Armband mit Bluetooth-Sensor, der kontinuierlich RSSI (Received Signal Strength Indication) an stationäre Dongles an den Wänden sendete. Wir mappten RSSI-Werte auf Distanzen und stellten eine zuverlässige Beziehung her.

RSSI-Werte wurden an einen Mini-Computer (Raspberry Pi oder MK802 III) mit Triangulationsalgorithmus gesendet, um jedes Kind zu orten. Durch bekannte Kamerapositionen konnte die optimale Kamera pro Kind ausgewählt werden.

Video-Aufzeichnungsanwendung

Wir nutzten GStreamer für Java für Echtzeit-Video-Capture, Encoding, Decoding und Display. Alternativen wie vlcj unterstützten Raspberry Pi nicht oder erfüllten unsere Latenzanforderungen nicht. Nach intensiver Recherche erwies sich GStreamer als geeignet, da es Zugriff auf encodierte Videobuffer via AppSink und AppSource ermöglicht und diese auf ein DDS-Topic publiziert.

Wir wählten den VP8 (WebM) Encoder. Aufgrund der Java-Wrapper-Kompatibilität mit GStreamer 0.10 mussten wir die Auflösung reduzieren. Unsere Testkonfiguration nutzte einen Raspberry Pi, mit Plan zur Migration auf MK802 III für mehr Rechenleistung bei gleichem Kosten.

Folgender Java-Snippet erstellt den VP8-Encoder:

Element codec = ElementFactory.make("vp8enc", null); codec.set("threads", 5); codec.set("max-keyframe-distance", 20); codec.set("speed", 5); Element capsDst = ElementFactory.make("capsfilter", null); capsDst.setCaps(Caps.fromString("video/x-vp8 profile=(string)2"));

Client-seitig konfigurierten wir die Pipeline so:

Java-Code für VP8-Decoder:

String caps = "video/x-vp8, width=(int)320, height=(int)240, framerate=15/1"; Element capsSrc = ElementFactory.make("capsfilter", null); capsSrc.setCaps(Caps.fromString(caps)); Element queue = ElementFactory.make("queue2", null); Element codec = ElementFactory.make("vp8dec", null); Element convert = ElementFactory.make("ffmpegcolorspace", null);

Wir experimentierten mit JPEG-Encoding, aber dessen größere Paketgröße machte Echtzeit-Streaming unpraktikabel.

DDS-Architektur

Das Publish-Subscribe-Modell war zentral für unsere Lösung und eliminierte manuelles Socket-Management. Wir abstrahierten DDS-Interaktionen durch unsere eigene Wrapper-Bibliothek DDStheus.

Unser finales System bestand aus sechs Programmen, die drei Topics teilten, implementiert in drei Sprachen:

1. Python für Low-Level Bluetooth-Handling.
2. MATLAB/Octave für Triangulations-Skripte.
3. Java für RTI Connext DDS Integration und GUI-Entwicklung.

Wir benötigten alle RSSI-Werte des Raums, daher schrieben wir ein Skript zur Dongle-Konfiguration und Datensammlung. Diese Werte wurden via lokalem Socket an ein Java-Programm weitergeleitet. Die Java-Applikation publizierte die Daten auf dem Sensor Data Topic, inkl. Kinder-ID (Sensor MAC), Dongle-ID, Position, aktuellem Raum (als Filter-Key), RSSI-Wert und Ablaufzeit.

Nach Video-Capture und Encoding übertrug das Java-Programm Gava den Stream via Video Data Topic, getaggt mit Kamera-ID und Raum-Info. Wir nutzten ContentFilteredTopic, um Streams nach Kameraposition und Raum zu filtern.

Kamera-Metadaten – ID, Raum, Position – wurden im USER_DATA QoS-Feld jedes Publishers gespeichert. Der Triangulations-Mini-Computer konnte alle Kameras eines Raums entdecken, neue/offline Kameras in Echtzeit erkennen und den Kamera-Selektionsalgorithmus entsprechend anpassen.

Der finale Schritt aggregierte Sensor- und Videodaten in das Child Data Topic. Ein Room Server – auf Raspberry Pi oder MK802 III – triangulierte Kinderposition und wählte die beste Kamera. Er filterte Sensoren nach Raum, holte Kamerainfos, führte das Octave-Skript zur Positionsberechnung aus und publizierte das Ergebnis in die Cloud. Kinder-ID und Videoqualität dienten als Filter-Keys für effiziente Subscription.

Zur Ressourcenoptimierung führte der Room Server das Triangulationsskript nur aus, wenn ein Subscriber Daten für ein bestimmtes Kind anforderte, ermittelt via Subscriber Discovery und ContentFilteredTopic-Filter.

Wir implementierten auch Fehlertoleranz: Jeder Mini-Computer publizierte eine Prioritäts-ID in USER_DATA. Der Knoten mit der niedrigsten ID wurde aktiver Server, bis ein neuer Knoten mit noch niedrigerer ID beitrat.

[1] [2]  >

Adaptive Fertigungssysteme für Industrie 4.0 designen: IIoT & RTI Connext nutzen 2014: Ein Meilensteinjahr für RTI in der Industrial-IoT-Innovation