Desafio técnico ETSIIT | De estudantes universitários a empresários

Esta postagem foi escrita por os vencedores do TechChallenge:Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García e Benito Palacios Sánchez.

Há um ano, iniciamos nosso trabalho para o IV Desafio Técnico ETSIIT (vídeo). Quem somos nós? Bem, somos quatro alunos que estudam Engenharia Elétrica e Ciência da Computação na Universidade de Granada, na Espanha.

Nossa equipe, Prometheus, venceu o Tech Challenge patrocinado pela RTI. Para este desafio, equipes de quatro ou cinco alunos tiveram que criar um produto para resolver um desafio proposto por uma empresa externa. O tema do desafio deste ano foi "Sistema Distribuído de Vídeo Multi-Agente".

Nós nos juntamos a este desafio pela experiência prática. Um ano após o Tech Challenge, ainda somos todos estudantes, mas agora pesquisamos uma oportunidade de negócio, projetamos o produto competitivo Locaviewer, desenvolvemos uma estratégia para vendê-lo no mercado e criamos um protótipo funcional além do trabalho do curso exigido para nossos graus.

Locaviewer

A maioria dos pais com filhos em uma creche se preocupa com a saúde e o progresso de seus filhos. Nosso produto, Locaviewer, tenta fornecer aos pais para rastrear e ver seus filhos em tempo real. Como parte do nosso plano de marketing, criamos um vídeo promocional. Nosso código foi lançado sob a licença do MIT no GitHub.

Organização e cronograma da equipe

O projeto levou aproximadamente 250 horas para ser concluído. A cada semana nos reuníamos por pelo menos 4 horas, com exceção do último mês em que passamos 20 horas / semana no projeto. Para ser mais eficiente, nos dividimos em duas equipes. Duas pessoas trabalharam no algoritmo de localização do Bluetooth interno. Os outros dois focaram em um aplicativo para capturar, codificar / decodificar um stream de vídeo e compartilhá-lo usando o RTI Connext DDS.

Algoritmo de localização

A primeira e mais importante etapa de nossa solução foi determinar a localização das crianças dentro da creche. Cada criança precisava usar uma pulseira com um dispositivo Bluetooth -sensor-, que continuamente relatava a potência do sinal recebido por um dispositivo Bluetooth -dongle-, colocado nas paredes da sala. Este valor de indicação de intensidade do sinal recebido (RSSI) é geralmente medido em decibéis (dB). Determinamos a relação entre RSSI e distância.

Os valores RSSI foram transmitidos a um minicomputador (Raspberry Pi ou MK802 III) para executar um algoritmo de triangulação e identificar a localização da criança. Como sabíamos a posição da câmera, após determinarmos a posição da criança, sabíamos quais câmeras estavam gravando a criança e selecionamos a melhor.

Aplicativo de gravação de vídeo

Para gravar, codificar, decodificar e visualizar o vídeo usamos o GStreamer para Java. Tentamos outras bibliotecas, como vlcj, mas elas não eram compatíveis com Raspberry Pi nem atendiam às restrições de tempo real de nosso sistema. Depois de alguma pesquisa, descobrimos GStreamer que funcionava com Raspberry Pi e poderia facilmente obter o buffer de vídeo codificado em tempo real (usando AppSink e AppSource elementos). Isso nos permitiu encapsulá-lo e enviá-lo para um tópico DDS. Trabalhamos nisso por vários meses, implementando uma solução temporária com streaming de HTTP usando vlcj até definirmos nossa abordagem final.

Usamos o codificador de vídeo VP8 (WebM). Como o wrapper para Java só funciona com o GStreamer versão 0.10, não foi possível otimizá-lo e tivemos que reduzir as dimensões do vídeo. Nossos testes usaram Raspberry Pi, mas planejamos usar um dispositivo MK802 III na implementação final porque tem o mesmo preço, mas mais poder de processamento. A configuração de codificação final foi:

Usamos o seguinte código Java para criar elementos do codificador VP8.

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

No lado do cliente, usamos a seguinte configuração:

Usamos o seguinte código Java para criar elementos do decodificador VP8.

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

Também tentamos a codificação JPEG, mas isso não era viável para uso em tempo real devido ao tamanho maior e ao maior número de pacotes.

Arquitetura DDS

A abordagem publicar-assinar foi a chave para nossa solução. Isso nos permitiu compartilhar dados entre muitos clientes sem nos preocupar com soquetes de rede ou conexões. Precisávamos apenas especificar que tipo de dados enviar e receber. Criamos uma biblioteca wrapper, DDStheus, para abstrair o uso de DDS em nosso sistema.

Nossa solução final foi composta por seis programas que compartilhavam três tópicos. Usamos diferentes linguagens de programação:

1. Python para funcionar em baixo nível (HCI) com dispositivos Bluetooth
2. MATLAB / Octave para fazer o script de triangulação
3. Java para trabalhar com RTI Connext DDS e interfaces gráficas de usuário

Precisávamos saber todos os valores RSSI em uma sala. Criamos um script para configurar os dongles Bluetooth e obter as informações RSSI. Esses valores foram enviados para um programa Java usando uma conexão de soquete simples na mesma máquina. O aplicativo Java publicou os dados no Sensor Data tópico. Enviou ID de criança (o sensor Bluetooth MAC), ID e posição do dongle Bluetooth, sala atual (como uma chave para filtrar por sala), valor RSSI e tempo de expiração.

Depois que as câmeras gravaram e codificaram o vídeo, o programa Java Gava envia o vídeo por meio dos Dados de vídeo tópico. Ele enviou o ID da câmera como um valor-chave para filtrar o fluxo usando ContentFilteredTopic com a posição da câmera, sala, quadro codificado e informações do codec.

Além disso, o aplicativo coloca o ID da câmera, a sala e a posição da câmera no valor de QoS USER_DATA de cada editor de vídeo. O minicomputador de triangulação poderia então obter todas as informações da câmera em uma sala apenas descobrindo os editores. Ele também pode detectar câmeras novas e quebradas em tempo real e atualizar o script de localização para melhorar o algoritmo de seleção de câmeras.

Na última etapa, processamos os dados e escrevemos o resultado como Dados filho tópico. Isso foi feito pelo servidor da sala (implementado com Raspberry Pi ou MK802 III) que triangulou a localização da criança e selecionou a câmera apropriada. Ele filtrou apenas os sensores na sala atual e reuniu todas as informações do editor de vídeo naquela sala. Os dados foram enviados para um script Octave, que retornou a localização da criança e a melhor identificação da câmera. A informação enviada para a nuvem com o tópico Dados Filhos , ID da criança incluída, qualidade de vídeo, ID da câmera, localização da criança e ID da sala. Par

[1] [2] 下一页