Dentro del estimador: cómo se combinan el GNSS, la IMU y los sensores

A estas alturas, las mediciones están en buen estado. La sincronización temporal ha proporcionado una base temporal común para todos los datos. El preprocesamiento ha depurado los flujos de datos sin procesar. El motor de navegación ha modelado los valores que debería registrar cada sensor, y la fijación RTK ha permitido reducir la precisión de las mediciones GNSS hasta el nivel centimétrico.

En el centro de todo ello se encuentra el estimador. Es la parte del sistema que toma mediciones independientes, a veces apenas relacionadas entre sí, pero que aportan información sobre el estado del mundo, y las convierte en una única respuesta.

Esta entrada trata sobre lo que ocurre realmente dentro del «estimador».

El vector de estado: lo que el estimador realmente estima

El estado del filtro, o vector de estado, es el conjunto de valores que el estimador intenta determinar. La posición, la velocidad y la orientación son los más evidentes. Sin embargo, el estado suele incluir también magnitudes menos evidentes: correcciones para sensores que presentan errores subyacentes y otros valores que el sistema solo estima como subproductos, ya que los necesita para alcanzar una posición correcta.

Algunas mediciones te proporcionan información directa sobre algún elemento de ese vector de estado. Una medición de la posición es el caso más sencillo: simplemente te indica una posición. Otras mediciones son indirectas. La velocidad de las ruedas te indica a qué velocidad te estás moviendo, no dónde te encuentras. La distancia a un satélite te da información sobre la posición, pero solo en combinación con muchas otras distancias.

La función del estimador es tomar todos estos datos, tanto directos como indirectos, y procesarlos para obtener una actualización de aquello que realmente te interesa. No lo consigue de un solo golpe. Va aprendiendo el estado con el paso del tiempo, refinándolo con cada medición que recibe.

Ponderación: confianza frente a error esperado

Lo más importante que hace el estimador es ponderar cada medición.

Toda medición tiene un cierto margen de variación, un error previsible. El estimador compara ese margen con el grado de confianza que ya tiene en su estimación actual. ¿Qué grado de certeza tengo sobre mi posición en este momento? ¿Y sobre mi orientación? Una medición que presenta ruido o que solo guarda una relación indirecta con el estado tiene menos peso que una que sea precisa y fiable.

Ese equilibrio va cambiando con el tiempo. Cuando enciendes un dispositivo por primera vez, el estimador no sabe prácticamente nada. La posición, la orientación, los errores de los sensores: todo es incierto. En ese estado, incluso una medición con ruido resulta valiosa, porque cualquier cosa es mejor que nada, y el sistema se basa en los datos que recibe para aprender.

Una vez que el sistema lleva un tiempo funcionando y tiene clara su posición, la relación se invierte. Supongamos que tienes una fijación RTK y conoces muy bien tu posición, y de repente llega una medición GNSS defectuosa, alterada por un edificio o alguna otra fuente de error. El estimador puede comparar esa medición —y el error que normalmente debería conllevar— con lo que ya considera cierto. Si la medición se aleja mucho del error esperado, el estimador puede restarle peso o rechazarla directamente. (Enla parte 3 se trata este manejo de valores atípicos con más detalle).

Sensores complementarios: lo mejor de ambos mundos

Descartar una medición GNSS errónea no significa quedarse a ciegas. Los demás sensores siguen aportando datos.

Esta es la ventaja de la fusión multisensor: los sensores son complementarios. Las velocidades de las ruedas no saben nada del edificio alto que hay al final de la manzana, y tampoco les importa. Las mediciones del GNSS pueden verse afectadas por ese edificio, pero cuando no es así, pueden ser excelentes. La IMU (unidad de medición inercial) funciona rápidamente, más rápido que las actualizaciones del GNSS, y completa el movimiento entre ambas. Los datos de velocidad de las ruedas pueden llegar a una frecuencia menor, a veces incluso con menos frecuencia que el GNSS. Con el tiempo, todos se complementan entre sí. Al combinarlos, cada uno compensa la debilidad del otro: la precisión absoluta del GNSS cuando funciona correctamente y una percepción estable del movimiento cuando no es así.

