En resumen: Antes de evaluar cualquier hardware GNSS/RTK, se necesitan tres datos: las restricciones de diseño (potencia, coste, factor de forma y capacidad de cálculo —siendo esta última la más subestimada—, el entorno operativo (visibilidad del cielo, montaje de la antena y dinámica de la plataforma) y el caso de uso de la aplicación (lo que el sistema debe ofrecer en sus peores momentos, no en los mejores). Una hora dedicada a analizar en profundidad estos tres aspectos permite obtener dos o tres arquitecturas candidatas listas para las pruebas en el mundo real, y evita los rediseños que acaban con los programas en la fase de DVT.
Lo que más suelo oír cuando llega un nuevo cliente es: «Necesito una precisión de un centímetro con el GPS».
Esa cifra solía proceder de la ficha técnica del receptor. Encontraron un módulo compatible con RTK, vieron las especificaciones —«un centímetro más una parte por millón multiplicada por la línea de base»— y lo incluyeron en sus requisitos. La pregunta que surge a continuación es: ¿cómo consigue realmente ese receptor una precisión de un centímetro en todos los entornos en los que va a funcionar el producto?
Ese es el comienzo del proceso de descubrimiento.
La cifra que figura en la ficha técnica es real, pero se ha medido en condiciones ideales: visión perfecta del cielo, una antena sin ningún tipo de interferencia y una distancia corta hasta la estación base. La mayoría de los productos no funcionan ni de lejos en esas condiciones. La ficha técnica no incluye datos de precisión para seis entornos diferentes, porque esos entornos no son problema suyo, sino que es usted quien debe diseñarlos.
El análisis de requisitos es el proceso de sustituir un valor que figura en la ficha técnica por un conjunto de requisitos propios de tu producto.
El instinto de pasar rápidamente al hardware es acertado: el orden es importante
Los ingenieros quieren crear y probar. Es lógico que se sientan atraídos por el hardware. Pero actuar antes de recabar la información necesaria es precisamente lo que hace que los programas pierdan tiempo.
Los equipos que acortan el calendario en la parte izquierda del modelo en V son los que gestionan bien la fase de descubrimiento. Una conversación centrada en el descubrimiento aborda los aspectos fundamentales en aproximadamente una hora. Las opciones de arquitectura comienzan a perfilarse durante esa conversación, no después, y el resultado es un equipo que consigue hardware representativo más rápidamente, con mayor confianza en la arquitectura que está probando.
El sistema que se está diseñando es toda la pila de localización: antenas, receptores, IMU, software del motor de posicionamiento y conectividad para las correcciones. No se trata solo del módulo GNSS. Cada elemento se adapta en función de los resultados de la fase de exploración.
Los tres factores a tener en cuenta son las restricciones de diseño, el entorno operativo y el caso de uso de la aplicación.
Entrada 1: Restricciones de diseño: los cuatro límites físicos que condicionan todas las decisiones relativas al hardware
Antes de evaluar el hardware, es necesario conocer las restricciones a las que debe someterse cualquier opción de hardware. Estas definen los límites del espacio de diseño.
Presupuesto energético. Un dispositivo portátil cuenta con una batería de poca capacidad. Esa limitación reduce de inmediato la gama de receptores disponibles. Los receptores de mayor capacidad suelen consumir más energía, por lo que un presupuesto energético más ajustado obliga a realizar concesiones en otras partes del sistema.
Objetivo de coste. Un receptor topográfico de gama alta en cada dron de una flota ofrece un posicionamiento excelente, pero no resulta viable a gran escala. El objetivo de coste define el límite máximo del hardware en función del volumen. Las correcciones RTK cambian significativamente este cálculo: un receptor de menor coste con acceso a una red de correcciones puede alcanzar una precisión que no podría lograr por sí solo, lo que abre una relación coste-rendimiento que la mayoría de los equipos no tienen en cuenta inicialmente.
Tamaño, factor de forma y espacio disponible en la placa de circuito impreso. La antena debe colocarse en algún lugar de la plataforma que permita una visión despejada del cielo. El receptor y la unidad de procesamiento deben ajustarse a la envolvente mecánica. El espacio disponible en la placa de circuito impreso es limitado, y cada componente que lo comparte supone un riesgo potencial de interferencias de radiofrecuencia. El factor de forma determina la ubicación de la antena, lo que a su vez influye en la calidad de la señal y, por ende, en todo el sistema de posicionamiento.
Disponibilidad informática: no elijas la opción equivocada. Esta es la limitación que más se subestima y la que provoca los rediseños más problemáticos en las últimas fases del proyecto.
La mayoría de los receptores RTK son modulares: el motor de posicionamiento funciona con la capacidad de cálculo propia del módulo, que es limitada. Para aplicaciones con buena visibilidad del cielo, esto no supone ningún problema. Sin embargo, cuando es necesario fusionar sensores adicionales, la dinámica de la plataforma es compleja o se requiere algo más allá de una solución estándar de RTK más IMU, el límite de capacidad de cálculo se convierte en un obstáculo insuperable.
Los equipos que se basaron en un receptor modular y descubrieron en DVT que la fusión de sensores que requería su entorno superaba las capacidades del módulo se enfrentaron a dos opciones: reducir el sistema o rediseñarlo en torno a una arquitectura basada en un host, en la que el motor de posicionamiento se ejecutara en el procesador principal de la plataforma. Cualquiera de las dos opciones resulta costosa en esa fase.
El cambio que estamos observando es que los equipos se plantean antes la pregunta: ¿podemos aprovechar la capacidad de cálculo con la que ya cuenta la plataforma? A menudo, la respuesta es sí, y detectar esto desde el principio permite que la decisión sobre la arquitectura resulte más económica.
Entrada 2: Entorno operativo: tres capas que determinan las condiciones a las que debe resistir el hardware
Las restricciones de diseño definen cómo debe ser el hardware. El entorno operativo define a qué condiciones debe resistir.
Dónde opera el GNSS. El cielo abierto es el caso más sencillo. Si un producto funciona siempre a cielo abierto y dispone de conexión a Internet, un motor exclusivamente RTK puede ser la solución adecuada —y vale la pena decirlo sin rodeos—. Pero el cielo abierto rara vez representa el panorama completo. Los entornos urbanos, las obras de construcción, las transiciones entre interiores y exteriores, y cualquier situación en la que se trabaje cerca de estructuras generan multitrayectoria y degradación de la señal, lo que cambia por completo la arquitectura del sistema. Un escáner subterráneo de redes de servicios públicos que funciona en un aparcamiento no es el mismo producto que uno que escanea justo contra la pared de un edificio.
El soporte en el que se monta el dispositivo. Una antena instalada en el techo de un coche cuenta con una excelente visión del cielo y un plano de tierra que juega a su favor. Un dispositivo que se lleva en el pecho o en el hombro presenta un entorno de señal diferente: obstrucción por el cuerpo, variabilidad en la orientación y una calidad de señal más difícil de gestionar. El soporte físico determina la calidad inicial de la señal, lo que a su vez determina el esfuerzo que debe realizar el motor de posicionamiento, lo que a su vez determina qué sensores son necesarios en la fusión.
Dinámica de la plataforma, vibraciones y modelos de movimiento. Un dron tiene características de movimiento diferentes a las de un coche. Un vehículo con dirección en las cuatro ruedas se comporta de forma diferente a una plataforma con dirección en dos ruedas, lo cual influye en la forma en que un algoritmo de fusión de sensores modela el movimiento. Un tractor agrícola presenta perfiles específicos de vibración y deslizamiento. Una persona que camina genera una firma dinámica completamente diferente.
El modelo de movimiento es donde todo esto se materializa. El software de fusión de sensores modela cómo se mueve la plataforma concreta: qué hace cuando acelera, gira, vibra o pierde la señal del GNSS momentáneamente. Un modelo generalizado se adapta adecuadamente a una amplia gama de plataformas. En lo que respecta al rendimiento, una solución ajustada a la dinámica real de la plataforma ofrecerá mejores resultados. La mayoría de los receptores modulares incluyen una solución inercial generalizada; se trata de una compensación conocida, pero debe ser la adecuada para la aplicación.
La calidad de la señal es el nexo de unión entre las tres capas. Es el factor determinante principal a la hora de establecer si es posible obtener una precisión RTK a nivel centimétrico en un entorno operativo concreto.
Entrada 3: Caso de uso de la aplicación: lo que el sistema tiene que generar en sus momentos más difíciles
¿Qué debe ofrecer el sistema en sus momentos más difíciles, y no en los más fáciles? Un producto que alcanza una precisión de centímetros a cielo abierto, pero que falla en cualquier otro lugar, no es un producto, sino un prototipo que ha superado la prueba equivocada. El objetivo es un sistema que funcione el 99,9 % del tiempo, en toda la variedad de entornos a los que se enfrentará la aplicación.
Eso significa que la precisión debe establecerse en un nivel que sea factible desde el punto de vista del diseño. Un centímetro es un objetivo. Lo que importa es el error de una sigma, el error de dos sigmas, el nivel de protección y lo que hace el sistema cuando no puede cumplir esos límites. ¿Solo la posición, o también la actitud —rumbo, cabeceo y balanceo—? Un vehículo que necesita conocer su orientación al tomar una curva con inclinación lateral plantea un problema diferente al de un escáner que solo necesita la ubicación absoluta.
La conversación sobre la aplicación también pone de manifiesto limitaciones que no resultaban evidentes desde el principio. Un equipo que describe su producto como un dispositivo portátil para uso al aire libre puede que, en un primer momento, no lo plantee como un problema propio del entorno urbano, hasta que se comprenda el caso de uso. Una vez que esto queda claro, las implicaciones de diseño se derivan directamente.
Resultados empresariales y escalabilidad. ¿ Cómo se escala la aplicación? El volumen previsto determina la estrategia de corrección, los requisitos de conectividad y las decisiones de arquitectura, incluso cuando estos aspectos parecen lejanos en la fase de definición de requisitos. El análisis inicial es, en sí mismo, una inversión en productividad: una hora dedicada exclusivamente a recabar información permite acortar semanas de iteraciones que, de otro modo, tendrían lugar en la fase de DVT.
¿Qué aporta un buen descubrimiento?
El resultado de una conversación de análisis de necesidades bien llevada no es un diseño definitivo, sino dos o tres arquitecturas de referencia que, con toda probabilidad, cumplen los requisitos y que están listas para ser evaluadas entre sí con hardware real en condiciones reales.
Lo importante en esta fase es mantener abiertas varias opciones. La fase de exploración proporciona información suficiente para evitar descartar una arquitectura inadecuada demasiado pronto. El siguiente paso —las opciones de arquitectura y la creación de prototipos en condiciones reales— consiste en construir versiones representativas de cada opción candidata y probarlas en el entorno operativo real antes de que se fabrique ninguna placa.
De eso trata la próxima entrada.
Si te encuentras en las primeras fases de un proyecto de diseño de un sistema de localización y deseas repasar los datos de análisis inicial antes de decidirte por el hardware, programa un taller de análisis inicial con un ingeniero de Point One.
Mira la conversación completa — Episodio 2 de «Catalyst»
Preguntas frecuentes
¿En qué consiste el proceso de selección de Catalyst?
Catalyst es la metodología de Point One para el diseño de sistemas de localización. La fase de análisis es el primer paso: una conversación estructurada para identificar las limitaciones de diseño, el entorno operativo y los requisitos de la aplicación antes de evaluar cualquier hardware. Suele durar aproximadamente una hora y da como resultado dos o tres arquitecturas candidatas listas para su validación en condiciones reales.
¿Cuáles son los tres elementos fundamentales para el diseño de un sistema de localización GNSS?
Los tres factores a tener en cuenta son las restricciones de diseño (presupuesto energético, objetivo de coste, tamaño y factor de forma, y disponibilidad de recursos informáticos), el entorno operativo (visibilidad del cielo para el GNSS, montaje físico y dinámica de la plataforma) y el caso de uso de la aplicación (resultados requeridos, límites de precisión y resultados empresariales a gran escala).
¿Por qué las especificaciones técnicas de un receptor no son suficientes como requisito del sistema?
Las cifras de las fichas técnicas, como «1 cm + 1 ppm», se miden en condiciones ideales: a cielo abierto, con una línea de base corta y sin interferencias. Los productos reales funcionan en entornos que no se ajustan a esas condiciones, y la ficha técnica no indica cuál es el rendimiento cuando no se dan esas condiciones. Utilizar una especificación de la ficha técnica como requisito significa diseñar para el mejor caso que jamás se vaya a dar, y no para las condiciones reales en las que se va a utilizar el producto.
¿Qué es la disponibilidad computacional y por qué es importante para el diseño de los sistemas GNSS?
La mayoría de los receptores GNSS modulares se suministran con una capacidad de cálculo integrada limitada. En el caso de aplicaciones que requieren una fusión compleja de sensores —como la fusión de datos GNSS con datos de IMU, cámaras, lidar o dinámicas de plataforma no estándar—, ese límite de capacidad de cálculo se convierte en una restricción importante. Los equipos que descubren este problema en la fase de validación del diseño, en lugar de en la de definición de requisitos, se enfrentan a un costoso rediseño arquitectónico. Identificarlo a tiempo permite que la decisión resulte más económica.
¿Qué es un modelo de movimiento y por qué influye en el rendimiento de la localización?
Un modelo de movimiento es el conjunto de supuestos que se incluyen en el software de fusión de sensores sobre cómo se mueve una plataforma: su dinámica, su comportamiento en los giros, su perfil de vibración y su respuesta a la aceleración. Un modelo generalizado permite gestionar adecuadamente una amplia gama de plataformas. Las aplicaciones que operan al límite de sus prestaciones, con una dinámica inusual o con requisitos de precisión exigentes, se benefician de un modelo adaptado a su plataforma específica.
¿Cómo influye el entorno operativo en la selección del hardware GNSS?
El entorno determina la calidad de señal que puede esperar el sistema, lo que a su vez condiciona la arquitectura de fusión y, por ende, la selección del hardware. En espacios abiertos es posible adoptar un enfoque más sencillo basado únicamente en RTK. Los entornos urbanos, las aplicaciones que se llevan en el cuerpo y las plataformas con una dinámica compleja requieren sensores adicionales, IMU de mayor precisión y un software de posicionamiento adaptado a la plataforma específica.
¿Cuánto tiempo dura la fase de investigación?
En la mayoría de los proyectos, la reunión inicial de análisis dura aproximadamente una hora. Durante la misma, empiezan a perfilarse las opciones de arquitectura. En el caso de proyectos más amplios o entornos más complejos, puede ser necesario realizar un seguimiento interno antes de presentar una propuesta formal, pero la mayor parte de la recopilación de información se lleva a cabo con rapidez cuando se formulan las preguntas adecuadas en el orden correcto.
¿Cómo puedo obtener más información sobre la fusión de sensores para los sistemas de localización GNSS?
La fusión de sensores —la combinación de datos de GNSS, IMU y otros sensores en una única salida de posición— es un hilo conductor que recorre todas las fases del diseño de un sistema de localización. La serie Catalyst aborda este tema en profundidad a lo largo de varias entradas. La entrada sobre el modelo en V explica por qué las decisiones de fusión tomadas en las primeras fases del proceso de diseño se convierten en las restricciones más difíciles de modificar posteriormente. La entrada sobre los seis errores habituales aborda las decisiones específicas relacionadas con la fusión —nivel de precisión de la IMU, arquitectura de cálculo, modelo de movimiento— que con mayor frecuencia provocan rediseños en la fase de DVT. Las próximas entradas de la serie profundizarán en las opciones de arquitectura, la creación de prototipos de prueba de concepto y cómo cambian los requisitos de fusión a medida que el diseño pasa de 10 unidades a 100 000. También puedes explorar directamente el motor de posicionamiento de Point One o concertar una reunión con un ingeniero de campo.