En resumen: la mayoría de los programas de localización no fallan por un problema técnico complejo. Se retrasan debido a una decisión de diseño inicial que parecía correcta en la ficha técnica, pero que falló en la práctica. Estos son los seis errores que vemos con más frecuencia: dejar la precisión para más adelante, copiar y pegar las especificaciones del receptor, especificar una clase de hardware incorrecta, subestimar la antena, elegir una IMU que no puede cubrir la distancia y dar por sentado que la red siempre está disponible, además de la prueba en el aparcamiento que los oculta todos.
En nuestra última entrada analizamos el modelo en V para el diseño de sistemas de localización en robótica. La parte izquierda del modelo en V es donde se define y se diseña; la parte derecha, donde se valida y se amplía a mayor escala; y el coste de corregir una decisión se multiplica aproximadamente por diez en cada etapa que se avanza hacia la derecha.
Esta entrada trata sobre las decisiones que salen mal en el lado izquierdo. La mayor parte de lo que hemos aprendido en ingeniería de campo se refiere a las fases de diseño y validación del diseño, porque es ahí donde se cometen los errores más costosos. Son esas decisiones comunes y aparentemente razonables que no resisten el contacto con el mundo real.
Error n.º 1: Dejar la precisión para más adelante
La mayoría de los equipos te dirán que ya saben qué nivel de precisión necesitan. El problema es que, por lo general, ese requisito no es lo suficientemente específico.
Se crea un sistema con una precisión de «aproximadamente un metro», pero resulta que la aplicación necesita límites mucho más ajustados. Pensemos en la cartografía con drones. Sin correcciones RTK, ya sea en tiempo real o en el posprocesamiento, se tiene un margen de incertidumbre de un metro. Eso puede parecer aceptable si nos imaginamos un desplazamiento constante de un metro en todo el mapa. Pero el error no se comporta así. No se trata de un desplazamiento uniforme que se pueda restar; varía a lo largo del mapa, y eso es precisamente lo que echa por tierra un trabajo de nivel topográfico.
La trampa más insidiosa es pensar: «No necesito ese nivel de precisión». A veces es cierto. Pero en el momento en que necesitas que el sistema funcione en cualquier lugar, el listón se eleva. Una mayor precisión es lo que te proporciona los límites más estrictos sobre los que desarrollar aplicaciones precisas y mantener su precisión a medida que te adentras en entornos más exigentes.
Establece el requisito de precisión en función de lo que la aplicación tenga que hacer, en las condiciones en las que tenga que hacerlo, antes de decidir cualquier otra cosa.
Error n.º 2: Copiar y pegar las especificaciones del receptor
Se trata de un error muy habitual, y es fácil entender por qué. Compras un receptor compatible con RTK, la ficha técnica indica «1 cm + 1 ppm» (un centímetro más una parte por millón multiplicada por la distancia de referencia) y lo incluyes en tus requisitos.
Esa cifra es real, en un mundo ideal. Un centímetro cuando estás justo encima de tu estación base, a cielo abierto, sin ningún tipo de interferencia. Pero la mayoría de las aplicaciones no funcionan así.
Los entornos reales presentan obstáculos, y es literalmente imposible diseñar un sistema en el que la señal del GNSS no sufra ninguna interferencia, ya que esta suele provenir del propio producto. Basta con que haya otro ordenador o subsistema cerca del receptor para que el rendimiento de este se vea mermado.
Un valor de ficha técnica medido en condiciones ideales es un valor máximo, no una especificación que vayas a encontrar en la práctica. Considéralo como el mejor caso posible y diseña teniendo en cuenta las condiciones en las que realmente vas a trabajar.
Error n.º 3: Elegir una clase de hardware inadecuada
No todos los receptores GNSS están diseñados para el mismo fin. Existen diferentes categorías de receptores, y ofrecen un rendimiento realmente distinto en función de para qué hayan sido diseñados.
Por ejemplo, los equipos de topografía utilizan receptores y antenas de gama muy alta y costosos, precisamente para garantizar la precisión y la fiabilidad. Sin embargo, un dispositivo portátil utiliza componentes de una categoría completamente diferente. Ninguna de las dos opciones es incorrecta; están diseñados para satisfacer requisitos distintos. El error consiste en recurrir a la categoría equivocada para tu aplicación y darte cuenta más tarde de que no ofrece la precisión necesaria.
Además, va más allá de la lista de componentes. Algunos receptores incorporan un sofisticado software de motor de posicionamiento y una profunda integración de la IMU que se adapta bien a entornos difíciles; otros no. Un entorno con fuerte efecto multitrayecto marcará rápidamente la diferencia entre ellos, y el «efecto multitrayecto» no es algo único: existen diferentes tipos de efecto multitrayecto. La dispersión de las señales entre la vegetación es un problema completamente distinto al de las señales que rebotan en los cristales del centro de San Francisco.
Define desde el principio la categoría que necesitas, basándote en la precisión y la fiabilidad que exige la aplicación, y no en lo que te resulte más familiar o más barato al principio.
Error n.º 4: Subestimar la importancia de la antena
Te sorprendería saber cuántas veces la antena es lo único que se interpone entre un sistema y una precisión de posicionamiento a nivel de centímetros.
Esto lo vemos constantemente en las demostraciones en directo. Llevamos al cliente un equipo de prueba sencillo —un receptor y una antena— y empezamos a mostrar la posición con una precisión de centímetros. Luego montamos la antena en el robot real y la señal de GPS desaparece, porque hay demasiadas interferencias de radiofrecuencia dentro de la plataforma procedentes del Bluetooth, la red móvil y todo lo demás que hay allí dentro. Si alejamos la antena del robot, la precisión de centímetros vuelve inmediatamente.
Las decisiones importantes sobre la antena: el tipo y el tamaño, las bandas que admite (tiene que cubrir todas las bandas que utiliza tu receptor) y su ubicación física respecto al resto de tus dispositivos electrónicos. La buena noticia es que puedes probar todo esto antes incluso de diseñar una PCB (placa de circuito impreso).
El hardware modular instalado en el banco de pruebas permitirá detectar problemas relacionados con las antenas y las interferencias de radiofrecuencia de forma económica y iterativa, que es precisamente el tipo de validación temprana y de bajo coste para la que están pensadas las fases de diseño del «lado izquierdo» del modelo en V de localización.
Error n.º 5: Elegir una IMU que no pueda soportar la diferencia
La variedad de calidades de las IMU (unidades de medición inercial) es enorme, desde unos pocos dólares hasta decenas o cientos de miles, o incluso decenas de miles de dólares (¡o más!). La especificación que suele importar no es la precisión que se anuncia, sino el tiempo que la IMU puede mantener la navegación cuando se pierde la señal del GNSS.
Las IMU de gama baja que forman parte de una solución combinada de GNSS e IMU suelen estar diseñadas para realizar navegación por estimación durante un periodo de entre diez y treinta segundos. Eso puede estar bien. Pero cuanto más tiempo tenga que funcionar por sí sola una IMU de gama baja, peor será la precisión de la solución. Si necesitas navegar por estimación durante un tramo prolongado bajo un aparcamiento, necesitarás una IMU de gama alta u otros sensores (velocidad de las ruedas, cámaras) que alimenten la fusión de sensores para compensar.
Aquí también hay que elegir entre diferentes opciones de configuración. Un módulo integrado con una IMU incorporada es una solución inercial generalizada que viene de serie. Funciona, y cuando se pierde la señal del GPS, es mejor que nada. Pero una solución generalizada no está adaptada a tu plataforma. Para plataformas nuevas o exigentes, un enfoque personalizado con la IMU adecuada y un motor de posicionamiento que modele tu dinámica ofrecerá un rendimiento superior.
Decide qué es lo que necesitas teniendo en cuenta el peor escenario posible de interrupción del servicio, y no lo que resulte más fácil de integrar.
Error n.º 6: Dar por sentado que la red siempre está disponible
Es fácil olvidar que el mundo no es tu entorno de pruebas. Aquí, en EE. UU., todavía hay zonas sin cobertura móvil importantes; en Europa la situación es mejor, pero las lagunas son reales y rara vez se tienen en cuenta en el diseño.
Las matemáticas no perdonan. Si se requiere una precisión de un centímetro en el 99,9 % de los casos, incluso una interrupción de la cobertura móvil del 0,1 % mientras se conduce hará que se falle la prueba, al instante. La solución no suele consistir en eliminar todas las zonas sin cobertura, sino en comprender el impacto y programarlo en consecuencia.
Si se pierden las correcciones durante diez segundos, un motor RTK bien diseñado no se desvía del mapa; pierde un poco de precisión y se recupera. Ese comportamiento fluido es una decisión de diseño que se toma desde el principio, no una sorpresa que se descubre en fase de producción.
La prueba del aparcamiento
Las pruebas al aire libre son un buen punto de partida. Son predecibles y confirman que el sistema funciona en lo esencial. El problema es dejar que se conviertan en tu referencia de validación, ya que las condiciones al aire libre se acercan mucho al mejor escenario que tu sistema podrá encontrar jamás. Apenas recurres a los demás sensores porque los datos del GPS son tan abundantes, el rendimiento parece excelente y da la sensación de que ya está todo listo.
Entonces, el producto se distribuye por las calles de los barrios periféricos, los muelles de carga, las hileras de árboles y los cañones urbanos, y las cifras se desmoronan. Las cifras de los aparcamientos no son tu punto de referencia para el diseño.
Lo que recomendamos desde el principio es un plan de pruebas que refleje fielmente el comportamiento real del sistema en el mundo real, y que se ejecute en los entornos más exigentes antes de la entrega definitiva (DVT), no después. Valida aquellos aspectos en los que es imprescindible que todo salga bien, no aquellos en los que ya sabes que funcionarán.
Se observa el mismo patrón en los seis errores más comunes...
No se trata de problemas aislados con soluciones aisladas. Como ya hemos señalado en el análisis anterior sobre el diseño de nuestro sistema de localización: un sistema que cuente con todos los componentes adecuados, pero que esté mal configurado o se pruebe en un entorno inadecuado, seguirá sin funcionar. Se trata de una interacción entre los componentes del sistema. El receptor, la antena, la IMU, las correcciones y el entorno determinan el resultado de forma conjunta.
Esa es precisamente la razón por la que conviene desarrollar la disciplina del prototipado rápido y la iteración en la «parte izquierda del modelo en V». Si estas interacciones salen a la luz en una fase temprana, con hardware representativo en condiciones representativas, el coste se limita a una breve conversación. Si, en cambio, surgen en la fase de DVT o en producción, suponen el coste de un rediseño.
En la próxima entrada, analizaremos el proceso de descubrimiento que llevamos a cabo con los clientes en el marco de Catalyst: cómo pasamos de una página en blanco a dos o tres arquitecturas de referencia listas para validarse en paralelo, de modo que estos errores se detecten antes de que se adquiera ningún hardware.
Si te encuentras en las primeras fases de un proyecto de diseño de un sistema de localización y quieres una segunda opinión antes de cerrar la arquitectura, podría ser una conversación muy productiva para nosotros.
Concierta una sesión de descubrimiento con un ingeniero de Point One
Preguntas frecuentes
¿Cuáles son los errores de diseño más habituales en la localización mediante GNSS?
Los seis errores más comunes: definir la precisión de forma demasiado imprecisa; copiar las especificaciones de la ficha técnica del receptor en los requisitos; elegir una clase de receptor inadecuada para la aplicación; subestimar la antena y su entorno de radiofrecuencia; seleccionar una IMU que no pueda realizar navegación por estimación durante el tiempo suficiente en caso de cortes de suministro; y dar por sentado que hay cobertura móvil en todas partes. La validación exclusiva en espacios abiertos oculta todos estos errores.
¿Por qué las especificaciones de precisión RTK que figuran en las fichas técnicas no se corresponden con el rendimiento real?
Las cifras que aparecen en las fichas técnicas, como «1 cm + 1 ppm», se miden en condiciones ideales: cielo despejado, una línea de visión corta hasta la estación base y ausencia de interferencias. Las plataformas reales presentan obstáculos e interferencias de radiofrecuencia internas procedentes de sus propios componentes electrónicos, por lo que el rendimiento en el terreno es casi siempre inferior al valor máximo indicado en la ficha técnica.
¿Durante cuánto tiempo puede un sistema GNSS/IMU navegar por estimación sin señal?
Depende de la IMU. Las IMU de menor coste, en una solución acoplada, suelen estar diseñadas para entre diez y treinta segundos de navegación por estima antes de que la deriva degrade la solución. Las aplicaciones que necesitan funcionar durante más tiempo sin GNSS (por ejemplo, bajo un aparcamiento) requieren una IMU de mayor calidad o sensores adicionales, como sensores de velocidad de las ruedas o datos de cámara.
¿Por qué la ubicación de la antena influye tanto en la precisión del GNSS?
La antena es el punto de entrada de la señal, y las plataformas modernas generan importantes interferencias de radiofrecuencia (RF) a nivel interno procedentes de la red móvil, el Bluetooth y los componentes informáticos. Una antena situada dentro de esa zona de interferencias puede perder la señal por completo, incluso cuando el receptor es capaz de alcanzar una precisión de centímetros. La cobertura de banda de la antena también debe coincidir con las bandas del receptor. Ambos aspectos pueden comprobarse con hardware modular antes del diseño de la placa de circuito impreso.
¿Qué ocurre con el RTK cuando se interrumpe la conexión móvil?
Un motor RTK bien diseñado no pierde la posición de forma inmediata cuando dejan de recibirse las correcciones. En caso de una interrupción breve, pierde un poco de precisión y se recupera cuando se restablece la conexión. La clave está en diseñar el sistema teniendo en cuenta ese comportamiento desde el principio, ya que incluso las interrupciones más breves pueden hacer que no se cumplan los requisitos estrictos de disponibilidad (como una precisión de un centímetro el 99,9 % del tiempo).