Verificar la odometria y decidir si se separa en su propio paquete

[mmggjj]

No bloqueante. Después de la puesta en marcha.

En Donatello (star-uma/TFG_MARIA_JOSE) la odometría es un paquete propio (src/odometry, con real_odometry.py). En StarCrawler va dentro de starcrawler_driver.

Sin LiDAR, la odometría de ruedas es la única fuente de posición que va a tener el robot, así que conviene que esté bien y sea fácil de revisar por separado.

Qué hay que hacer

1. Verificar que lo que publica el driver es correcto: /odom coherente con el desplazamiento real, TF bien encadenada (odom -> base_link), y que ros2 topic hz da la frecuencia esperada.
2. Decidir si separarla en su propio paquete, como en Donatello. A favor: se prueba y se sustituye sin tocar el driver, y deja hueco a fusionar una IMU más adelante. En contra: un nodo más y un salto extra de latencia.

Relacionado

La calibración de wheel_radius y track_separation tiene issue propia y es requisito previo: sin esos dos valores medidos, la odometría no puede ser correcta por muy bien escrita que esté.

Criterio de aceptación

Odometría verificada contra desplazamiento medido con cinta métrica, y decisión tomada y anotada sobre separarla o no.

[mmggjj]

Implementado en feature/ros2 (commit 421730c).

Paquete starcrawler_odometry, separado del driver como en Donatello. Lógica en odometry_core.py, sin rclpy, siguiendo la convención del repo.

• 15 tests escritos y ejecutados, los 15 pasan
• Integra por arco de circunferencia, no por Euler: con giros cerrados y dt de 20 ms deriva bastante menos
• Covarianza del yaw alta a propósito — con orugas las bandas deslizan al girar, y cualquier filtro que fusione esto debe ponderarlo bajo
• publish_tf desactivable para cuando haya un filtro que publique la TF

Por defecto usa los valores del CAD (star-uma/SimulacionOrugas): radio de polea 0.0764 m y separación 0.524 m. El radio efectivo con la banda tensada no es el geométrico, así que sigue pendiente afinarlo rodando — eso es la #13.