⚡ electrical engineering

A Distributed Stereo Visual Feedback Framework for VR- based Telesurgical Robotic Teleoperation: Design and Latency Characterization

Este artigo apresenta e caracteriza uma estrutura de feedback visual estéreo distribuído para teleoperação de telecirurgia baseada em RV, revelando que, embora o atraso de transmissão de rede seja mínimo, a maior parte da latência total do sistema (aproximadamente 78 ms) decorre das etapas de processamento de imagem e renderização de exibição.

Autores originais: Haniyeh Altafi, Rayan Shakeel, Kourosh Zareinia

Publicado 2026-08-13

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Haniyeh Altafi, Rayan Shakeel, Kourosh Zareinia

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando jogar um videogame onde controla um braço robótico em uma sala do outro lado do mundo. Você move sua mão e o robô se move, mas você só consegue ver o que o robô vê através de uma tela. Se a imagem na tela estiver até mesmo um pouquinho atrasada, seu cérebro fica confuso. É como tentar pegar uma bola usando óculos que mostram onde a bola estava um segundo atrás, não onde ela está agora. Este é o grande problema na "teleoperação", que é apenas uma palavra sofisticada para controlar um robô de longe.

Para fazer isso funcionar bem, especialmente para tarefas delicadas como cirurgias, você precisa de duas coisas: uma imagem 3D clara (para julgar a profundidade, como a distância de uma agulha) e velocidade (para que a imagem seja atualizada instantaneamente). Os cientistas chamam isso de "feedback visual estéreo" e "baixa latência". Se o atraso for muito longo, o operador se sente desajeitado, o robô pode bater ou, em um ambiente médico, um erro pode acontecer. A grande questão que os pesquisadores fazem é: "Para onde vai o tempo?" É a conexão de internet atrasando as coisas ou o computador levando muito tempo para processar a imagem?

Este artigo mergulha nesse mistério construindo uma "máquina do tempo" especial para a visão robótica. Os pesquisadores criaram um sistema onde um robô de um lado da sala envia um feed de vídeo 3D para uma pessoa usando um headset de Realidade Virtual (VR) do outro lado. Eles não apenas mediram o tempo total; eles dividiram a jornada em três etapas distintas, como cronometrar uma corrida de revezamento para ver qual corredor é o mais lento. Eles descobriram que, embora a conexão de internet fosse incrivelmente rápida — como um trem-bala — o processamento de vídeo pelo computador e o headset de VR mostrando-o eram os verdadeiros gargalos, agindo mais como um caracol lento.

Os Olhos 3D do Robô e o Headset de VR

Os pesquisadores configuraram um sistema que atua como um par de olhos remotos. No lado do "seguidor" (onde o rob em está), há uma câmera estéreo especial que tira duas fotos de uma vez, exatamente como os olhos humanos fazem, para criar um efeito 3D. Essas imagens são enviadas através de uma rede para o lado do "mestre", onde um operador humano está esperando. O humano usa um headset de VR Meta Quest 3, que é como uma janela de alta tecnologia que o faz sentir como se estivesse parado bem ao lado do robô.

A jornada do vídeo começa na câmera, viaja através de um computador intermediário (que atua como um escritório de correios triando correspondência), chega ao computador principal, é processado por um motor de jogo chamado Unity, e finalmente aparece dentro do headset de VR. A equipe queria saber exatamente quanto tempo cada etapa dessa jornada levou.

A Corrida de Revezamento do Tempo

Para descobrir onde o tempo estava se escondendo, a equipe dividiu a jornada do vídeo em três estágios, como uma corrida de revezamento com três corredores:

O Corredor da Rede: Este é o tempo que o vídeo leva para viajar pelos fios.
O Corredor do Unity: Este é o tempo que o computador leva para desempacotar o vídeo e deixá-lo pronto para o headset de VR.
O Corredor do VR: Este é o tempo que o headset leva para realmente mostrar a imagem aos seus olhos.

Eles mediram o Corredor da Rede primeiro. Eles enviaram 10.000 frames de vídeo e descobriram que era extremamente rápido. O tempo médio foi de apenas 5,59 ± 1,04 ms. Isso é incrivelmente rápido! Eles até testaram se o computador intermediário ("escritório de correios") estava atrasando as coisas, e ele adicionou menos de 1 milissegundo. Isso provou que a conexão de internet em si não era o problema; era a parte mais rápida de todo o sistema.

No entanto, quando olharam para o Corredor do Unity, a corrida desacelerou significamente. O computador levou uma média de 40,06 ± 10,12 ms apenas para processar o vídeo e deixá-lo pronto. Este foi o maior pedaço do atraso. O Corredor do VR final (o headset) levou outros 32,30 ± 0,09 ms para exibir a imagem.

Quando você soma todos os três corredores, o tempo total desde o momento em que a câmera vê algo até o momento em que o humano vê no headset de VR foi de 77,95 ± 10,17 ms.

A Grande Surpresa: Não é a Internet!