Dos familias: INS frente a GNSS únicamente

Antes de que el estimador pueda predecir cómo cambia el estado entre mediciones, tiene que saber en qué tipo de sistema se está ejecutando. Aquí hay una línea divisoria muy clara, y todo se reduce a un solo sensor.

Un sistema de navegación inercial (INS) cuenta con una IMU. Un sistema que solo utiliza GNSS no la tiene. Esa distinción es más importante que casi cualquier otro aspecto del motor.

Una IMU mide con gran precisión las aceleraciones y las velocidades de rotación. Si se integran estas magnitudes a lo largo del tiempo, se obtiene una imagen directa de cómo varían la posición y la velocidad. La IMU indica cómo evoluciona el estado a medida que se mueve la plataforma, a diferencia de las mediciones absolutas —como el GNSS o la visión artificial—, que proporcionan información sobre el mundo exterior al dispositivo. La calidad de la IMU, que depende del coste, el consumo energético y otros factores, determina el nivel de precisión que se puede alcanzar.

Si quitas la IMU, te encuentras en una situación mucho más complicada. Imagínate que vas conduciendo por una autopista y entras en un túnel. Antes de llegar al túnel, el GNSS funcionaba bien y todo iba bien. Una vez dentro, el GNSS deja de funcionar. Con una IMU (o con las velocidades de las ruedas u otros sensores de movimiento relativo), puedes seguir calculando la posición por estimación durante ese tramo. Sin nada, quizá puedas hacer conjeturas durante un par de segundos, pero después de eso simplemente te equivocarás.

Cuando no se dispone de esos sensores de movimiento relativo, lo mejor que se puede hacer es basarse en cómo se mueve normalmente este tipo de vehículo. Tenemos una idea bastante clara de cómo se comportan los coches: por lo general, no suben, no bajan, no se balancean mucho de lado a lado y, desde luego, no vuelcan. Un barco o un avión son otra historia. Esas suposiciones, en las que un INS se basa mucho menos porque la IMU mide el movimiento directamente, son las únicas en las que puede apoyarse un sistema que solo utiliza GNSS. (Para conocer la dinámica de cada plataforma —coches, aviones y motocicletas—, véase la parte 3).

Esta distinción entre el uso del INS y el uso exclusivo del GNSS constituye la base del enfoque del Atlas INS: combinar un motor de posicionamiento eficaz con sensores inerciales para que el sistema siga generando una posición válida cuando no haya visibilidad del cielo.

Pseudomedidas: cómo generar información que nunca has medido

Este es uno de los trucos más interesantes de los que dispone el estimador. Los académicos suelen denominarlos «pseudomedidas»: se trata de aplicar lo que se sabe sobre un vehículo para limitar lo que el sistema puede hacer y lo que, sencillamente, no tiene sentido.

La detección de la inmovilidad es el ejemplo más claro. Supongamos que la IMU indica que no estás girando —ya que la velocidad de giro es precisamente lo que mide— y que tampoco estás acelerando. En sentido estricto, la ausencia de aceleración significa que tu velocidad no varía, no que sea cero. Sin embargo, los vehículos reales casi nunca mantienen una velocidad perfectamente constante, por lo que, en la práctica, cuando la IMU no indica aceleración ni giro, es muy probable que estés parado.

En la práctica, no leemos los valores brutos de rotación y aceleración para compararlos con cero. De todos modos, la aceleración nunca es realmente cero, ya que la gravedad siempre está presente, repartida entre los ejes, a menos que el dispositivo se encuentre perfectamente nivelado. En su lugar, observamos cómo varían esas señales y cuán ruidosas son a lo largo de un intervalo de tiempo. Un vehículo que está realmente parado produce una firma distintiva y constante, y interpretarla de esa manera nos permite detectar la parada al tiempo que ignoramos los sesgos propios del sensor.

