En resumen: Tras la fase de análisis, dispones de dos o tres arquitecturas que podrían cumplir de forma plausible tus requisitos. El objetivo de esta fase es reducir esas opciones a una sola —con datos reales, en hardware representativo— antes de que se envíe ninguna placa a fabricación. La decisión fundamental es dónde se ejecuta el motor de posicionamiento: en el módulo o en el host. Cuatro preguntas sobre el flujo de datos reducen el resto de opciones. Y la propia creación de prototipos suele sacar a la luz requisitos que no figuraban en el pliego de condiciones original, lo cual, en la parte izquierda del modelo en V, resulta barato de incorporar.
Esta es la cuarta entrada de una serie sobre el diseño de sistemas de localización para la autonomía y la robótica. En entradas anteriores se han tratado el modelo en V y las fases de un programa de diseño, los seis errores que con mayor frecuencia hacen fracasar los programas y los tres requisitos que deben resolverse antes de evaluar el hardware. Cada una de ellas surge de una conversación real entre Tom Weeks y yo. Esta entrada retoma el hilo justo donde termina la fase de descubrimiento.
La fase de descubrimiento te proporciona un conjunto de requisitos propios de tu producto, en lugar de una cifra que figure en una ficha técnica. Además, te ofrece dos o tres arquitecturas candidatas que podrían cumplir dichos requisitos de forma plausible.
Aquí es donde la parte izquierda del modelo en V deja de ser teórica. Hay que elegir una opción. Y la forma de hacerlo no es mediante un análisis más exhaustivo, sino probando las opciones en el entorno en el que el producto va a funcionar realmente.
Esta es la parte del trabajo que más me gusta.
La decisión clave: dónde se ejecuta el motor de posicionamiento
La mayoría de los receptores RTK del mercado son modulares. El motor de posicionamiento funciona con la capacidad de cálculo del propio módulo, que es limitada. Para muchas aplicaciones, esa es la solución adecuada, y conviene dejarlo claro: no estamos animando a los equipos a optar por arquitecturas basadas en host. La cuestión es confirmar que la solución integrada en el módulo realmente funciona para lo que estás desarrollando.
Donde deja de funcionar es cuando la aplicación necesita algo más que una solución estándar de RTK más IMU. Dinámicas de plataforma no estándar. Entornos urbanos degradados en los que la dispersión de señales es constante. Fusión con cámaras, lidar u odometría de ruedas. En esos casos, el límite de capacidad de cálculo del módulo se convierte en un obstáculo insuperable, y la solución es una arquitectura basada en el host, en la que el motor de posicionamiento se ejecuta en el procesador principal de la plataforma.
El cambio que estamos observando es que los equipos preguntan desde el principio si pueden aprovechar la capacidad de cálculo que ya existe en la plataforma. Un robot que ejecuta un conjunto de sistemas LIDAR ya dispone de una capacidad de cálculo considerablemente mayor que un módulo GNSS. A menudo, la respuesta es sí.
Un equipo que detecta esto en la prueba de validación del diseño (DVT) se enfrenta a un rediseño. Un equipo que lo detecta en la fase de selección de la arquitectura mantiene una conversación al respecto.
Cuatro preguntas que delimitan el resto de la arquitectura
La ubicación del motor de posicionamiento es el factor clave, pero hay cuatro cuestiones relacionadas con el flujo de datos que determinan todo lo que viene a continuación. Cada respuesta descarta determinadas arquitecturas.
¿Solo GNSS o con fusión inercial? Hay casos de uso en los que un motor basado únicamente en RTK es la mejor opción: si solo quieres basarte en la posición cuando tienes una fijación de fase portadora y gestionas la continuidad con otros sensores de tu propia pila, esa es la respuesta clara. Si el sistema necesita mantener la posición durante las interrupciones del GNSS, necesitas fusión inercial, y eso cambia la cuestión de cálculo anterior. También plantea la decisión entre un acoplamiento flexible o uno estrecho.
¿Cuál es la fuente de corrección? ¿ Puede la aplicación tolerar una precisión ligeramente menor a cambio de una cobertura más constante? Las soluciones SSR y VRS presentan un equilibrio diferente al del RTK de línea de base única, y la respuesta correcta depende del lugar en el que opere el producto y de la distancia a la que se encuentre de la estación de referencia más cercana. La densidad de la red es la variable que determina en qué medida hay que aceptar realmente ese compromiso.
¿Solo la posición, o un PVT completo con actitud? Un escáner de redes de servicios subterráneos que intenta determinar la ubicación absoluta necesita la posición. Eso es todo. Un vehículo que necesita conocer su desviación, cabeceo y balanceo en una curva de un circuito de carreras —o su rumbo al llegar al aparcamiento para que un sistema posterior sepa en qué dirección está orientado— presenta un requisito completamente diferente y un flujo de datos distinto en el back-end. Este es un aspecto que suele pasarse por alto, ya que el rumbo y la actitud no figuran en las especificaciones técnicas de un GNSS.
La actitud también tiene que provenir de algún elemento físico. Dos antenas en una línea de base fija proporcionan directamente el rumbo GNSS, y por eso existen los sistemas de doble antena —el nuestro es el Atlas Duo—. Una sola antena combinada con una IMU también puede proporcionar el rumbo, pero solo cuando la plataforma se mueve lo suficiente como para que el rumbo sea observable, lo cual es precisamente la limitación que afecta a un vehículo que necesita orientación estando parado. El cabeceo y el balanceo proceden de la solución inercial. Conviene decidir esto desde el principio, ya que se trata de una cuestión relacionada con el número de antenas y la forma de montaje, y no de un ajuste de software que se pueda modificar más adelante.
¿Cuáles son los requisitos de conectividad? Al fin y al cabo, los sistemas de gestión penitenciaria requieren conectividad. Comprender dónde funciona el producto y cómo es el acceso a la red en ese lugar forma parte de la arquitectura, no es un detalle de implementación que se resuelva más adelante.
En la práctica hay cuatro vías, y la mayoría de los sistemas acaban utilizando una principal y otra de reserva. La red móvil es la opción predeterminada para las plataformas terrestres: las correcciones llegan a través de NTRIP, y la contrapartida son las lagunas de cobertura. El Wi-Fi funciona cuando la plataforma opera dentro de un área de cobertura conocida, como un almacén o una obra fija. Un enlace de radio local con una estación base propia elimina por completo la dependencia de la red, razón por la cual sigue utilizándose en agricultura y topografía; sin embargo, no se puede ampliar más allá de las zonas geográficas en las que se hayan instalado estaciones base. El satélite de banda L proporciona correcciones donde no existe ninguna red terrestre, aunque con una precisión inferior a la del RTK terrestre.
La ruta alternativa determina qué ocurre en esa fracción de un por ciento que agota todo tu presupuesto de disponibilidad. Vale la pena decidirlo a propósito.
Creación de una prueba de concepto: representativa, no idéntica
Una vez que tengamos dos o tres arquitecturas de referencia, la tarea consistirá en reproducirlas lo más fielmente posible y ponerlas en práctica sobre el terreno.
Un ejemplo concreto de cómo se aplicaría esto: para un robot móvil de exterior de tamaño medio, las tres opciones podrían ser: (1) una solución basada en módulos RTK más IMU con correcciones a través de NTRIP móvil y salida de posición por puerto serie —el menor coste y el menor consumo de recursos de cálculo—; (2) el mismo hardware de receptor con el motor de posicionamiento ejecutándose en el ordenador principal del robot, añadiendo odometría de ruedas a la fusión para tramos con señal GNSS degradada; y (3) un acelerador de hardware integrado que proporciona datos PVT completos con actitud a través de Ethernet, con el menor número de incógnitas de integración y el mayor coste por unidad. Las tres opciones podrían cumplir los requisitos de precisión sobre el papel. Sin embargo, difieren enormemente en su comportamiento bajo una línea de árboles y en cómo queda la lista de materiales (BOM) para un pedido de 5 000 unidades.
El estándar es un hardware representativo, no un hardware idéntico. Lo ideal es que la prueba de concepto utilice el mismo hardware que el cliente tiene previsto comercializar, pero eso depende de sus plazos y de lo que haya disponible. Cuando no sea posible, lo que importa es la arquitectura de la ruta de la señal.
Por ejemplo: un equipo se ha decantado por un módulo del que no habrá muestras disponibles hasta dentro de tres meses. En lugar de perder el trimestre, desarrollamos el sistema con un receptor que tenemos a mano, configurado para emitir el mismo conjunto de mensajes a través de la misma interfaz serie y a la misma velocidad que verá su host en producción. Su trabajo de integración es un trabajo real. Los datos de rendimiento son datos reales. El número de referencia se cambia más adelante.
Si un cliente ya se ha decantado por un módulo que envía datos en serie a su host —es decir, el módulo calcula la posición a bordo y transmite la solución al procesador principal a través de una interfaz serie, en lugar de entregar observaciones sin procesar para que el host las procese—, construiré un equipo que envíe datos en serie a un host, incluso si el receptor subyacente es diferente. Si utilizan un receptor de gama alta, puedo construir algo estructuralmente similar con un kit de evaluación (EVK) diferente, es decir, la placa de desarrollo suministrada por el fabricante que se utiliza para probar un receptor antes de decidirse por un diseño. Lo que estamos validando es la arquitectura, no la lista de materiales (BOM).
Esa distinción es lo que hace posible la creación rápida de prototipos. Si tienes que esperar meses a recibir tus primeras placas antes de poder realizar pruebas significativas, habrás agotado tu margen de tiempo antes de haber aprendido nada. Y si las pruebas que realizas en ese plazo se centran en un único componente en lugar de en el sistema, ahí es donde las cosas se tuercen.
Caso práctico: RTK en gafas inteligentes
Las gafas inteligentes con cámaras y unidades inerciales están apareciendo por todas partes últimamente. Un cliente que estaba desarrollando un sistema VIO —odometría visual-inercial, que determina la posición mediante la fusión de imágenes de cámara con datos de la IMU— se puso en contacto con nosotros porque quería añadir GNSS.
Ya habían descartado el GPS. Lo habían probado, no funcionaba, y habían pasado a otra cosa.
Cuando nos metimos de lleno en lo que realmente habían probado, el problema era la ubicación de la antena. La calidad de la señal que se obtiene de un dispositivo que se lleva en el pecho o colocado a un lado de la cabeza no va a funcionar. El bloqueo del cuerpo y la variabilidad en la orientación hacen que se trate de un entorno de señal fundamentalmente diferente al de una antena montada en el techo de un coche. Eso no era un problema del GPS. Era un problema de diseño del que se estaba culpando al GPS.
Así que construimos algo que se pudiera probar. Nos enviaron un kit de evaluación de su propia plataforma informática —el mismo procesador con el que se comercializaría su producto—, montado en una placa de desarrollo a la que podíamos conectar los cables. Conectamos el mismo receptor con el que ellos estaban trabajando y construimos un pequeño equipo modular que pudiera llevar puesto una persona real en entornos reales. Hay fotos mías llevándolo puesto: el dispositivo informático en la cadera, la antena en su sitio y, junto a ella, una antena en la cabeza que actuaba como sistema de referencia.
Ese dispositivo de referencia sobre el terreno que se lleva en la cabeza es deliberadamente de baja tecnología y lleva mucho tiempo funcionando. Está disponible por si alguien lo necesita.
Una vez establecido esto, podríamos recopilar datos reales con ellos y responder a preguntas concretas. ¿En qué medida degrada cada entorno la calidad de la señal? ¿Qué puede hacer el motor de posicionamiento con una señal degradada para seguir ofreciendo una solución útil? ¿Con qué precisión puede la IMU mantener la posición cuando se interrumpe la señal del GNSS?
Y eso les abrió una vía que no habían barajado: ya disponían de un sistema informático que ejecutaba un sistema VIO. La solución inercial generalizada del módulo no está optimizada para la dinámica humana, pero no hay razón para que la fusión GNSS no pueda ejecutarse en el sistema informático que ya tienen.
El producto pasó de «el GPS no nos sirve» a convertirse en una arquitectura viable. No porque tuviéramos un algoritmo mejor, sino porque probamos lo que había que probar.
La creación de prototipos es una herramienta para definir requisitos, no solo una herramienta de validación
Los dispositivos portátiles son la norma, no la excepción. Las aplicaciones más recientes en el ámbito de la localización de precisión —dispositivos portátiles para equipos de primera intervención, equipos de seguridad, sensores corporales— plantean durante la fase de prototipado requisitos que no figuraban en el pliego de condiciones original.
A veces eso implica volver al fase de descubrimiento. En el lado izquierdo del modelo en V, ese bucle no supone un gran coste. Basta con modificar un documento y volver a montar una plataforma. En el lado derecho, ese mismo bucle supone un rediseño, un retraso y, en el peor de los casos, una cancelación.
La versión iterativa de esta fase podría expresarse así: «ese hardware no ha funcionado, pongamos en marcha algo con hardware de gama alta y veamos si mejoran los resultados». O bien: «vamos a dar un paso atrás y a replantearnos qué es lo que realmente se está intentando conseguir». Ambas opciones son económicas en este momento. Ninguna de las dos lo es una vez que se han fabricado decenas, cientos o miles de placas y se ha detectado un fallo en ese momento.
Dónde encajan los aceleradores de hardware
Hay una vía intermedia que conviene conocer. Parte de cómo llevamos a cabo este proceso consiste en utilizar hardware de calidad industrial que integra todo lo necesario —receptor, IMU, motor RTK y fusión de sensores— en una sola unidad. A estos dispositivos los denominamos «aceleradores de hardware». Atlas INS y Atlas Duo son la generación actual.
Si se trata de 10 o 50 unidades, es posible que ni siquiera necesites un diseño basado en módulos. Puedes utilizar un acelerador de hardware que sea representativo de la arquitectura que estás validando. A partir de 1.000 unidades, tiene sentido crear tu propio diseño basado en módulos. A partir de 10 000 o 20 000 unidades, lo que hay que plantearse es un diseño «chip-down», es decir, colocar el chipset receptor directamente en tu propia placa de circuito impreso en lugar de comprar un módulo preensamblado. El diseño «chip-down» requiere un esfuerzo de ingeniería inicial, pero se amortiza en la lista de materiales (BOM) y en el espacio ocupado en la placa a medida que aumenta el volumen de producción.
El método de prueba de concepto sigue siendo válido en cada una de esas transiciones. No basta con incorporar un nuevo receptor a un producto ya en el mercado y dar el tema por zanjado. Cada generación pasa por las mismas fases, que es precisamente donde tiene lugar el interesante trabajo de reducción de costes. Reducir el número de chips en la próxima generación puede permitirte disponer de más bandas, más constelaciones y una lista de materiales (BOM) más baja, ya que se eliminan las partes del módulo que no se utilizaban.
El resultado final
El resultado de esta fase es una arquitectura, seleccionada a partir de los datos.
Pero el objetivo real es más específico que eso. Para cuando un diseño pasa a la fase de fabricación, la probabilidad de que se produzca un incumplimiento catastrófico de los requisitos —un fallo en el diseño del sistema que obligue a volver a la parte izquierda de la «V» o que acabe con el programa— debería ser lo más cercana posible a cero, en la medida en que el proceso lo permita.
Eso es lo que aportan las pruebas. No la certeza, que nadie tiene. La confianza de que aquello a lo que te estás comprometiendo ya ha sido probado en las condiciones en las que realmente se va a comercializar.
En la próxima entrada se explica qué ocurre al pasar a la fase de pruebas de validación de ingeniería (EVT) y cómo se presenta la parte derecha del modelo en V cuando la parte izquierda se ha llevado a cabo correctamente.
Si estás evaluando diferentes opciones de arquitectura y quieres someterlas a pruebas de estrés con datos reales antes de tomar una decisión, reserva un taller de descubrimiento con un ingeniero de Point One.
Mira la conversación completa — Episodio 2 de «Catalyst»
Preguntas frecuentes
¿En qué consiste la fase de arquitectura y creación de prototipos en el diseño de un sistema de localización?
Es el paso que media entre los requisitos y la elección del hardware. Se empieza con dos o tres arquitecturas candidatas identificadas en la fase de análisis, se construyen prototipos representativos de cada una, se prueban en el entorno operativo real y se utilizan esos datos para seleccionar una. El objetivo es descartar arquitecturas basándose en pruebas, más que en análisis.
¿Debería ejecutarse el motor de posicionamiento en el módulo GNSS o en el equipo principal?
Depende de los requisitos de potencia de cálculo. La mayoría de los receptores RTK modulares ejecutan el motor de posicionamiento en el propio módulo, lo cual resulta suficiente para aplicaciones con buena disponibilidad de cielo abierto y necesidades estándar de RTK más IMU. Las aplicaciones que requieren una fusión de sensores compleja —dinámicas de plataforma no estándar, entornos urbanos con señal degradada o fusión con cámaras, lidar u odometría— suelen superar el límite de capacidad de cálculo del módulo y necesitan una arquitectura basada en un host. Decidir esto en la fase de requisitos resulta económico; descubrirlo en la fase de DVT implica un rediseño.
¿Qué significa «hardware representativo» en una prueba de concepto de GNSS?
Hardware que reproduce la ruta de la señal y el flujo de datos del diseño previsto, incluso cuando los componentes concretos difieran. Si el diseño de producción es un módulo que envía datos en serie a un host, el prototipo debe ser un módulo que envíe datos en serie a un host; el receptor concreto puede ser diferente. Lo que se valida es la arquitectura, no la lista de materiales.
¿Cómo se obtienen el rumbo y la actitud a partir de un sistema GNSS?
Hay dos formas. Una configuración de doble antena en una línea de base fija proporciona directamente el rumbo GNSS y funciona incluso con la plataforma parada. Una sola antena combinada con una IMU también puede proporcionar el rumbo, pero solo cuando la plataforma se mueve lo suficiente como para que el rumbo sea observable. El cabeceo y el balanceo se obtienen a partir de la solución inercial. Dado que esto determina el número de antenas y su montaje, debe decidirse durante la selección de la arquitectura, en lugar de tratarse como una configuración de software.
¿Qué opciones de conectividad hay disponibles para transmitir correcciones RTK?
La conexión móvil a través de NTRIP es la opción predeterminada para la mayoría de las plataformas terrestres, aunque a cambio presenta lagunas de cobertura. El Wi-Fi funciona para plataformas que se limitan a un área de cobertura conocida. Un enlace de radio local con tu propia estación base elimina la dependencia de la red, pero no se puede ampliar más allá de las zonas geográficas en las que hayas instalado estaciones base. El satélite de banda L proporciona correcciones donde no existe red terrestre, con una precisión inferior a la del RTK terrestre. La mayoría de los sistemas de producción utilizan una ruta principal y una de reserva, y esta última determina el comportamiento durante el periodo de interrupción que incumple el requisito de alta disponibilidad.
¿Por qué es tan importante la ubicación de la antena en los dispositivos portátiles?
Una antena instalada en el techo de un vehículo cuenta con una vista despejada del cielo y un plano de tierra que le favorecen. Una antena que se lleva en el pecho o se coloca en el lateral sufre el bloqueo que supone el cuerpo y cambios constantes de orientación, lo que genera un entorno de señal fundamentalmente diferente. A menudo, los equipos concluyen que el GNSS no funciona con su dispositivo portátil cuando, en realidad, la limitación es la ubicación. Realizar pruebas con un banco de pruebas representativo permite diferenciar ambos casos.
¿Cómo se mide el valor de referencia de un sistema de posicionamiento que se lleva en el cuerpo?
Con un segundo sistema de referencia de mayor calidad que se lleva en la misma plataforma. En el caso de los dispositivos wearables, utilizamos un sistema de antenas que se coloca en la cabeza como referencia de referencia —deliberadamente sencillo y eficaz—. Sin una referencia de referencia, se pueden recopilar datos, pero no se puede medir el error, lo que hace que las pruebas sean mucho menos útiles.
¿Qué es el SSR y cuándo conviene utilizarlo en lugar del RTK de línea de base única?
La SSR (representación en espacio de estados) corrige las fuentes de error del modelo en toda una región, en lugar de transmitir observaciones desde una única estación de referencia. Las soluciones SSR y VRS suelen ofrecer una cobertura más homogénea en áreas más extensas, a cambio de una precisión máxima ligeramente inferior a la de una solución RTK de una sola estación con línea de base corta. La elección adecuada depende de la zona en la que se utilice el producto y de la densidad de las estaciones de referencia. La densidad de la red determina el grado de intensidad de esa compensación.
¿Qué es un acelerador de hardware en el diseño de sistemas de localización?
Una unidad de calidad de producción que integra un receptor, una IMU, un motor RTK y la fusión de sensores en un único sistema integrado. Permite a un equipo lanzar al mercado productos en pequeñas series sin tener que desarrollar su propio diseño basado en módulos, y sirve como hardware de referencia durante la validación de la arquitectura. Atlas INS y Atlas Duo son los aceleradores de hardware de Point One.
¿Qué es un diseño «chip-down»?
Incorporar el chipset de un receptor GNSS directamente en tu propia placa de circuito impreso, en lugar de utilizar un módulo ya ensamblado. Aunque supone un mayor esfuerzo de ingeniería inicial y requiere conocimientos de diseño de radiofrecuencia, esta decisión se amortiza en cuanto a costes de la lista de materiales y espacio en la placa cuando se producen grandes volúmenes. Además, permite ampliar las prestaciones, ya que ya no estás limitado a la configuración de banda y constelación que haya elegido el proveedor del módulo.
¿Cómo cambia la arquitectura de localización a medida que el volumen pasa de 100 a 100 000 unidades?
La arquitectura que resulta adecuada para 100 unidades no suele serlo para 100 000. A bajo volumen, un acelerador de hardware integrado suele ser la opción más rápida. A medida que aumenta el volumen, resulta más rentable un diseño propio basado en módulos, y con un volumen elevado, lo más rentable es un diseño «chip-down». Cada transición debe pasar por el mismo proceso de prueba de concepto, y cada una de ellas supone una oportunidad, ya que los diseños «chip-down» permiten añadir bandas y constelaciones al tiempo que reducen los costes al eliminar los componentes de los módulos que no se utilizaban.
¿Cómo puedo obtener más información sobre el proceso Catalyst?
Catalyst es la metodología de Point One para el diseño de sistemas de localización. La entrada sobre el modelo en V aborda las fases y explica por qué las decisiones de la parte izquierda determinan los costes de la parte derecha. La entrada sobre los seis errores habituales aborda las decisiones concretas que con mayor frecuencia provocan rediseños. La entrada sobre la fase de descubrimiento aborda los tres requisitos previos que preceden a la selección de la arquitectura. Las próximas entradas profundizarán en la EVT, la parte derecha de la V, y en cómo evolucionan los requisitos de posicionamiento a gran escala. También puedes explorar directamente el motor de posicionamiento o concertar una reunión con un ingeniero de campo.