A descoberta mais importante deste artigo é um pouco de um reviravolta no enredo. Muitas pessoas assumem que, se você quiser um robô mais rápido, basta precisar de uma conexão de internet mais rápida. Mas este estudo mostrou que, mesmo com uma rede super-rápida (a parte dos 5,59 ms), o atraso total ainda era de quase 78 milissegundos. Por quê? Porque o processamento de vídeo pelo computador e o headset mostrando-o estavam consumindo a maior parte do tempo.

É como ter uma Ferrari (a internet) presa em um congestionamento causado por um pedágio lento (o processamento do computador) e um motorista lento (a renderização do headset). Não importa o quão rápido seja o carro, a viagem demora muito tempo por causa das paradas. Os pesquisadores descobriram que a rede era responsável apenas por uma fração minúscula do atraso. O verdadeiro "congestionamento" estava acontecendo dentro do software e do hardware de exibição.

Isso Realmente Funciona?

Para ver se este sistema era realmente útil, os pesquisadores pediram a quatro pessoas que jogassem um jogo. O jogo era uma tarefa de "pegar e colocar": usar o robô para mover pequenos blocos de um lugar para outro. Eles tentaram fazer isso com a visão 3D de VR e sem ela (usando uma tela 2D normal).

Os resultados foram promissores. Quando os participantes usaram o sistema de VR, terminaram a tarefa mais rápido (uma média de 373,7 segundos com VR vs. 527,2 segundos sem VR). Eles também moveram o robô em caminhos mais curtos e diretos e deixaram cair menos blocos. Todos os participantes disseram que a versão VR deu a eles uma melhor sensação de profundidade e pareceu mais conveniente.

No entanto, os autores são cuidadosos ao dizer que este foi apenas um teste "preliminar" com apenas quatro pessoas. Isso sugere que o sistema funciona bem, mas não é uma prova final de que funcionará para todos em todas as situações. Eles precisam testar com mais pessoas e em condições mais difíceis antes de declarar uma solução perfeita.

A Conclusão

Este artigo constrói uma base sólida para futuras cirurgias robóticas e trabalhos remotos. Ele prova que você pode enviar vídeo 3D de alta qualidade para um headset de VR com pouquíssimo atraso proveniente da internet. Mas também envia uma mensagem clara aos engenheiros: se você quer tornar esses sistemas mais rápidos, não compre apenas um cabo de internet mais rápido. Você precisa consertar o software que processa o vídeo e o hardware que o exibe. A internet está pronta; agora os computadores e os headsets precisam alcançar o nível.

Resumo Técnico: Uma Estrutura de Feedback Visual Estéreo Distribuído para Teleoperação Robótica Telesúrgica Baseada em VR

Definição do Problema

Na telecirurgia assistida por robôs e na teleoperação de alta precisão, a percepção de profundidade eficaz e a coordenação mão-olho dependem fortemente de um feedback visual estéreo de baixa latência. Embora as interfaces de Realidade Virtual (VR) ofereçam uma visualização imersiva que pode melhorar a consciência situacional, a latência total de ponta a ponta nesses sistemas é frequentemente um gargalo crítico. Pesquisas anteriores destacaram que atrasos visuais podem degradar o desempenho da tarefa, aumentar a carga de trabalho do operador e compromplicar a segurança. No entanto, muitos estudos existentes focam primariamente em atrasos de transmissão de rede ou interfaces de interação geral, falhando em caracterizar o pipeline completo de feedback visual "da câmera ao headset". Especificamente, há uma falta de decomposição detalhada das fontes de latência — distinguindo entre transmissão de rede, processamento de software (ex: renderização de motor de jogo) e renderização de exibição — o que é essencial para identificar os verdadeiros gargalos em sistemas de telecirurgia baseados em VR.

Metodologia

Os autores desenvolveram e avaliaram um pipeline de feedback visual estéreo distribuído projetado para teleoperação robótica baseada em VR. A arquitetura do sistema consiste em cinco componentes primários:

Câmera Estéreo: Um Módulo de Câmera VR Estéreo 3D GXIVISION que captura imagens sincronizadas lado a lado (2560 × 720 pixels) a 30 fps.
Computador do Lado do Remetente (Sender-Side): Executa Windows 11 com uma NVIDIA RTX 3060 Ti. Ele codifica o vídeo usando H.264 via GStreamer com aceleração de hardware (NVENC) e transmite o fluxo via UDP/RTP.
Computador de Rede Intermediário: Uma ponte baseada em Ubuntu usada para encaminhamento de pacotes UDP. Neste estudo, funções de impedimento (atraso, jitter, perda de pacotes) foram desativadas para estabelecer uma linha de base, embora a configuração permita simulações de rede futuras.
Computador do Lado do Mestre (Master-Side): Executa Windows 11 com uma NVIDIA RTX 4060 Ti. Ele decodifica o fluxo H.264 (usando NVDEC), processa a imagem lado a lado no Unity (separando as visões esquerda/direita via shaders customizados) e prepara o quadro para exibição.
Headset VR: Um Meta Quest 3 conectado via Meta Quest Link/OpenXR para exibir a visão estéreo imersiva.