Una vez que sabemos que el vehículo está parado, el truco da sus frutos. Un coche parado no gira ni se inclina, por lo que podemos afirmar que la velocidad de rotación real es cero y que la velocidad real es cero; introducimos esos valores como una pseudomedida y medimos en qué medida los sensores se desvían de ellos. Esa diferencia es el error del sensor, al descubierto. A partir de ahí, elaboramos correcciones para los sensores —afirmaciones del tipo «este sensor concreto tiene un desvío de tal magnitud, de tal manera»— y las aplicamos al modelo dinámico y a las mediciones entrantes, de modo que la solución en su conjunto se vuelve más precisa con el tiempo.

Esas correcciones no son estáticas. Evolucionan. La temperatura y otros factores ambientales las modifican, por lo que el sistema las va reaprendiendo sobre la marcha. Pero una vez que se les coge el truco, se puede sacar una precisión real de unas mediciones que, en teoría, no deberían ser tan buenas.

Módulo frente a host: dónde se ejecuta el estimador

Todo esto suena a pura matemática, y lo es, pero las matemáticas no son gratis. Propagar el estimador hacia adelante y ejecutar el modelo dinámico requiere un esfuerzo computacional real.

En primer lugar, los dos entornos en los que puede ejecutarse el cálculo. Cuando el posicionamiento se ejecuta en un módulo, el estimador se aloja en un dispositivo pequeño e independiente, con su propio procesador y su propio presupuesto energético, una placa dedicada a realizar una única tarea. Cuando se ejecuta en un host, el estimador se ejecuta en el ordenador principal, de mayor tamaño, que ya se encuentra a bordo del vehículo o del robot, utilizando la misma clase de procesador que se encarga de la percepción, la planificación y el resto de la aplicación. Un módulo es compacto, eficiente en el consumo de energía y fácil de integrar en un diseño. Un host dispone de mucha más capacidad de cálculo y memoria de reserva. Esa diferencia en el margen de capacidad es el tema central del resto de esta sección.

Hay un antecedente que merece la pena destacar: gran parte de lo que hacemos hoy en día con los estimadores surgió de la necesidad de que este tipo de cálculos resultaran lo suficientemente económicos como para poder realizarlos en ordenadores pequeños, una tradición que se remonta al ordenador de navegación del Apolo. Así que, en cierto sentido, este campo siempre se ha centrado en adaptar la estimación a un hardware con limitaciones. Pero todo es relativo.

En un dispositivo con menos capacidad, como por ejemplo el procesador integrado en un módulo, es posible que simplemente te quedes sin margen de maniobra. Si le estás enviando datos de una IMU con una frecuencia muy alta, o si estás ejecutando cálculos o algoritmos especialmente exigentes, es posible que físicamente no puedas seguir el ritmo. Y las consecuencias no se limitan a que «funcione más lento». Imagina un coche de carreras con una dinámica intensa y muchas vibraciones, en el que las mediciones de alta frecuencia aportan precisamente los detalles que quieres capturar. Si el procesador no puede seguir el ritmo a esa frecuencia, es posible que te veas obligado a utilizar una frecuencia de medición más baja, y esa frecuencia más baja puede ocultar precisamente los aspectos que más importan. O quizá te veas obligado a limitar o desactivar funciones del motor de navegación en las que normalmente confías, lo que puede degradar el rendimiento.

Ese es solo un ejemplo entre muchos, pero ilustra bien la idea. Algunas de las técnicas necesarias para alcanzar el máximo nivel de precisión simplemente no se adaptan bien a determinados dispositivos, debido a todas las demás tareas que estos deben realizar al mismo tiempo. Esta es la diferencia práctica entre un motor capaz que se ejecuta en un módulo y uno más robusto que se ejecuta en un procesador principal con capacidad de sobra. Por eso, la respuesta correcta depende totalmente de la plataforma.

Preguntas que vale la pena plantearse

Si estás creando tu propia pila tecnológica o evaluando un motor de posicionamiento comercial:

