Tantangan Teknis ETSIIT: Dari Mahasiswa hingga Wirausaha dengan Locaviewer

Postingan ini ditulis oleh pemenang TechChallenge: Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García, dan Benito Palacios Sánchez.

Se tahun yang lalu, kami memulai IV ETSIIT Technical Challenge (video). Siapa kami? Kami adalah empat mahasiswa Teknik Elektro dan Ilmu Komputer di Universitas Granada, Spanyol.

Tim kami, Prometheus, meraih kemenangan dalam Tech Challenge yang disponsori RTI. Tim yang terdiri dari empat atau lima mahasiswa diberi tugas untuk menciptakan produk yang mengatasi masalah dunia nyata yang diajukan oleh partner eksternal. Tema tahun ini adalah “Sistem Video Terdistribusi Multi-Agen.”

Kami masuk ke tantangan untuk mendapatkan pengalaman langsung. Satu tahun kemudian, sementara masih kuliah, kami mengidentifikasi peluang komersial, merancang produk kompetitif Locaviewer, merumuskan strategi pasar, dan membangun prototipe yang berfungsi—semua itu di samping memenuhi persyaratan akademik kami.

Locaviewer

Banyak orang tua khawatir tentang kesehatan dan perkembangan anak mereka di taman kanak-kanak. Locaviewer memberikan orang tua visibilitas real-time terhadap anak mereka. Kami membuat video promosi untuk memamerkan solusi ini, dan kode sumber kami tersedia di bawah lisensi MIT di GitHub.

Organisasi Tim dan Jadwal

Proyek ini membutuhkan sekitar 250 jam. Kami bertemu setiap minggu minimal empat jam, meningkat hingga 20 jam per minggu selama bulan terakhir. Untuk memaksimalkan efisiensi, kami terpecah menjadi dua sub-tim: satu berfokus pada algoritma lokasi Bluetooth indoor, yang lain pada tangkapan video, encoding/decoding, dan distribusi melalui RTI Connext DDS.

Algoritma Lokasi

Pusat solusi kami adalah menempatkan setiap anak di dalam taman kanak-kanak. Setiap anak mengenakan gelang pergelangan tangan dengan sensor Bluetooth yang terus-menerus melaporkan Received Signal Strength Indication (RSSI) ke dongle stasioner yang dipasang di dinding ruangan. Kami memetakan nilai RSSI ke jarak, membangun hubungan yang andal.

Bacaan RSSI ditransmisikan ke mini-komputer (Raspberry Pi atau MK802 III) yang menjalankan algoritma triangulasi untuk menentukan lokasi setiap anak. Dengan mengetahui posisi kamera, kami dapat memilih kamera optimal untuk setiap anak.

Aplikasi Perekaman Video

Kami menggunakan GStreamer untuk Java untuk menangani tangkapan video real-time, encoding, decoding, dan tampilan. Alternatif seperti vlcj tidak mendukung Raspberry Pi atau memenuhi persyaratan latensi kami. Setelah penelitian yang menyeluruh, GStreamer terbukti cocok, memungkinkan kami mengakses buffer video yang dienkripsi melalui elemen AppSink dan AppSource dan menerbitkannya ke topik DDS.

Kami memilih encoder VP8 (WebM). Karena wrapper Java kompatibel dengan GStreamer 0.10, kami harus mengurangi resolusi untuk memenuhi keterbatasan platform. Konfigurasi uji kami menggunakan Raspberry Pi, dengan rencana untuk bermigrasi ke MK802 III untuk daya pemrosesan yang lebih tinggi sambil mempertahankan paritas biaya.

Cuplikan Java berikut membuat encoder VP8:

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"));

Di sisi klien, kami mengonfigurasi pipeline sebagai berikut:

Kode Java untuk decoder VP8:

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);

Kami bereksperimen dengan encoding JPEG, tetapi ukuran paket yang lebih besar membuat streaming real-time tidak praktis.

Arsitektur DDS

Model publish-subscribe adalah pusat dari solusi kami, yang menghilangkan keuntungan untuk mengelola koneksi socket secara manual. Kami abstraksi interaksi DDS melalui perpustakaan wrapper kami sendiri, DDStheus.

Sistem akhir kami terdiri dari enam program yang berbagi tiga topik, diimplementasikan dalam tiga bahasa:

1. Python untuk penanganan Bluetooth tingkat rendah.
2. MATLAB/Octave untuk skrip triangulasi.
3. Java untuk integrasi RTI Connext DDS dan pengembangan GUI.

Kami membutuhkan semua nilai RSSI dari ruangan, jadi kami menulis skrip untuk mengonfigurasi dongle dan mengumpulkan data RSSI. Nilai ini diteruskan ke program Java melalui soket lokal. Aplikasi Java menerbitkan data ke topik Data Sensor, termasuk ID anak (sensor MAC), ID dongle, posisi, ruangan saat ini (sebagai kunci untuk filtering), nilai RSSI, dan waktu kedaluwarsa.

Setelah tangkapan dan encoding video, program Java Gava mentransmisikan stream melalui topik Data Video, melabeli setiap paket dengan ID kamera dan informasi ruangan. Kami memanfaatkan ContentFilteredTopic untuk memfilter stream berdasarkan posisi kamera dan ruangan.

Metadata kamera—ID, ruangan, dan posisi—disimpan di bidang QoS USER_DATA dari setiap penerbit. Mini-komputer triangulasi dapat menemukan semua kamera di ruangan, mendeteksi kamera baru atau offline secara real-time, dan menyesuaikan algoritma pemilihan kamera sesuai kebutuhan.

Langkah terakhir melibatkan agregasi data sensor dan video ke topik Data Anak. Server ruangan—diimplementasikan pada Raspberry Pi atau MK802 III—melakukan triangulasi lokasi anak dan memilih kamera terbaik. Ini memfilter sensor berdasarkan ruangan, mengambil informasi kamera, menjalankan skrip Octave untuk menghitung posisi anak dan kamera optimal, dan menerbitkan hasilnya ke cloud. ID anak dan kualitas video digunakan sebagai kunci filter untuk langganan yang efisien.

Untuk mengoptimalkan penggunaan sumber daya, server ruangan hanya menjalankan skrip triangulasi ketika pelanggan meminta data untuk anak tertentu, yang ditentukan melalui penemuan pelanggan dan filter ContentFilteredTopic.

Kami juga mengimplementasikan mekanisme toleransi kesalahan: setiap mini-komputer menerbitkan ID prioritas di USER_DATA. Node dengan ID terendah menjadi server aktif sampai node baru dengan ID yang lebih rendah bergabung.

[1] [2]  >

Merancang Sistem Manufaktur Adaptif untuk Industry 4.0: Memanfaatkan IIoT dan RTI Connext 2014: Tahun Penting untuk RTI dalam Inovasi IoT Industri