ETSIIT Technische Uitdaging: Van Student tot Ondernemer met Locaviewer

Deze post is geschreven door de winnaars van de TechChallenge: Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García, en Benito Palacios Sánchez.

Een jaar geleden begonnen we aan de IV ETSIIT Technische Uitdaging (video). Wie zijn we? We zijn vier Elektrotechniek en Informatica studenten aan de Universiteit van Granada, Spanje.

Ons team, Prometheus, behaalde de overwinning in de RTI-gesponsorde Tech Challenge. Teams van vier of vijf studenten moesten een product creëren dat een real-world probleem adresserde voorgelegd door een externe partner. Dit jaar was het thema "Multi-Agent Video Distributed System."

We gingen de uitdaging aan om praktijkervaring op te doen. Een jaar later, nog steeds staande, identificeerden we een commerciële kans, ontwierpen het competitieve product Locaviewer, bedachten een marktstrategie, en bouwden een werkend prototype – allemaal naast onze academische verplichtingen.

Locaviewer

Veel ouders maken zich zorgen over de gezondheid en vooruitgang van hun kinderen in kannen. Locaviewer geeft ouders real-time zichtbaarheid van hun kind. We produceerden een promotionele video om de oplossing te tonen, en onze broncode is beschikbaar onder de MIT-licentie op GitHub.

Teamorganisatie en Planning

Het project vereiste ongeveer 250 uur. We vergaderden wekelijks voor minimaal vier uur, opschalend tot 20 uur per week in de laatste maand. Om efficiëntie te maximaliseren, splisten we in twee subteams: één gericht op het indoor Bluetooth-locatiealgoritme, de ander op videocapturing, encoding/decoding en distributie via RTI Connext DDS.

Locatiealgoritme

De hoeksteen van onze oplossing was het lokaliseren van elk kind binnen de kann. Elk kind droeg een polsband met een Bluetooth-sensor die continu Received Signal Strength Indication (RSSI) rapporteerde aan stationaire dongels gemonteerd op de kamermuren. We kaartten RSSI-waarden af naar afstand, wat een betrouwbare relatie tot stand bracht.

RSSI-metingen werden doorgestuurd naar een mini-computer (Raspberry Pi of MK802 III) die een triangulatie-algoritme draaide om de locatie van elk kind te bepalen. Wetende de cameraposities, konden we de optimale camera voor elk kind selecteren.

Video-opname Applicatie

We gebruikten GStreamer voor Java om real-time videocapturing, encoding, decoding en weergave te hanteren. Alternatieven als vlcj bleken geen ondersteuning voor Raspberry Pi te bieden of voldeden niet aan onze latentie-eisen. Na uitgebreid onderzoek bleek GStreamer geschikt, wat ons toegang gaf tot gecodeerde videobuffers via AppSink en AppSource elementen en deze publiceerde op een DDS-topic.

We selecteerden de VP8 (WebM) encoder. Vanwege de Java-wrapper's compatibiliteit met GStreamer 0.10, moesten we de resolutie verlagen om aan de platformbeperkingen te voldoen. Onze testconfiguratie gebruikte een Raspberry Pi, met plannen om te migreren naar een MK802 III voor hogere verwerkingskracht tegen gelijke kosten.

De volgende Java-code creëert de 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"));

Aan de clientkant configureerden we de pipeline als volgt:

De Java-code voor de 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);

We experimenteerden met JPEG-encoding, maar de grotere pakketgrootte maakte real-time streaming onpraktisch.

DDS Architectuur

Het publish-subscribe model was centraal in onze oplossing, wat de noodzaak elimineerde om socket-verbindingen handmatig te beheren. We abstraheerden DDS-interacties door onze eigen wrapper-bibliotheek, DDStheus.

Ons finalesysteem bestond uit zes programma's die drie topics deelden, geïmplementeerd in drie talen:

1. Python voor low-level Bluetooth-handling.
2. MATLAB/Octave voor triangulatie-scripts.
3. Java voor RTI Connext DDS integratie en GUI-ontwikkeling.

We hadden alle RSSI-waarden uit de kamer nodig, dus schreven we een script om de dongels te configureren en RSSI-data te verzamelen. Deze waarden werden doorgestuurd naar een Java-programma via een lokale socket. De Java-applicatie publiceerde de data naar het Sensor Data topic, inclusief kind-ID (sensor MAC), dongel-ID, positie, huidige kamer (als sleutel voor filteren), RSSI-waarde en vervaltijd.

Na videocapturing en encoding, stuurde het Java-programma Gava de stream via het Video Data topic, waarbij elk pakket getagd was met camera-ID en kamerafgegevens. We benutten ContentFilteredTopic om streams te filteren op camerapositie en kamer.

Camerametadata – ID, kamer en positie – werd opgeslagen in het USER_DATA QoS-veld van elke publisher. De triangulatie-minicomputer kon alle camera's in een kamer ontdekken, nieuwe of offline camera's in real-time detecteren, en het camera-selectiealgoritme dienovereenkomstig aanpassen.

De laatste stap betrof het aggregeren van sensor- en videodata in het Child Data topic. Een kamerserver – geïmplementeerd op Raspberry Pi of MK802 III – trianguleerde de kindlocatie en selecteerde de beste camera. Het filterde sensoren op kamer, haalde camerainfo op, draaide het Octave-script om de kindpositie en optimale camera te berekenen, en publiceerde het resultaat naar de cloud. Kind-ID en videokwaliteit werden als filtersleutels gebruikt voor efficiënte abonnementen.

Om resourcegebruik te optimaliseren, voerde de kamerserver het triangulatie-script alleen uit wanneer een abonnee data aanvroeg voor een specifiek kind, bepaald via subscriber discovery en ContentFilteredTopic filters.

We implementeerden ook een fouttolerantiemechanisme: elke minicomputer publiceerde een prioriteits-ID in USER_DATA. De knoop met de laagste ID werd de actieve server totdat een nieuwe knoop met een nog lagere ID deelde.

[1] [2]  >