Desafio Técnico ETSIIT: De Estudantes a Empreendedores com Locaviewer

Este post foi escrito pelos vencedores do TechChallenge: Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García e Benito Palacios Sánchez.

Há um ano, embarcamos no IV Desafio Técnico ETSIIT (vídeo). Quem somos? Somos quatro estudantes de Engenharia Elétrica e Ciência da Computação na Universidade de Granada, Espanha.

Nossa equipe, Prometheus, venceu o Tech Challenge patrocinado pela RTI. Equipes de quatro ou cinco estudantes tinham a tarefa de criar um produto que resolvesse um problema real proposto por um parceiro externo. O tema deste ano foi "Sistema Distribuído de Vídeo Multi-Agente".

Entramos no desafio para ganhar experiência prática. Um ano depois, ainda estudando, identificamos uma oportunidade comercial, projetamos o produto competitivo Locaviewer, elaboramos uma estratégia de mercado e construímos um protótipo funcional — tudo isso além de cumprir nossos requisitos acadêmicos.

Locaviewer

Muitos pais se preocupam com a saúde e o progresso dos filhos em creches. O Locaviewer dá aos pais visibilidade em tempo real de seus filhos. Produzimos um vídeo promocional para apresentar a solução, e nosso código-fonte está disponível sob licença MIT no GitHub.

Organização e Cronograma da Equipe

O projeto demandou cerca de 250 horas. Nos encontrávamos semanalmente por no mínimo quatro horas, escalando para 20 horas por semana no mês final. Para maximizar eficiência, dividimos em dois sub-times: um focado no algoritmo de localização indoor via Bluetooth, o outro em captura, codificação/decodificação e distribuição de vídeo via RTI Connext DDS.

Algoritmo de Localização

A pedra angular da nossa solução era localizar cada criança dentro da creche. Cada criança usava uma pulseira com sensor Bluetooth que reportava continuamente a Indicação de Intensidade de Sinal Recebido (RSSI) para dongles fixos nas paredes. Mapeamos valores RSSI para distância, estabelecendo uma relação confiável.

Leituras de RSSI eram transmitidas para um mini-computador (Raspberry Pi ou MK802 III) rodando um algoritmo de triangulação para pinpoint a localização de cada criança. Conhecendo as posições das câmeras, podíamos selecionar a câmera ideal para cada criança.

Aplicação de Gravação de Vídeo

Usamos GStreamer para Java para lidar com captura, codificação, decodificação e exibição de vídeo em tempo real. Alternativas como vlcj não suportavam Raspberry Pi ou não atendiam nossos requisitos de latência. Após extensa pesquisa, o GStreamer provou ser adequado, permitindo acessar buffers de vídeo codificados via elementos AppSink e AppSource e publicá-los em um tópico DDS.

Selecionamos o codificador VP8 (WebM). Devido à compatibilidade do wrapper Java com GStreamer 0.10, tivemos que reduzir a resolução para adequar às restrições da plataforma. Nossa configuração de teste usou Raspberry Pi, com planos de migrar para MK802 III para maior poder de processamento mantendo paridade de custo.

O snippet Java abaixo cria o codificador 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"));

No lado do cliente, configuramos o pipeline da seguinte forma:

O código Java para o decodificador 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);

Experimentamos codificação JPEG, mas seu tamanho de pacote maior tornou streaming em tempo real impraticável.

Arquitetura DDS

O modelo publish-subscribe foi central para nossa solução, eliminando a necessidade de gerenciar conexões de socket manualmente. Abstraímos interações DDS através de nossa própria biblioteca wrapper, DDStheus.

Nosso sistema final compreendia seis programas compartilhando três tópicos, implementados em três linguagens:

1. Python para manipulação de Bluetooth de baixo nível.
2. MATLAB/Octave para scripts de triangulação.
3. Java para integração RTI Connext DDS e desenvolvimento de GUI.

Precisávamos de todos os valores RSSI da sala, então escrevemos um script para configurar os dongles e coletar dados RSSI. Esses valores eram encaminhados para um programa Java via socket local. A aplicação Java publicava os dados no tópico Sensor Data, incluindo ID da criança (MAC do sensor), ID do dongle, posição, sala atual (como chave para filtragem), valor RSSI e tempo de expiração.

Após captura e codificação de vídeo, o programa Java Gava transmitia o stream via tópico Video Data, marcando cada pacote com ID da câmera e informação da sala. Aproveitamos ContentFilteredTopic para filtrar streams por posição da câmera e sala.

Metadados da câmera — ID, sala e posição — eram armazenados no campo USER_DATA QoS de cada publisher. O mini-computador de triangulação podia descobrir todas as câmeras em uma sala, detectar câmeras novas ou offline em tempo real e ajustar o algoritmo de seleção de câmera conforme necessário.

A etapa final envolvia agregar dados de sensor e vídeo no tópico Child Data. Um servidor de sala — implementado em Raspberry Pi ou MK802 III — triangulava a localização da criança e selecionava a melhor câmera. Ele filtrava sensores por sala, buscava informações das câmeras, executava o script Octave para calcular a posição da criança e a câmera ideal, e publicava o resultado na nuvem. ID da criança e qualidade de vídeo eram usados como chaves de filtro para assinatura eficiente.

Para otimizar uso de recursos, o servidor de sala só executava o script de triangulação quando um assinante solicitava dados para uma criança específica, determinado via descoberta de assinantes e filtros ContentFilteredTopic.

Também implementamos um mecanismo de tolerância a falhas: cada mini-computador publicava um ID de prioridade no USER_DATA. O nó com menor ID tornava-se o servidor ativo até que um novo nó com ID ainda menor entrasse.

[1] [2]  >

Projetando Sistemas de Manufatura Adaptativos para a Indústria 4.0: Aproveitando IIoT e RTI Connext 2014: Ano Marco para RTI em Inovação de IIoT Industrial