Latencia en la comunicación

Uno de los problemas que primero se observaron durante el desarrollo fue la latencia de llegada de los cuadros de video. Existe una demora entre que un comando es enviado a la cámara y hasta que los cuadros del giro son entregados a los algoritmos de proyección y sustracción de fondo. Esta demora no resulta de gran importancia para el análisis en tiempo real mientras la cámara se mantiene fija, pero representa un obstáculo en el modelado del fondo antes, durante, y después de cada rotación.

En verdad hay dos demoras presentes a la hora de rotar la cámara, primero la tardanza del comando en alcanzarla y luego la de la imagen en llegar a la aplicación. Para comprender mejor los problemas ocasionados por estas latencias es mejor recordar primero el camino que recorren los mensajes:

1. El usuario presiona el botón de confirmar un giro a ciertas coordenadas, o bien la aplicación decide automáticamente la rotación.

2. Se envía un mensaje a través de la red con destino a la cámara IP indicando el comando de rotación correspondiente.

3. La cámara recibe el comando, envía un mensaje de ACK (acknowledgement)

a la aplicación y luego efectúa el giro.

4. La aplicación recibe el ACK, tomando conocimiento de que la cámara ejecutó

la orden.

El problema que surge es que no es claro cuándo actualizar las coordenadas de la región observada en el modelo de visión. Téngase en cuenta que la aplicación está

53

continuamente recibiendo el stream de video desde la cámara, por lo que podría estar procesando imágenes del giro en ejecución – o incluso ya finalizado – antes de recibir el ACK. El modelo debe estar alertado del giro o de otra forma introducirá cuadros en la región incorrecta, pero la aplicación no puede tener confirmación del mismo hasta la llegada del ACK. Además, existen pérdidas de mensajes: tanto el comando de movimiento como el ACK podrían nunca llegar a destino. La potencial pérdida del comando de movimiento evita cualquier actualización segura del modelo a priori, mientras que la posible pérdida del ACK evita que se pueda definir una cota superior de tiempo para la actualización – cualquier actualización retardada en un intervalo aceptable tiene siempre el riesgo de ser prematura.

El problema no es solo que el ACK sea asincrónico, sino también que las variaciones impredecibles en la latencia (jitter) – derivadas de factores como la congestión de la red y de reenvíos por corrupción de mensajes – dificultan la coordinación. El hecho de que las variaciones suelan manifestarse como ráfagas irregulares termina de descartar la posibilidad de hacer estimaciones confiables basadas en tiempos de latencia anteriores y en la demora del giro mecánico de la cámara.

Otro problema, quizás más importante, es que – incluso aunque pudiese conocerse exactamente el tiempo de latencia – la demora del envío de los mensajes, sumada a los tiempos de deserialización y decodificación de los cuadros de video, acaban produciendo un retraso temporal lo suficientemente significativo como para impedir el seguimiento mecánico continuo de un objeto en tiempo real mediante comandos de giro de la cámara a coordenadas absolutas.

4.1.1. Tratamiento en el Software Implementado

Si se abandona la funcionalidad del seguimiento en tiempo real, una solución simple para continuar con el procesamiento tras la rotación de la cámara es introducir una demora constante entre el envío del comando y la actualización de las coordenadas actuales dentro del modelo. Recordando que la latencia es variable, esta solución no será perfecta, y requerirá definir un tiempo de demora lo suficientemente alto como para incluir no solo a la latencia media, sino también a la mayoría de los casos más largos.

La solución implementada en el proyecto utiliza una demora constante con un tiempo de 4 segundos. Este valor fue ajustado empíricamente a las condiciones de la red de desarrollo para evitar la proyección errónea de virtualmente ningún cuadro. Durante este

54

plazo de tiempo el procesamiento del video es detenido completamente y, antes de reanudarlo, las coordenadas del modelo son actualizadas.

4.1.2. Soluciones Alternativas

En la solución implementada existe el riesgo de que el comando de rotación se haya perdido y el modelo se esté actualizando de manera incorrecta por tiempo indefinido. Aunque este es un evento inusual, puede resultar importante si la cámara gira de manera infrecuente – dando pocas posibilidades de recuperarse en un tiempo aceptable. Como trabajo futuro la solución mediante introducción de demora podría abandonarse, y los ángulos de visión de la cámara estimarse completamente en base al contenido de la imagen. Vale la pena mencionar este enfoque por su capacidad de generalización, y porque además serviría también de solución al pequeño error de precisión de posicionamiento del hardware, pero al mismo tiempo este tipo de soluciones podría involucrar algoritmos complejos de feature matching como los mencionados al inicio del Capítulo 3, u otras técnicas de visión computacional costosas.

Una alternativa intermedia es utilizar el protocolo VISCA para indicar la dirección y la velocidad de movimiento en vez de utilizar coordenadas absolutas, y realizar una búsqueda de la imagen grabada en un modelo del fondo que haya sido creado y validado previamente, realizando las comparaciones con métricas como el error cuadrado medio o similares. Esto requiere igualmente de una capacidad de procesamiento considerablemente mayor, porque cada imagen debe proyectarse múltiples veces para mantener la estimación de las coordenadas actualizadas y conservar el error dentro de un intervalo aceptable. Un balance de las ventajas y desventajas debería llevarse a cabo para cada caso de aplicación en específico.

4.1.3. Impacto de la Configuración de la Cámara

Finalmente, se observó que los tiempos de latencia están vinculados a la calidad del video enviado por la cámara. Mayores resoluciones, frame rates y bit rates se corresponden con una latencia mayor y con niveles de variación en la duración de la demora más susceptibles a la congestión en la red y a otros factores. Para lograr un tiempo de demora total e irregularidad aceptables, se configuró la cámara para enviar video con una resolución de 720x480 píxeles, un frame rate máximo de 15 cuadros por segundo y bit rate constante de 1 megabit.

55