Abordagem de Caracterização de Latência:
O estudo decompôs a latência total ( $L_{total}$ ) em três estágios distintos:

$L_{network}$ : Tempo de transmissão e decodificação (medido via rastreador de latência do GStreamer).
$L_{Unity}$ : Tempo de atualização de quadro e processamento dentro do motor Unity (medido via Time.realtimeSinceStartup).
$L_{VR}$ : Latência de renderização e exibição do Unity para o headset.

Os autores compararam múltiplas estratégias de implementação, incluindo uma abordagem de socket Python de linha de base versus um pipeline GStreamer otimizado, e codificação baseada em CPU versus codificação acelerada por GPU (NVENC/NVDEC). Adicionalmente, uma tarefa preliminar de "pegar e colocar" (pick-and-place) foi conduzida com quatro participantes para comparar a visualização estéreo baseada em VR contra uma condição sem VR, medindo o tempo de conclusão da tarefa, o comprimento do caminho e peças derrubadas.

Principais Contribuições

Implementação do Pipeline: A criação de um sistema de feedback visual estéreo distribuído que captura, transmite, processa e exibe vídeo estéreo sincronizado em um headset Meta Quest 3, especificamente adaptado para futuras aplicações de telecirurgia.
Decomposição de Latência: Um método de caracterização inovador que isola os atrasos de transmissão de rede, processamento Unity e renderização VR. Esta abordagem vai além das medições simples de computador-para-computador para identificar os estágios específicos que contribuem para o atraso de ponta a ponta.
Validação de Otimização: Demonstração de que a codificação/decodificação acelerada por hardware (GPU) e estruturas de mídia estruturadas (GStreamer) superam significativamente as implementações básicas de socket Python em termos de latência, jitter e estabilidade de quadros.
Linha de Base Empírica: Fornecimento de dados quantitativos de latência para uma configuração de teleoperação baseada em VR, estabelecendo uma referência para estudos futuros sobre percepção estéreo e desempenho do operador.

Resultados Experimentais

Transmissão de Rede: O pipeline otimizado do GStreamer alcançou uma latência de rede média de 5,59 ± 1,04 ms com 0,45 ms de jitter e zero perda de quadros sobre 10.000 quadros. O computador de ponte intermediário introduziu um atraso adicional desprezível (<1 ms) em comparação com uma conexão direta.
Impacto da Otimização: A mudança de uma linha de base de socket Python para o pipeline GStreamer reduziu a latência média em aproximadamente 44,7% (de 10,11 ms para 5,59 ms) e eliminou a perda de pacotes. Além disso, a codificação/decodificação acelerada por GPU reduziu a latência média do pipeline em 38,1% e melhorou significativamente a estabilidade do tempo de quadro (reduzindo o desvio padrão entre quadros de ~44 ms para ~8 ms) em comparação com o processamento baseado em CPU.
Latência de Ponta a Ponta: A latência total da câmera para a exibição foi medida em 77,95 ± 10,17 ms. A decomposição revelou que a transmissão de rede contribuiu apenas com uma pequena fração (~5,6 ms). As fontes dominantes de latência foram:
- Atualização de quadro do Unity: ~40,06 ms
- Renderização de exibição VR: ~32,30 ms
Avaliação de Tarefa Preliminar: Em uma tarefa de pegar e colocar com quatro participantes, a condição VR resultou em tempos de conclusão mais rápidos (média de 373,7 s vs. 527,2 s sem VR), caminhos cartesianos mais curtos e menos peças derrubadas (média de 1,25 vs. 4,00). Todos os participantes relataram subjetivamente uma melhor percepção de profundidade e preferiram a condição VR.

Significância e Alegações

O artigo alega que sua principal significância reside em demonstrar que a transmissão de rede não é a fonte dominante de latência em sistemas de teleoperação baseados em VR. Em vez disso, os estágios de visualização e exibição (processamento Unity e renderização VR) introduzem a maior parte do atraso.

Consequentemente, os autores argumentam que otimizar apenas os protocolos de rede é insuficiente para alcançar um feedback de telecirurgia de baixa latência. O design de sistemas futuros deve priorizar a otimização do pipeline de visualização, incluindo taxas de quadros da câmera, overhead de upload de textura em motores de jogo e caminhos de renderização VR.

O estudo posiciona seu pipeline proposto como uma base prática para pesquisas futuras em percepção estéreo, atraso visual e desempenho do operador em telecirurgia baseada em VR. Os autores declaram explicitamente que os resultados da tarefa preliminar são observações descritivas devido ao pequeno tamanho da amostra e que o sistema ainda não foi integrado com feedback háptico ou loops de controle robótico físico. O trabalho serve como um passo necessário para a caracterização do ciclo completo de feedback visual antes que estudos de teleoperação mais complexos e integrados possam ser conduzidos.