De las nubes de puntos y la realimentación del chasis a la alineación temporal y la estimación de estado con EKF.
En el artículo anterior, las cámaras GMSL2, la calibración y la proyección en vista de pájaro ayudaron al robot a observar su entorno. Cuando el chasis empieza a moverse aparece otra serie de preguntas. ¿Por qué la misma pared deja un contorno doble en una nube de puntos? ¿Por qué una trayectoria estimada se curva cuando el robot avanza en línea recta? ¿Por qué agregar otro sensor puede hacer que el resultado salte?
Muchas veces el robot tiene varias mediciones que parecen válidas, pero sin una relación coherente entre sus tiempos, sus marcos de coordenadas y sus modelos de movimiento.
Las cámaras registran imágenes, el LiDAR mide la geometría del entorno, los encoders registran el giro de las ruedas, una IMU mide la velocidad angular y la fuerza específica, y el GNSS entrega una referencia de posición en exteriores. Cada fuente aporta algo útil y cada una tiene limitaciones. Las ruedas patinan, los sensores inerciales arrastran sesgo y las mediciones satelitales sufren por obstrucción y multitrayecto.
La fusión de sensores combina estas observaciones para estimar el movimiento y el estado del robot, con una incertidumbre asociada al resultado. Antes de combinarlas hay que establecer qué significa cada medición y si se puede comparar con las demás.
El módulo 3 lleva ese proceso desde la validación de datos en ROS 2, pasando por el preprocesamiento de nubes de puntos, una referencia de tiempo común y las relaciones TF, hasta un EKF bidimensional con robot_localization. El primer experimento local fusiona la velocidad de las ruedas con la tasa de giro de la IMU, y el GNSS agrega una capa de posicionamiento global. Los puntos crudos del LiDAR no entran directamente a este EKF mínimo. Estos ejercicios dejan la base de datos para el trabajo de SLAM y mapeo del módulo M05.
Distintos sensores observan aspectos distintos del mismo robot. Sus unidades, marcas de tiempo, marcos y su incertidumbre deben entenderse antes de fusionarlos.
¿Recién llegas a la serie? La introducción del curso explica la ruta de aprendizaje completa, y el módulo 1 arma el entorno de desarrollo con Jetson y ROS 2. El entorno de referencia del M03 usa el hardware reComputer Robotics J501, Ubuntu 22.04 y ROS 2 Humble, con ejemplos en el J5011 para integrar sensores y chasis.
GitHub del curso, Mobile Robot Full-Stack Development in Practice
El LiDAR ve una pared, ¿por qué eso todavía no es localización?
Lanzar un driver y ver una habitación en RViz es un primer resultado satisfactorio. Esa visualización todavía no dice si las mediciones están completas, cuándo se tomaron ni si su geometría se mantiene coherente mientras el robot se mueve.
Los experimentos de integración del LiDAR parten con el RPLIDAR A1 por USB y pasan después al Livox MID-360 conectado por Ethernet. Los dos caminos usan conexiones y estructuras de mensajes de ROS distintas.
Un escaneo 2D es una secuencia de mediciones
El driver del A1 publica /scan como sensor_msgs/msg/LaserScan. Envía distancias ordenadas por ángulo, no un mapa terminado. Para la muestra i, su dirección se obtiene del ángulo inicial y del incremento angular.
theta_i = angle_min + i * angle_increment
x_i = range_i * cos(theta_i)
y_i = range_i * sin(theta_i)Estas coordenadas pertenecen al marco del escáner. Llevarlas al marco del robot o del mapa requiere la transformación correspondiente.
La validez de cada distancia también importa. Los retornos infinitos, inválidos y fuera de rango deben tratarse según el contrato del mensaje. Incluso un valor finito por debajo del range_min declarado no sirve como medición de obstáculo.
Con el driver configurado en marcha y el entorno de ROS cargado, se inspeccionan la interfaz, la frecuencia observada y el contenido de los mensajes.
ros2 topic info /scan --verbose
ros2 topic hz /scan
ros2 topic echo /scan --onceLa prueba de referencia del curso con el A1 registra cerca de 7,55 Hz, con un objetivo configurado de 10 Hz. Ese resultado corresponde al montaje documentado. La configuración y la frecuencia de publicación que observa el suscriptor son dos cosas distintas que hay que revisar en el robot propio.
Salida del escaneo del A1 en laser. La advertencia de TF visible muestra también que ver el flujo de un sensor y completar el árbol de marcos del robot son hitos distintos.
Ethernet suma una dependencia de red y una opción de salida
El MID-360 envía la nube de puntos y los datos de su IMU por Ethernet. El sensor, la interfaz cableada del equipo y las direcciones del driver deben coincidir, y la máquina de desarrollo puede necesitar otra interfaz para salir a internet. Hay que usar la dirección de la interfaz conectada al LiDAR. Copiar una dirección de Wi-Fi o una IP de ejemplo en la configuración puede romper el camino previsto.
La elección del archivo de lanzamiento también cambia el contrato de datos. En el curso, msg_MID360_launch.py entrega los mensajes de nube de puntos propios de Livox y la salida de la IMU, mientras rviz_MID360_launch.py entrega el camino estándar de visualización con PointCloud2.
El nombre de un tópico no garantiza el tipo de mensaje. Hay que revisar /livox/lidar antes de conectar un suscriptor. Si el procesamiento posterior necesita el tiempo de cada punto, conviene verificar que la conversión lo conserve. Una representación cómoda para visualizar puede omitir información necesaria para corregir el movimiento.
Salida PointCloud2 del MID-360 con livox_frame. La advertencia de Fixed Frame sigue siendo parte de este ejemplo de vista previa del sensor, y la alineación TF todavía debe revisarse.
El preprocesamiento cambia lo que ve el siguiente algoritmo
Una nube cruda puede contener el propio cuerpo del robot, regiones lejanas que no interesan y ruido aislado. El curso introduce el recorte por distancia y por cuerpo, el submuestreo por vóxeles, la eliminación de puntos atípicos y la transformación de coordenadas.
Una grilla de vóxeles divide el espacio en celdas y conserva un punto representativo por cada celda ocupada. Las celdas más grandes reducen la densidad y el trabajo de procesamiento, pero también pueden debilitar postes delgados, bordes y obstáculos pequeños. La resolución se elige según la geometría que la tarea necesita conservar. Un valor útil para mapear áreas grandes puede no servir para detectar objetos pequeños cercanos.
El preprocesamiento reduce la entrada no deseada y conserva la geometría que se necesita después. Es un diagrama conceptual, no una comparación medida de filtrado.
El movimiento agrega otro problema, porque los puntos de un escaneo pueden tomarse en momentos distintos. Durante un giro, la pose del LiDAR cambia entre la primera y la última muestra. Tratarlas como simultáneas puede deformar una pared plana. La corrección de distorsión (deskewing) usa el tiempo de adquisición de cada punto y el movimiento que entregan la IMU o la odometría para expresar esos puntos en un mismo instante de referencia.
Conservar el tiempo de cada punto prepara ese procesamiento posterior. Que un driver funcione o que se vea la nube no significa que la corrección de distorsión, la odometría LiDAR o el SLAM estén resueltos.
¿Por qué las ruedas y la IMU se necesitan entre sí?
Los encoders entregan una forma directa de observar el giro de las ruedas. Convertir ese giro en movimiento del chasis depende de las dimensiones de la rueda, la trocha, el contacto con el suelo y el patinaje. La IMU observa un proceso físico distinto. El giroscopio mide la velocidad angular y el acelerómetro mide la fuerza específica. Responde rápido, pero el sesgo y el ruido se acumulan cuando se integran las mediciones.
Entender cómo mide cada sensor hace más fácil explicar los beneficios y los límites de la fusión. El material de integración de IMU, GNSS y chasis desarrolla estas entradas antes de pedirle a un filtro que las use.
Las tramas CAN todavía tienen que convertirse en odometría
El curso presenta CAN-FD y muestra un J5011 conectado a un chasis con dos motores DM-H65. Hay que distinguir la capacidad de la interfaz del protocolo del dispositivo conectado. Este ejemplo con DM-H65 usa CAN clásico a 1 Mbit/s, y la configuración de CAN-FD no es intercambiable con ella.
CAN-FD puede llevar hasta 64 bytes de datos por trama y usar una fase de datos más rápida, pero exige dispositivos compatibles y la misma configuración en todo el bus. El cableado, la terminación y la conexión física igual deben revisarse.
Con el servicio del chasis del curso en marcha, se inspecciona la interfaz y se captura de forma pasiva el tráfico existente.
ip -details -statistics link show can0
timeout 4s candump -L can0Una interfaz sana no prueba que la decodificación sea correcta. En el ejemplo del curso, la identidad de cada motor debe leerse de los campos de la carga útil y no deducirse solo del identificador de arbitraje CAN. Hay que revisar el orden de bytes, los valores con signo, los factores de escala y la convención de dirección izquierda y derecha contra el protocolo del dispositivo.
Después de convertir la realimentación de las ruedas en velocidades lineales, un chasis de tracción diferencial sigue estas ecuaciones.
v = (v_right + v_left) / 2
omega = (v_right - v_left) / track_widthVelocidades iguales en las ruedas describen un movimiento recto ideal, y su diferencia produce la rotación. Un error en el radio de la rueda cambia la escala de la distancia, un error en la trocha cambia el giro estimado y el patinaje rompe la relación entre giro y desplazamiento.
El camino completo, entonces, es este.
Decodificación del protocolo → unidades y dirección → cinemática del chasis → marcas de tiempo y covarianza → publicación de la odometría.
Los recursos de SDK y drivers del chasis cubren la integración del lado de los motores. El adaptador de ROS igual debe entregar el contrato de medición nav_msgs/msg/Odometry validado que exige el filtro.
¿Por qué una IMU puede derivar con el robot detenido?
El curso usa la IMU integrada del MID-360 en /livox/imu, con una frecuencia de publicación de referencia de cerca de 200 Hz. Una frecuencia estable sirve, pero no demuestra que los valores describan el movimiento correcto.
Si un giroscopio detenido conserva un sesgo pequeño b, el error del ángulo integrado crece más o menos como b multiplicado por el tiempo transcurrido. Un valor que parece cercano a cero puede producir una deriva de rumbo visible después de varios minutos.
Conviene partir con una grabación con el robot detenido y después girarlo a propósito en una dirección conocida. Hay que revisar rad/s para la velocidad angular, m/s² para la aceleración, los signos esperados y cómo se mapean los ejes del sensor sobre el marco del cuerpo. La convención habitual de ROS para el cuerpo es x hacia adelante, y hacia la izquierda y z hacia arriba. Un montaje distinto o una convención nativa diferente requieren la transformación adecuada.
Primero se establece la interfaz de la IMU y después se evalúan el sesgo, las unidades, las convenciones de ejes y las marcas de tiempo. Este lanzamiento muestra también el tipo de mensaje propio del LiDAR.
Hay que revisar si la aceleración incluye la gravedad y si hay una orientación válida disponible. La compensación de la gravedad depende de la orientación, así que restar un valor fijo a un eje no es una solución general cuando el robot se inclina.
