ETSIIT Technische Uitdaging | Van studenten tot ondernemers

Dit bericht 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 zijn we begonnen met ons werk voor de IV ETSIIT Technical Challenge (video). Wie zijn we? Nou, we zijn vier studenten die Elektrotechniek en Computerwetenschappen studeren aan de Universiteit van Granada in Spanje.

Ons team, Prometheus, heeft de Tech Challenge gewonnen, gesponsord door RTI. Voor deze uitdaging moesten teams van vier of vijf studenten een product maken om een ​​door een extern bedrijf voorgestelde uitdaging op te lossen. Het thema voor de uitdaging van dit jaar was "Multi-Agent Video Distributed System."

We deden mee aan deze uitdaging voor praktische ervaring. Een jaar na de Tech Challenge zijn we allemaal nog steeds studenten, maar we hebben nu een zakelijke kans onderzocht, het concurrerende product Locaviewer ontworpen, een strategie ontwikkeld om het op de markt te verkopen en een werkend prototype gemaakt naast het cursuswerk dat nodig is voor onze diploma's.

Locaviewer

De meeste ouders met kinderen op een kleuterschool maken zich zorgen over de gezondheid en vooruitgang van hun kinderen. Ons product, Locaviewer, probeert ouders in staat te stellen hun kind in realtime te volgen en te zien. Als onderdeel van ons marketingplan hebben we een promotievideo gemaakt. Onze code is vrijgegeven onder MIT-licentie op GitHub.

Teamorganisatie en planning

Het kostte ons ongeveer 250 uur om het project te voltooien. Elke week kwamen we minstens 4 uur bij elkaar, met uitzondering van de laatste maand waar we 20 uur per week aan het project besteedden. Om efficiënter te zijn, verdeelden we ons in twee teams. Twee mensen werkten aan het indoor Bluetooth-locatiealgoritme. De andere twee waren gericht op een applicatie om een ​​videostream vast te leggen, te coderen/decoderen en te delen met RTI Connext DDS.

Locatie-algoritme

De eerste en belangrijkste stap van onze oplossing was om de locatie van de kinderen in de kleuterschool te bepalen. Elk kind moest een polsbandje dragen met een Bluetooth-apparaat -sensor-, die voortdurend het signaalvermogen meldde, ontving een Bluetooth-apparaat -dongle-, dat in de muren van de kamer was geplaatst. Deze Received Signal Strength Indication (RSSI) waarde wordt meestal gemeten in decibel (dB). We hebben de relatie tussen RSSI en afstand bepaald.

De RSSI-waarden zijn verzonden naar een minicomputer (Raspberry Pi of MK802 III) om een ​​triangulatie-algoritme uit te voeren en de locatie van het kind te identificeren. Omdat we de camerapositie kenden, wisten we na het bepalen van de positie van het kind welke camera's het kind aan het opnemen waren en selecteerden we de beste camera.

Video-opnametoepassing

Voor het opnemen, coderen, decoderen en visualiseren van video hebben we GStreamer voor Java gebruikt. We hebben andere bibliotheken geprobeerd, zoals vlcj, maar ze ondersteunden Raspberry Pi niet of voldeden niet aan de realtime-beperkingen van ons systeem. Na wat onderzoek ontdekten we GStreamer die werkte met Raspberry Pi en die gemakkelijk de gecodeerde videobuffer in realtime kon krijgen (met behulp van AppSink en AppSource elementen). Hierdoor konden we het inkapselen en naar een DDS-onderwerp sturen. We hebben hier enkele maanden aan gewerkt, zelfs door een tijdelijke oplossing te implementeren met HTTP-streaming met behulp van vlcj totdat we onze definitieve aanpak hadden vastgesteld.

We gebruikten de VP8 (WebM) video-encoder. Omdat de wrapper voor Java alleen werkt met GStreamer versie 0.10, konden we deze niet optimaliseren en moesten we de videodimensies verkleinen. Onze tests gebruikten Raspberry Pi, maar we zijn van plan om een ​​MK802 III-apparaat te gebruiken in de uiteindelijke implementatie omdat het dezelfde prijs heeft maar meer verwerkingskracht. De uiteindelijke coderingsconfiguratie was:

We hebben de volgende Java-code gebruikt om VP8-encoderelementen te maken.

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 clientzijde hebben we de volgende configuratie gebruikt:

We hebben de volgende Java-code gebruikt om VP8-decoderelementen te maken.

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 wachtrij =ElementFactory.make("queue2", null)Element codec =ElementFactory.make("vp8dec", null);Element convert =ElementFactory. make("ffmpegcolorspace", null); 

We hebben ook JPEG-codering geprobeerd, maar dit was niet haalbaar voor realtime gebruik vanwege de grotere omvang en het grotere aantal pakketten.

DDS-architectuur

De publiceer-abonneer-aanpak was de sleutel tot onze oplossing. Het stelde ons in staat om gegevens tussen veel klanten te delen zonder ons zorgen te hoeven maken over netwerkaansluitingen of verbindingen. We moesten alleen specificeren wat voor soort gegevens we moesten verzenden en ontvangen. We hebben een wrapper-bibliotheek gemaakt, DDStheus, om het DDS-gebruik in ons systeem te abstraheren.

Onze uiteindelijke oplossing bestond uit zes programma's die drie onderwerpen deelden. We gebruikten verschillende programmeertalen:

1. Python werkt op laag niveau (HCI) met Bluetooth-apparaten
2. MATLAB/Octave om het triangulatiescript te maken
3. Java gaat werken met RTI Connext DDS en grafische gebruikersinterfaces

We moesten alle RSSI-waarden in een ruimte weten. We hebben een script gemaakt om de Bluetooth-dongles te configureren en de RSSI-informatie te krijgen. Deze waarden werden naar een Java-programma gestuurd via een simpele socketverbinding in dezelfde machine. De Java-toepassing heeft de gegevens gepubliceerd in de Sensorgegevens onderwerp. Het stuurde Child ID (de sensor Bluetooth MAC), Bluetooth dongle ID en positie, huidige kamer (als een sleutel om op kamer te filteren), RSSI-waarde en vervaltijd.

Nadat de camera's de video hebben opgenomen en gecodeerd, stuurt het Java-programma Gava de video via de Video Data onderwerp. Het stuurde de camera-ID als sleutelwaarde om de stream te filteren met ContentFilteredTopic met camerapositie, kamer, gecodeerd frame en codec-info.

Bovendien plaatste de applicatie de camera-ID, kamer en camerapositie in de USER_DATA QoS-waarde van elke video-uitgever. De triangulatie-minicomputer zou dan alle camera-informatie in een kamer kunnen krijgen door alleen uitgevers te ontdekken. Het kan ook nieuwe en kapotte camera's in realtime detecteren en het locatiescript bijwerken om het cameraselectie-algoritme te verbeteren.

In de laatste stap hebben we de gegevens verwerkt en het resultaat geschreven als Child Data onderwerp. Dit werd gedaan door de roomserver (geïmplementeerd met Raspberry Pi of MK802 III) die de locatie van het kind t

[1] [2] 下一页