• ¿Cómo pondera el estimador una medición en función de su propio nivel de confianza? ¿Qué ocurre con una estimación fiable cuando se recibe una única medición GNSS errónea?
• ¿El sistema aprende las correcciones de los sensores en tiempo real y sigue reaprendiéndolas a medida que cambian la temperatura y las condiciones?
• ¿Puede aprovechar pseudomediciones como la detección de vehículos estacionados, o simplemente utiliza los datos de los sensores tal y como son?
• ¿Cómo se comporta con una IMU en comparación con el uso exclusivo del GNSS? ¿Cuál es la solución alternativa cuando no hay visión del cielo?
• ¿Para qué hardware está diseñado el motor? ¿La ruta de alta velocidad que necesitas cabe realmente en tu procesador junto con todo lo demás que ejecuta?

¿Qué viene ahora?

El estimador ha cumplido su función. Genera un estado preciso del filtro varias o muchas veces por segundo. Sin embargo, siguen existiendo dos problemas. En primer lugar, para utilizar mediciones que llegan desordenadas, es posible que el motor se vea obligado a funcionar ligeramente por detrás del tiempo real, lo que significa que su última respuesta está un poco desactualizada. En segundo lugar, esa respuesta sigue siendo solo un conjunto de números dentro del motor; ningún otro componente del sistema puede utilizarla todavía.

En la próxima entrada abordaremos la última etapa del proceso: el propagador de salida que se actualiza en tiempo real, y los servicios de salida y transporte que convierten el estado del filtro en mensajes que tu pila puede consumir realmente.

Preguntas frecuentes

¿Qué hace realmente el estimador de un motor de posicionamiento?

Toma mediciones de sensores independientes, a veces apenas relacionadas entre sí, y las combina en un único estado de filtro. Su función principal consiste en ponderar cada medición en función de su error esperado y del grado de confianza que ya tiene el sistema, para luego actualizar el estado en consecuencia, en lugar de confiar ciegamente en un solo sensor.

¿Qué es un vector de estado?

El vector de estado es el conjunto de valores que el estimador está calculando. Incluye la posición, la velocidad y la orientación, además de magnitudes menos evidentes, como las correcciones para sensores con error subyacente y otros valores que el sistema estima como subproductos en el proceso de alcanzar una posición correcta.

¿Cuál es la diferencia entre un sistema INS y un sistema que utiliza únicamente GNSS?

Un sistema de navegación inercial (INS) incluye una unidad de medida inercial (IMU) que mide la aceleración y la rotación, lo que le permite realizar un seguimiento de cómo varían la posición y la velocidad entre puntos de referencia absolutos y mantener la navegación por estima durante interrupciones del servicio, como en los túneles. Un sistema que utiliza únicamente el GNSS carece de dicho sensor y debe basarse en suposiciones generales sobre el movimiento del vehículo una vez que se pierden las señales de los satélites.

¿Qué son las pseudomedidas en la fusión de sensores?

Las pseudomedidas son restricciones derivadas de la información que el sistema tiene sobre la plataforma. Por ejemplo, una vez que el motor detecta que un coche está parado, puede establecer que la velocidad de rotación y la velocidad reales son cero, introducir esos valores y medir en qué medida los sensores se desvían de ellos. Esa diferencia pone de manifiesto el error de los sensores, que el sistema puede corregir a continuación.

¿Importa si el motor de posicionamiento se ejecuta en un módulo o en un procesador principal?

Sí. Un módulo tiene una capacidad de cálculo y una potencia limitadas, y unas exigencias elevadas —como una IMU de muy alta frecuencia o algoritmos complejos— pueden obligar a reducir las frecuencias de medición o a desactivar algunas funciones. Un procesador principal dispone de mucho más margen, lo que permite aplicar técnicas que un módulo no puede soportar. La elección adecuada depende de la plataforma.

---

Esta es la quinta parte de nuestra serie sobre la arquitectura de los sistemas de posicionamiento. En la primera parte se trató la sincronización horaria. En la segunda parte se abordó el preprocesamiento y la estrategia de sensores. En la tercera parte se analizó el motor de navegación. En la cuarta parte se trató la determinación de la posición mediante RTK.

Prueba nuestra red RTK de forma gratuita. Precisión a nivel mundial a un precio asequible y sin complicaciones. Empieza tu prueba gratuita.