Coche RBCar Caddy AI2 CONTEXTO DE PARTIDA Este es el modelo antiguo del RBCar de Robotnik. Este fue adquirido ya hace unos años por el AI2 para los proyectos IDEMOV, IDECONA IDECONA AI2 . El grupo de trabajo  CO3 UPV ahora ha heredado este coche. Como venía diciendo, este prototipo se hereda de un proyecto anterior:  IDECONA AI2 , os recomiendo ver el material  Multimedia - IDECONA AI2 . El coche tiene una compleja y no demasiado documentada información sobre como es el cableado, esquemas eléctricos, etc... A nivel software funciona actualmente con una versión obsoleta de ROS 1 Indigo Igloo con Ubuntu 14 (sin parche del tiempo de real - PREEMPT RT). La intención es actualizar el coche adaptando las piezas de hardware y software necesarias para tener un coche con la versión actual de ROS 2 y Ubuntu con PREEMPT RT. Partimos de la base de software Tenemos los repositorios de código de Robotnik y otros extraídos de un backup de código del workspace del robot: https://github.com/racarla96/ros1_caddy_ai2_rbcar_sim https://github.com/racarla96/ros1_caddy_ai2_rbcar_common https://github.com/racarla96/ros1_caddy_ai2_robotnik_sensors https://github.com/racarla96/ros1_caddy_ai2_rbcar_robot  (rescatado del coche, muy importante) De estos paquetes, se han eliminado las ramas de ROS posteriores a indigo-devel, porque corresponden al nuevo modelo de Robotnik, conservando sólo la rama de indigo-devel. ESQUEMA ELÉCTRICO GENERAL Esquema general a groso modo del vehículo. Explicar cada bloque. NOTA: Queda pendiente asegurarse que mientras el vehículo se carga, no hay voltaje a partir del interruptor porque por el ciclo de carga de batería los voltajes que inyecta son altos (matizar ese rango) y hay que evitar tener el vehículo encendido, por seguridad. IDEA: Si   se planteará en un futuro cambiar la batería actual por una de otra tecnología, habría que considerar el rango al que trabaje la nueva batería, entorno a los 48V. ESQUEMA GENERAL INFORMÁTICO SISTEMA OPERATIVO Ubuntu 24.04 LTS + KERNEL 6.12 LTS + PARCHE PREEMPT RT Nota: No hay soporte de los drivers de NVIDIA con el PARCHE PREEMPT RT para instalaciones comunes, si la hay para la serie de ordenadores JETSON. Aunque con suerte se puede instalar sin problemas. Batería y su mantenimiento Mantenimientos 02/04/2024 (Mantenimiento realizado) 18/07/2024 (Comprobación - mantenimiento no requerido) 26/09/2024 (Comprobación - mantenimiento no requerido) Último mantenimiento: 02/04/2024 Configuración de la batería Configuración en SERIE Anteriormente tenía 8 baterías: Baterías Trojan T-125 6V 240 Ah Actualmente tiene 8 baterías: Baterías Trojan T-105 6V 225 Ah Justificación de compra: Compatibilidad con la anteriores baterías Facilidad en la gestión y compra Pequeña reducción de capacidad Carga Frecuencia de carga sin uso: Cada mes, mes y medio. Tiempo de carga: De 2 a 4 horas de carga. Por batería: Voltaje mínimo: 6V Voltaje máximo: 6.3V LOTE de 8 baterías: Voltaje mínimo: 48V Voltaje máximo: 50.4V Cargador: Tebetron 48V 30A   Conectores REMA Macho Ubicado en el cargador Hembra  Ubicado en el vehículo ¿Cómo hacer el mantenimiento de la batería? Componentes necesarios Agua destilada Jeringuilla Gafas de protección Guantes no permeables (por ejemplo, nitrilo, como en la imagen inferior) Linterna (para mirar el nivel) Frecuencia de rellenado cada 2/3 meses Procedimiento Ponerse los guantes y gafas. Tener cuidado con una posibles salpicaduras. Que cubra el agua destilada un poco por encima de las placas de la batería, no llenar hasta arriba, con que las placas no estén al aire es suficiente, ayudarse de la jeringuilla para el rellanado. Precaución con el fuego porque las baterías liberan hidrógeno durante le carga. Evitar a toda costa que haya elementos que generen ignición. Sin chispas ni llamas. Video de Youtube con el procedimiento Sistema de dirección Esquema Electrónica La electrónica del sistema de dirección está ubicado en la parte frontal del vehículo. Como podemos observar, se encuentra dentro de la caja metálica indicada en la imagen. La caja del steering controller tiene varios cables de entrada y salida estos se resumen en 4 grupos: Grupo 1: Encoder Motor DC (Bristish Encoder Product Company Modelo 15/T/HV PPR 1000) Grupo 2: Motor DC (Koyo Seiko NO 45262??8) Grupo 3: 48V Filtrados 24V Cable RS-232 configuración del driver (CONECTOR DB9 - PIN 3 RX VERDE, PIN 2 AMARILLO, PIN 5 GND MARRÓN) Grupo 4: Cable BUS CAN Encoder Dirección Endstops Dirección (para limitar el rango de la dirección) Grupo 1 y 2 actuan en conjunto: Motor DC Koyo Seiko NO 45262??8 Encoder Motor DC Bristish Encoder Products Company Modelo 15/T/HV PPR 1000 Cableado: BLACK 0 Volts (GND) WHITE VCC (+5V) BROWN CH A RED CH B ORANGE CH Z YELLOW CH -A GREEN CH -B BLUE CH -Z SCREEN CASE GROUND Grupo 4 : ENDSTOP DIRECCIÓN  DERECHA GND NONE (NC) RIGHT ROJO (NO) IZQUIERDA  GND NONE (NC) LEFT AMARILLO (NO) ENCODER CAN DIRECCIÓN  Bristish Encoder Products Company Modelo SA36H Single Turn Absolute (01 o 04) POR CONFIRMAR SF 12-V3-P1-C1-A EMK NEGRO GND BLANCO VCC (12V o 24V) Lo más seguro 24V AMARILLO CAN H (CNH) BUS CAN CONECTOR NEGRO TRASERO  VERDE CAN L (CNL) BUS CAN CONECTOR NEGRO TRASERO MARRÓN GND CAN (GNDI) BUS CAN CONECTOR NEGRO TRASERO CONTROLADOR DIRECCIÓN DZCANTE-020L080 MA MOT DC DIR + (ROJO) MB NONE MC MOT DC DIR - (NEGRO) GND NONE GND GND 48V FILT (NEGRO) HVIN POS 48V FILT (ROJO) GND VOUT- TRACO DC-DC 5V 5VIN VOUT+ TRACO DC-DC 5V GND NONE PAI1- NONE PAI1 NONE GND DB9 RS-232 (MARRÓN) PIN 5 GND PDO1 NONE PDO2 NONE PDO3 NONE GND NONE PDI1 NONE PDI2 END STOP DIR LEFT (AMARILLO) PDI3 END STOP DIR RIGHT (ROJO) GND END STOP DIR GND (AZUL Y MARRÓN) PDI4- NONE PDI4 NONE PDI5- NONE PDI5 NONE RX DB9 RS-232 (VERDE) PIN 3 RX TX DB9 RS-232 (AMARILLO) PIN 2 TX GNDI (CAN GND) ENC CAN DIR GND (MARRÓN) + CABLE COM CAN CONECTOR NEGRO TRASERO CNL (CAN L) ENC CAN DIR CAN L (VERDE) + CABLE COM CAN CONECTOR NEGRO TRASERO CNH (CAN H ENC CAN DIR CAN H (AMARILLO) + CABLE COM CAN CONECTOR NEGRO TRASERO H-A NONE H-B NONE H-C NONE ENI- ENC MOT DC - CH -Z (AZUL) ENI ENC MOT DC - CH Z (NARANJA) ENB- ENC MOT DC - CH -B (VERDE) ENB ENC MOT DC - CH B (ROJO) ENA- ENC MOT DC - CH -A (AMARILLO) ENA ENC MOT DC - CH A (MARRÓN) GND ENC MOT DC - GND (NEGRO) 5V-O ENC MOT DC - VCC (5V) (BLANCO) CONVERTIDOR DC-DC Modelo TRACO POWER TEN 15-2411WI Este controlador también necesita un convertidor DC-DC para ser alimentado a 5V, este está alimentado a los 24V que entran en la caja y está conectado a la entrada 5IN y GND. Introducción Conversión del proyecto de ROS 1 a ROS 2 Análisis inicial del proyecto rbcar_steering_controller (enfoque hardware) A alto nivel, este paquete ROS controla el giro (steering) de un vehículo (Rbcar) usando: Un variador/drive de motor (AMC DZCANTE-020L080) controlado por CANopen para mover el actuador de dirección en modo posición. Un encoder absoluto EPC (familia MA) conectado también por CANopen para medir el ángulo real de la dirección. Una tarjeta CAN PEAK (PCAN) como interfaz física con el bus CAN. A continuación desgloso los bloques de hardware y cómo se integran: 1) Bus CAN y hardware de comunicaciones Interfaz: PEAK PCAN (usuarios típicamente PCAN-PCI, PCAN-USB, etc.). En el launch se usa el dispositivo “/dev/pcanpci1”; por defecto en código “/dev/pcan32”. Velocidad: 1 Mbit/s (CAN_BAUD_1M). Librerías: libpcan (PCan.h/PCan.cc) para abrir y configurar el canal, y enviar/recibir tramas CAN. Protocolo: CANopen “ligero” implementado manualmente, sin stack externo. Se envían NMT (Start, Stop, Reset Comm/Node), SDO (objetos de configuración/lectura) y PDOs (tramas de proceso). Mecanismo de supervisión: Node Guard/Heartbeat (cíclicamente se lanza un RTR a 0x700+NodeID y se comprueba el estado; si no hay respuesta dentro de NMT_TIMEOUT=2s se considera fallo de comunicación). 2) Drive de motor: AMC DZCANTE-020L080 Función: accionar el actuador de dirección en modo posición (Position Mode). Nodo CAN: ID configurable (por defecto can_motor_id=1). Clase base Dzcante020l080 .* encapsula objetos CAN (índices SDO/PDO) para este drive: ControlWord (0x6040) con comandos: ENABLE_OP, SHUTDOWN, SWITCH_ON, QUICK_STOP, DISABLE_VOLT, RESET. Modos de operación (0x6060) = Position/Velocity/Home. RPDO y TPDO: configuración de COB-IDs y modos de transmisión (objetos 0x140x/0x180x y similares). Lecturas: StatusWord (0x6041), Drive Status extendido (0x2002 subíndices 1..6), posición (0x6064), velocidad (0x60FF), corriente (0x6077), tensión bus DC (0x200F.01). Clase MotorDrive .* añade: State machine interna (INIT/READY/EMERGENCY...) y comunicación (OPERATIONAL/FAULT...). Hilos auxiliares: ControlCommunicationThread: envía Node Guard y vigila tiempos para marcar FAULT si no hay respuesta. ReadSDOMessagesThread: lectura cíclica de Drive Status, tensión del bus, entradas digitales, posición actual, etc., y cálculo de medias. Configuración CAN: Reset/Preoperational, setting de Node Guard (Guard Time 0x100C, Life Factor 0x100D), Event Action (0x2065.21), Recovery Time, TPDOs/RPDOs para posición/velocidad. Gestión de estados de variador: dsDesiredStatus vs dsStatus. Cambia de estados enviando ControlWord con tiempos de guarda. Señales de diagnóstico: descompone StatusWord y 0x2002.* en flags con máscaras y temporizadores para logging-control. Clase MotorPosition .* especializa a Position Mode: Inicialización: secuencia ControlWord (Disable Voltage, Shutdown, Switch On, Enable Operation) y lectura de modo operación. Homing: soportado (START_HOME / STOP_HOME), flags de homing completo y cambio a modo posición. SetMotorPosition: envía objetivo vía RPDO21 (POSITION_PDO_MSG) en cuentas (counts). 3) Encoder absoluto EPC (familia MA) por CANopen Función: medir posición de la dirección en cuentas absolutas. Nodo CAN: por defecto can_encoder_id=0x7F. Clase EpcMaCanOpen .* maneja NMT/SDO/PDO básicos para estos encoders (IDs TPDO1 0x180+ID, TPDO2 0x280+ID). Clase EpcEncoder .*: State machine similar (OPERATIONAL/FAULT...). Hilo de comunicación para Node Guard. Procesa TPDO1/TPDO2 con cuentas del encoder (encoder_counts). El nodo de alto nivel convierte estas cuentas a ángulo mediante una calibración lineal. 4) Nodo ROS de control de dirección Binario: rbcar_steering_controller.cpp. Flujos: Parametrización vía ROS params y YAML (config/config.yaml): rangos de encoder, zero, resolución, calibración lineal (y=Ax+B), límites angulares y puntos extremos. Inicializa PCan (a 1M), crea objetos MotorPosition (drive) y EpcEncoder (encoder) con sus IDs y desired_freq (50 Hz). start(): Setup y Start de ambos (abre CAN, setea, pone OPERATIONAL, lanza hilos). Loop spin(): a 50 Hz: Envío SYNC (0x80). Lectura de hasta 100 mensajes CAN y dispatch a Motor/Encoder para proceso (PDO/SDO/NMT/EMCY). Publicación del estado: SteeringControllerStatus (estado motor+encoder, cuentas abs y motor, posición angular). Suscripciones: command_position_counts (std_msgs/Int32): manda counts al motor (posición absoluta en cuentas del motor). command_angle (std_msgs/Float64): convierte ángulo deseado a cuentas absolutas y luego a cuentas de motor según relación abs_to_motor, y envía referencia de posición al drive. Servicio: set_motor_status (SetMotorStatus.srv): permite fijar estado del drive: OPERATION_ENABLED, QUICK_STOP, READY_TO_SWITCH_ON. Diagnósticos: diagnostic_updater reporta estado de comunicación y estado del drive, y supervisa frecuencia de comandos. Qué tener en cuenta para replicar: Calibración mecánica : el YAML aporta relación entre encoder absoluto y cuentas del motor, y los extremos físicos. Esto es clave para que el comando en rad -> counts funcione correctamente. La variable abs_to_motor se calcula como motor_counts_range / abs_counts_range. Debes medir ambos rangos en tu mecánica y actualizar config.yaml. value_calibrate_a y value_calibrate_b definen la recta ángulo = -a*counts + b. Ajustarlos a tu encoder y cinemática. Límites de ángulo: extrem_angle_left/right y sus points asociados (extrem_points_left/right) fijan saturaciones de seguridad. 5) Resumen de la secuencia de arranque/operación PCan abre el dispositivo y configura el bitrate. MotorDrive: Reset CAN Comm -> Preoperational Configura PDOs/Node Guard/Eventos Init drive (ControlWord sequence), lee modo operación Start Communication (NMT Start), pasa a OPERATIONAL Lanza hilos de Node Guard y lecturas SDO periódicas EpcEncoder: Reset/Preoperational (En este código no reconfigura PDOs del encoder) Start Communication a OPERATIONAL Lanza hilo de Node Guard Bucle 50 Hz: Envía SYNC Lee paquetes CAN y los distribuye Publica estado (counts + angle) Comandos: command_angle -> se traduce a counts del encoder y luego a counts del motor y se envía la posición al drive por RPDO21. 6) Señales CAN-clave y mapeo rápido NMT (ID 0x000): Start 0x01, Stop 0x02, Reset Comm 0x82, Reset Node 0x81, Preop 0x80 (DATA[0]=cmd, DATA[1]=node). Node Guard RTR a 0x700+NodeID, respuesta en 0x700+NodeID con estado (OPERATIONAL=0x05/0x85, PREOP=0x7F/0xFF, STOPPED=0x04/0x84). SYNC: 0x80 sin datos. Drive: SDO server 0x600+ID (Write/Read a objetos 0x6040 ControlWord, 0x6060 Mode, 0x607A Position, 0x60FF Velocity, 0x2002 Drive Status, 0x200F.01 DC Bus, 0x6064 Position actual). RPDO21 (0x280+ID) para consigna de posición (4 bytes little-endian). TPDO1/21/22 para StatusWord/Position/Velocity según configuración. Encoder EPC: TPDO1 (0x180+ID) / TPDO2 (0x280+ID): se usan los 2 bytes bajos como cuentas (el código así lo interpreta). Node Guard/Heartbeat igual que el drive. 7) Qué adaptar en tu nuevo proyecto (hardware) Si cambias: Interfaz CAN: sustituye PCan.* por tu driver y conserva la API Send/Read/Setup/Configure. Drive: si el drive no es AMC DZCANTE-020L080, necesitarás: Revisar/actualizar índices SDO, COB-IDs, TPDO/RPDO, escalados, y status words. Ajustar secuencias de ControlWord y modos de operación. Encoder absoluto: si otro fabricante/protocolo, cambiar mapeo de TPDOs y cómo se extraen cuentas. Mecánica: recalibrar config.yaml para rangos, cero y linealización ángulo–cuentas. Mantener: Supervisión de comunicación (Node Guard/Heartbeat) o migrar a Heartbeat puro si tus nodos no usan Node Guard clásico. Seguridad: QUICK_STOP y manejo de fallos del drive.   Sistema de tracción Introducción El caddy eléctrico está equipado con un sistema de control en velocidad y tracción que garantiza un rendimiento confiable y eficiente. El corazón del sistema de control es un  Curtis Controller 1234 , reconocido por su fiabilidad y precisión en la gestión de la potencia entregada al motor.  Este controlador permite dos modos de funcionamiento: manual mediante pedal  o automático , adaptándose a diferentes necesidades de conducción. El modo automático funciona a través de su comunicación CAN bus, que asegura una integración sencilla y robusta con otros sistemas electrónicos. Por su parte, el sistema de tracción está impulsado por un motor eléctrico de 3.3 kW y 4800 rpm , el cual proporciona la potencia suficiente para mover el caddy con soltura, incluso en terrenos inclinados o con carga adicional. Esta combinación permite alcanzar un equilibrio óptimo entre eficiencia energética y desempeño, convirtiéndolo en una solución práctica y sostenible para el transporte en campos de golf, resorts o áreas residenciales. En resumen, el controlador Curtis 1234 y el motor de 3.3 kW , junto con su doble modo de operación y conectividad CAN, hacen del caddy un vehículo versátil, confiable y de bajo mantenimiento , con una excelente relación entre potencia y eficiencia. Paquete de ROS 2 Repositorio caddy_ai2_ros2_control_hardware_curtis_motor_driver: El repositorio caddy_ai2_ros2_control_hardware_curtis_motor_driver implementa la integración de un driver para motor Curtis dentro de la arquitectura ROS 2 control, permitiendo gestionar un caddy eléctrico (carrito de golf) desde un sistema robótico. La comunicación con el motor se realiza a través de CAN bus (Controller Area Network), lo que asegura robustez y fiabilidad en la transmisión de comandos. El sistema está diseñado para trabajar con una frecuencia de control de 25 Hz, garantizando un comportamiento estable en tiempo real. Entre sus características principales se encuentran: Interfaz Hardware en ROS 2: el repositorio define un hardware interface plugin capaz de interactuar con el controlador Curtis, permitiendo la publicación y recepción de comandos de velocidad. Soporte para CAN en Linux: incluye instrucciones para configurar interfaces USB-to-CAN, crear interfaces virtuales (vcan), y gestionar permisos via /etc/sudoers o grupos de usuario. Dependencias clave: libsocketcan y libsocketcanpp para manejar la comunicación CAN en C++. can-utils, herramienta común en Linux para monitoreo y pruebas sobre buses CAN. Soporte específico para el adaptador Ixxat USB-to-CAN V2 compact. Facilidad de prueba: se pueden crear interfaces virtuales (vcan_motor_drv o vcan_steer_drv) para simular el bus y publicar comandos con ROS 2 sin necesidad de hardware físico. Gestión en ROS 2: el driver se lanza como un controller dentro de ros2_control y permite enviar comandos, por ejemplo: En conjunto, este stack permite controlar el motor eléctrico de 3.3 kW del caddy a través del controlador Curtis 1234, gestionando modos de operación y facilitando la integración con arquitecturas robóticas modernas. Análisis software del sistema de tracción con ROS 1 https://github.com/racarla96/ros1_caddy_ai2_rbcar_robot/tree/indigo-devel/curtis_motordrive A continuación se presenta un análisis general del código contenido en el archivo curtis_controller.cpp del paquete curtis_controller , que forma parte del sistema de control para un motor drive basado en ROS: 1. Arquitectura General y Objetivos Propósito: El controlador ( CurtisController ) se encarga de gestionar la comunicación entre la red CAN y el sistema ROS para controlar un motor (o conjunto de motores) de la plataforma. Esto incluye la recepción de comandos (ya sea de tipo “throttle” o “twist”), la lectura de datos desde el bus CAN y la publicación del estado del sistema. Componentes Clave: Interfaz CAN: Se utiliza un objeto PCan (representado por can_dev ) para la comunicación con el bus CAN. Control del Motor: El objeto MasterDrive se encarga de enviar comandos de aceleración (throttle) y de procesar los mensajes CAN que provienen del drive. Integración ROS: Publicadores: Publica el estado general en el topic "state" y datos específicos del drive en "master_drive" y "slave_drive" . Suscriptores: Se suscribe a comandos de control (por ejemplo, "command_throttle" o "command_twist" ) dependiendo del modo configurado. Servicios: Posee un servicio para resetear el controlador. 2. Máquina de Estados El funcionamiento central del controlador se organiza en una máquina de estados implementada en el método controlLoop() , la cual revisa el valor de la variable state y ejecuta la función correspondiente. Los estados son definidos mediante constantes (probablemente en el paquete robotnik_msgs::State ): INIT_STATE: Función: initState() Acción: Llama a setup() para inicializar los subcomponentes (CAN, drive, etc.). Transición: Si la inicialización es exitosa, cambia al estado READY_STATE . STANDBY_STATE: Función: standbyState() Acción: Se enfoca en la lectura de mensajes del bus CAN (llamando a readCANMessages() ), pero sin enviar comandos de throttle. READY_STATE: Función: readyState() Acción: Lee mensajes CAN y, en base a ellos, gestiona la comunicación con el drive. Verifica condiciones de seguridad, como la existencia de la interlock. Envía el valor de aceleración (throttle) a través de master_drive->sendThrottle() , aplicando límites para evitar exceder el rango permitido. Control de Fallos: Si falla la lectura de mensajes CAN o se detecta un error al enviar el throttle, se transita a FAILURE_STATE . FAILURE_STATE: Función: failureState() Acción: Permite una recuperación tras un tiempo predefinido (controlado por failure_recover_time ). Se intenta reinicializar el sistema, y si tiene éxito, se cambia a READY_STATE . SHUTDOWN_STATE: Función: shutdownState() Acción: Ejecuta el proceso de apagado ( shutdown() ) de los dispositivos y transita de vuelta al estado INIT_STATE . EMERGENCY_STATE: Función: emergencyState() Acción: Actualmente se define pero sin implementación. Se reserva para tratar situaciones de emergencia. 3. Flujo de Ejecución y Control Inicio y Bucle de Control: El método start() configura ROS (llamando a rosSetup() ), activa la bandera running y ejecuta el controlLoop() , el cual se ejecuta a una frecuencia determinada ( desired_freq_ ) leída desde el servidor de parámetros o con un valor por defecto. Control Loop: Dentro de este ciclo: Se registra el tiempo para calcular la frecuencia real de ejecución. Se ejecuta el bloque correspondiente al estado actual (con switch(state) ). Se llaman a funciones comunes en todas las iteraciones a través de allState() , que entre otras cosas, implementa un watchdog (para poner a cero el throttle si no se reciben comandos en un tiempo determinado) y publica el estado a ROS. Detección y Procesamiento de Mensajes CAN: El método readCANMessages() intenta leer varios mensajes (en un bucle) del bus CAN y, para cada mensaje leído, llama a master_drive->processCANMessage() . Esto es fundamental para actualizar el estado del drive (por ejemplo, datos de velocidad, fault codes, interlock, etc.). 4. Interacción mediante ROS Suscriptores: Dependiendo del modo configurado (definido en el parámetro "mode" ), se suscribe a: "command_throttle" : Para recibir comandos de aceleración directa. "command_twist" : Para recibir comandos en forma de twist (probablemente para convertir velocidad lineal y angular a un comando de throttle). Publicadores: Estado del Controlador: Publica un mensaje del tipo robotnik_msgs::State que incluye el estado actual, la frecuencia deseada y la real, así como una descripción en cadena del estado. Datos del Motor: Publica datos específicos de la conducción (por ejemplo, velocidad, interlock, fallos) en dos topics: "master_drive" y "slave_drive" con mensajes del tipo curtis_msgs::DriveData . Servicio de Reset: Se implementa un servicio denominado "reset" que permite reiniciar el controlador (a través de la función resetSrv ). 5. Gestión de Errores y Seguridad Watchdog: En el método allState() , se monitoriza el tiempo desde el último comando recibido. Si se supera un tiempo límite ( WATCHDOG_TIMEOUT ), se fuerza la reducción del throttle a cero para evitar movimientos inesperados. Control de Interlock: El sistema verifica constantemente el estado del interlock: Si no está activado, se establece el throttle deseado a cero para prevenir el funcionamiento sin la debida seguridad. Se detecta la transición en el interlock (por ejemplo, cuando se recupera) y se emiten mensajes de advertencia. Transiciones por Error: Si se producen errores en la lectura de mensajes CAN o en el envío de comandos a través del drive, el sistema transita al estado FAILURE_STATE y posteriormente intenta una recuperación. Conclusión El código del CurtisController está organizado de forma modular y robusta, utilizando una máquina de estados que permite gestionar de manera clara las diferentes fases de la operación: Inicialización y Configuración (INIT_STATE y rosSetup): Se leen parámetros, se configuran los dispositivos CAN y se preparan los publishers/subscribers de ROS. Operación Normal (READY_STATE): Se realizan lecturas y escrituras constantes sobre el bus CAN, se envían comandos al drive y se publica el estado. Gestión de Fallos (FAILURE_STATE y EMERGENCY_STATE): Se implementa una estrategia para detectar fallos y recuperar el control tras un tiempo de espera. Apagado Seguro (SHUTDOWN_STATE): Se asegura la liberación de recursos y se prepara el sistema para una nueva inicialización. En resumen, se trata de un controlador para sistemas embebidos en robótica que integra comunicación a bajo nivel (CAN) con la capa de mensajería y servicios de ROS, siguiendo un patrón basado en estados que facilita tanto la operación normal como el manejo de situaciones de error o emergencia. Sensores SBG IG-500N GPS Aided AHRS El  IG-500N  es un sistema de referencia de actitud y rumbo (AHRS - Attitude and Heading Reference System) mejorado con GPS, compacto y de alta precisión, diseñado para entornos dinámicos exigentes. Con su  Unidad de Medición Inercial (IMU) basada en MEMS ,  receptor GPS  y  sensor de presión , el dispositivo garantiza datos de orientación y posición  precisos y sin deriva . Sobresale en escenarios que requieren un seguimiento preciso durante maniobras intensas de alta G, gracias a sus características avanzadas. Características principales: Filtro de Kalman Extendido  (EKF): Este algoritmo en tiempo real mejora la precisión al integrar los datos de los sensores para proporcionar mediciones exactas de orientación, posición y velocidad, incluso bajo movimientos rápidos, con una frecuencia de actualización de hasta  100 Hz . Precisión Dinámica : Gracias a su EKF y receptor GPS, el IG-500N elimina las aceleraciones transitorias, mejorando la precisión de actitud en comparación con los sistemas AHRS tradicionales. Aplicaciones Versátiles : La función "Perfil de Movimiento" permite una configuración sencilla, adaptando el sistema para diversas aplicaciones y asegurando configuraciones adecuadas de los sensores para cada caso de uso. (No está disponible) Datos de Salida : Orientación 3D  (Ángulos de Euler, Matriz o Cuaternión) Posición y Velocidad 3D Medición de Heave - Usado en aplicaciones marítimas Datos de Sensores Calibrados  (Aceleración, Velocidad de Rotación, Campo Magnético, Temperatura) Ángulo Delta Datos Brutos del Sensor y GPS Presión y Altitud Barométrica Información GPS Avanzada Información de Tiempo Referida a UTC Estas características hacen que el IG-500N sea una solución ideal para aplicaciones que requieren un seguimiento preciso de actitud, rumbo y posición en condiciones dinámicas y de alta velocidad. Repositorio de código de ROS 2 Humble para el uso del sensor https://github.com/racarla96/caddy_ai2_ros2_control_sensors_SBG_IG-500N Características SBG IG-500N-G4A2P1-B - G4 -> 300 º/s - A2 -> +-2g - P1 -> RS-232 (USB) - B -> Box version, no sync Github - Manual https://control.ros.org/jazzy/doc/ros2_controllers/gps_sensor_broadcaster/doc/userdoc.html https://control.ros.org/jazzy/doc/ros2_controllers/imu_sensor_broadcaster/doc/userdoc.html https://github.com/ros-controls/ros2_control_demos/blob/jazzy/example_5/doc/userdoc.rst https://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/Imu.html https://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/NavSatFix.html   Comunicaciones CAN - Introducción El coche tiene dos subsistemas que reciben acciones de control y dan feedback de su estado: Sistema de tracción Sistema de dirección CAN - Sistema de tracción Cómo bien hemos expresado en la introducción, el sistema de tracción se controla mediante CAN.  Este código está procesando mensajes de una red CAN en un sistema llamado MasterDrive , donde se manejan distintos PDOs (Process Data Objects) para la comunicación entre un Master , un Slave y una Computadora . 📌 ¿Qué significan las constantes? Las constantes como PDO1_MISO_MtoC y PDO1_MOSI_MtoS representan los identificadores CAN ID de los mensajes en la red. Estas son definiciones de valores hexadecimales que indican qué tipo de mensaje es cada uno. Constante ID (Hex) ID (Decimal) Significado PDO1_MISO_MtoC 0x1A6 422 Master → Computer (Datos de corriente, voltaje, batería) PDO1_MOSI_MtoS 0x227 551 Master → Slave (Comandos de control) PDO2_MISO_MtoC 0x2A6 678 Master → Computer (Datos de velocidad, temperatura) PDO2_MISO_StoC 0x2A7 679 Slave → Computer (Temperatura y corriente del Slave) PDO1_MISO_StoM 0x1A7 423 Slave → Master (Estados y fallas del Slave) PDO1_MOSI_CtoM 0x226 550 Computer → Master (Acción de control Accelerador)   candump-2025-02-13_124653_conector_rojo.log CAN - Herramientas https://github.com/linux-can/can-utils https://mintonperformance.com/blogs/controller-area-networking/setup-and-installation-of-can-utils-on-linux-2022-update?srsltid=AfmBOoqO-Zz8XW9iiHUu_DC6VKThbfrxMTdchiCR2tbKv1svMpi2Hj2f CAN - Bibliografía Tutoriales: Blog - mbedded.ninja - How To Use SocketCAN With The Command-Line In Linux -  https://blog.mbedded.ninja/programming/operating-systems/linux/how-to-use-socketcan-with-the-command-line-in-linux/ Blog - mbedded.ninja - How To Use SocketCAN With C++ In Linux https://blog.mbedded.ninja/programming/operating-systems/linux/how-to-use-socketcan-with-c-in-linux/ Parte eléctrica y electrónica Curtis Controller 1234 PIN CABLE - COLOR FUNCIÓN SALIDA 1 AMARILLO KSI 2 VERDE PROP. DRIVER 3 - DRIVER 4 4 MARRÓN DRIVER 3 5 - DRIVER 2 6 AZUL DRIVER 1 7 MARRÓN I/O GROUND 8 ROJO SWITCH 2 ANALOG 2 9 AMARILLO SWITCH 3 INTERLOCK NECESARIO HABILITAR Y DESHABILITAR ENTRE CAMBIO DE MODO MANUAL / AUTOMÁTICO 10 BLANCO-AMARILLENTO SWITCH 4 MODO MANUAL (0V - OFF) MODO AUTO        (24V - ON) 11 - SWITCH 5 12 AZUL SWITCH 6 13 AMARILLO COIL RETURN 14 - SWITCH 16 DNC 15 VERDE THROTTLE POT HIGH 16 AZUL-BLANCO THROTTLE POT WIPER CONECTOR NEGRO 3 PINES (CENTRO) (NEGRO,AZUL-BLANCO,VERDE) 17 - POT2 WIPER 18 NEGRO POT  LOW 19 - DIGITAL OUT 6 20 AZUL-BLANCO DIGITAL OUT 7 FUNCIÓN DESCONOCIDA 21 - CAN TERM H 22 AZUL-BLANCO SWITCH 7 +24V ON -> IR HACÍA DELANTE 23 AMARILLO CANH 24 - SWITCH 1 ANALOG 1 25 AMARILLO +12V OUT 26 AMARILLO +5V OUT 27 - POT2 HIGH 28 VERDE SERIAL TX 29 NEGRO SERIAL RX 30 - ANALOG OUTPUT 31 AZUL-BLANCO ENCODER A 32 AZUL ENCODER B 33 VERDE SWITCH 8 +24V ON -> IR HACÍA ATRÁS 34 - CAN TERM L 35 VERDE CANL PIN 31 Resistencia Pull UP Donde el VCC son 12V del pin 25 y una resistencia de Pull up de 5.2K y la toma de tierra se sustituye por donde vendría la señal del encoder A. Esto porque la entrada va conectada a la pantalla Engage IV, a modo de sensor de Speedometer. Curtis Engage IV 1 Rojo, 2 Common, 3 Amarillo-Verde, 5 Encoder A, 13 Amarillo-Verde, 14 Blanco amarillento, 19 Amarillo-Verde Todo apunta que la señal del pin 14 debe estar conectada con el controlador Curtis, no sé con qué fin... Imagino que para saber si está presente o lo lo está. Está también va conectada al botón de manual y automático. PLC Schneider TM241 - Entradas y Salidas Entradas Nombre Función Salidas Nombre Función Voltage I0 Q0 INTERLOCK 24V I1 Q1 MODO AUTO/MANUAL 24V I2 Q2 24V I3 Q3 24V I4 Q4 24V I5 Q5 24V I6 Q6 24V I7 Q7 24V I8 Q8 BRAKING BEAM LUZ DE FRENO 13.5V I9 Q9 REVERSE  BEAM LUZ DE MARCHA ATRÁS 13.5V I10 Q10 REAR STATIC BEAM LUZ TRASERA DE POSICIÓN 13.5V I11 Q11 HIGH BEAM LUZ LARGA 13.5V I12 Q12 LOW BEAM LUZ CORTA 13.5V I13 Q13 FRONT STATIC BEAM LUZ DELANTERA DE POSICIÓN 13.5V I14 Q14 RIGHT BLINKER BEAM INTERMITENTE DERECHO 13.5V I15 Q15 LEFT BLINKER BEAM INTERMITENTE IZQUIERDO 13.5V (*) Sabemos que las luces en inglés no todas se escriben así tal cual, pero por agrupar con un sustantivo todo el conjunto de luces con el mismo sustantivo como es BEAM. Información del driver Curtis 1234 TODO  Datasheet + Programa + Foto del cable Información del motor https://www.letrika.mahle.com/katalog/letrikaletrika.html?lang=E&tab=0&koda=IM7027 Bloque Motor Esquema mecánico - DINÁMICA DE LA TRANSMISIÓN Esquema eléctrico Esquema de la red de comunicaciones ESPECIFICACIONES FÍSICAS Arquitectura Cuadro de instrumentos FRENO DE MANO El freno de mano es un freno de tipo palanca. A nivel electrónico, podemos conocer su estado mediante un botón que actúa como interruptor, visible en la imagen. Cuando la palanca está arriba (freno activado), el interruptor está cerrado ; cuando la palanca está abajo (freno desactivado), el interruptor está abierto .   Activado (Arriba) - Interruptor Cerrado Desactivado (abajo)  - Interruptor Abierto Glosario de términos ACC : Adaptative Cruise Control - Control de crucero adaptativo" Un sistema de control de crucero para vehículos que controla la velocidad longitudinal. El ACC puede mantener una velocidad de referencia deseada o ajustar su velocidad en consecuencia para mantener distancias de conducción seguras con otros vehículos. EGO Término para expresar la noción de uno mismo, que se utiliza para referirse al vehículo que se controla de forma autónoma, por oposición a otros vehículos u objetos de la escena. Se utiliza con mayor frecuencia en la forma ego-vehículo, que significa el vehículo autónomo. AMFE : Análisis Modal de Fallos y Efectos -  FMEA  Failure mode and effects analysis Un enfoque ascendente del análisis de fallos que examina las causas individuales y determina sus efectos en el sistema de nivel superior. GNSS : Sistema Mundial de Navegación por Satélite - Global Navigation Satellite System Término genérico para todos los sistemas por satélite que proporcionan una estimación de la posición. El Sistema de Posicionamiento Global (GPS - Global Positioning System) fabricado por Estados Unidos es un tipo de GNSS. Otro ejemplo es el GLONASS (Globalnaya Navigazionnaya Sputnikovaya Sistema) de fabricación rusa. Otro ejemplo es el Galileo "es el sistema paneuropeo de radionavegación y posicionamiento por satélite desarrollado por la Agencia Espacial Europea (ESA) y financiado por la Comisión Europea". AFO - HAZOP : Análisis Funcional de Operatividad - Estudio de peligros y operabilidad - Hazard and Operability Study Una variación del AMFE (Análisis Modal de Fallos y Efectos) que utiliza palabras guía para hacer una lluvia de ideas sobre conjuntos de posibles fallos que pueden surgir. IMU : Unidad de medición inercial - Inertial Measurement Unit Dispositivo sensor compuesto por un acelerómetro y un giroscopio. La IMU se utiliza para medir la aceleración y la velocidad angular del vehículo, y sus datos pueden fusionarse con otros sensores para la estimación del estado. AHRS : Sistemas de Referencia de Actitud y Rumbo - Attitude and Heading Reference Systems Son un conjunto de distintos sensores tridimensionales que proporcionan información acerca del rumbo, la actitud, y la guiñada de una aeronave o vehículo. LIDAR : Light Detection and Ranging o Laser Imaging Detection and Ranging Tipo de sensor que detecta el alcance transmitiendo luz y midiendo el tiempo de retorno y los desplazamientos de la señal reflejada. LTI : Sistema Lineal e Invariante en el Tiempo - Linear Time-Invariant System Un sistema lineal cuya dinámica no cambia con el tiempo. Por ejemplo, un coche que utilice el modelo del bicicleta es un sistema LTI. Si el modelo incluye que los neumáticos se degraden con el tiempo (y cambien la dinámica del vehículo), entonces el sistema ya no sería LTI. LQR : Regulador Lineal Cuadrático - Linear Quadratic Regulator Un método de control que utiliza la retroalimentación completa del estado. El método trata de optimizar una función de coste cuadrática dependiente del estado y de la entrada de control. MPC : Control Predictivo - Model Predictive Control Método de control cuya entrada de control optimiza una función de coste definida por el usuario en un horizonte temporal finito. Una forma común de MPC es el LQR (regulador lineal cuadrático) de horizonte finito. NHTSA : Administración Nacional de Seguridad del Tráfico en Carretera (EEUU) - National Highway Traffic Safety Administration (EEUU) Agencia del Poder Ejecutivo del gobierno de EE.UU. que ha desarrollado un marco de 12 partes para estructurar la evaluación de la seguridad de la conducción autónoma. El marco puede consultarse aquí.  NTHSA - AUTOMATED DRIVING SYSTEMS 2.0 - A vision for Safety ODD : Dominio de Diseño Operativo - Operational Design Domain Conjunto de condiciones en las que un sistema determinado está diseñado para funcionar. Por ejemplo, un coche de conducción autónoma puede tener un sistema de control diseñado para la conducción en entornos urbanos y otro para la conducción en autopista. OEDR : Detección y Respuesta a Objetos y Eventos - Object and event detection and response   PID : Control Proporcional Integral Derivativo - Proportional Integral Derivative Controller Un método común de control definido por 3 ganancias. 1) Una ganancia proporcional que escala la salida de control en función de la cantidad de error. 2) Una ganancia integral que escala la salida de control en función de la cantidad de error acumulado. 3) Una ganancia derivativa que escala la salida de control en función de la tasa de variación del error. RADAR : Radio Detección y Alcance - Radio Detection and Ranging Un tipo de sensor que detecta el alcance y el movimiento transmitiendo ondas de radio y midiendo el tiempo de retorno y los desplazamientos de la señal reflejada. SONAR : Navegación por Sonido - Sound Navigation And Ranging Tipo de sensor que detecta la distancia y el movimiento mediante la transmisión de ondas sonoras y la medición del tiempo de retorno y los desplazamientos de la señal reflejada. Enlaces de referencia https://www.coursera.org/learn/intro-self-driving-cars https://es.wikipedia.org/wiki/Galileo_(navegaci%C3%B3n_por_sat%C3%A9lite) https://dallocas.blogs.upv.es/docencia/vehiculos-autonomos-y-conectados/limitacion-de-los-vehiculos-autonomos-y-conectados-dominios-de-diseno-operativos/ https://taxonomy.connectedautomateddriving.eu/object-and-event-detection-and-response/ Linux Opción alternativa - Instalación del parche PREEMPT RT usando Xanmod para Ubuntu 24.04 (x64) Instalación del parche PREEMPT RT usando Xanmod para Ubuntu 24.04 (x64) El siguiente script de instalación se basa en el siguiente enlace: https://linuxcapable.com/install-xanmod-kernel-on-ubuntu-linux/ Esta primera parte prepara el sistema con los paquetes necesarios, el repositorio y comprueba que versión es compatible con el kernel. sudo apt update sudo apt upgrade -y sudo apt install dirmngr lsb-release ca-certificates software-properties-common apt-transport-https dkms curl -y curl -fSsL https://dl.xanmod.org/gpg.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/xanmod.gpg > /dev/null echo 'deb [signed-by=/usr/share/keyrings/xanmod.gpg] http://deb.xanmod.org releases main' | sudo tee /etc/apt/sources.list.d/xanmod-kernel.list sudo apt update wget https://dl.xanmod.org/check_x86-64_psabi.sh chmod +x check_x86-64_psabi.sh ./check_x86-64_psabi.sh En resultado de este ultimo comando será CPU supports x86-64-v2 , CPU supports x86-64-v3 o CPU supports x86-64-v4 . En función de la salida tendremos que adaptar la versión. sudo apt install linux-xanmod-rt-x64v3 Para completar la instalación reiniciar el equipo. OPCIONAL: ROS 2 En mi caso quiero una caracteristicas determinadas del parche de tiempo real, que son las siguientes: # Enable CONFIG_PREEMPT_RT -> General Setup -> Preemption Model (Fully Preemptible Kernel (Real-Time)) (X) Fully Preemptible Kernel (Real-Time) # Enable CONFIG_HIGH_RES_TIMERS -> General setup -> Timers subsystem [*] High Resolution Timer Support # Enable CONFIG_NO_HZ_FULL -> General setup -> Timers subsystem -> Timer tick handling (Full dynticks system (tickless)) (X) Full dynticks system (tickless) # Set CONFIG_HZ_1000 (note: this is no longer in the General Setup menu, go back twice) -> Processor type and features -> Timer frequency (1000 HZ) (X) 1000 HZ # Set CPU_FREQ_DEFAULT_GOV_PERFORMANCE [=y] -> Power management and ACPI options -> CPU Frequency scaling -> CPU Frequency scaling (CPU_FREQ [=y]) -> Default CPUFreq governor ( [=y]) (X) performance Lo que ocurre es lo siguiente al comprobar si tenemos estas caracteristicas cat /boot/config-$(uname -r) | grep -E "CONFIG_PREEMPT_RT|CONFIG_HIGH_RES_TIMERS|CONFIG_NO_HZ_FULL|CONFIG_HZ_|CONFIG_CPU_FREQ_DEFAULT_GOV_" Podemos observar que no tenemos todas caracteristicas deseadas, 3 de las 5. # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_FULL is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_RT=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_500 is not set # CONFIG_HZ_1000 is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set Entonces, vamos a proceder a descargar de nuevo el kernel y esta vez compilarlo y instalarlo. Porque lo hago de esta forma, por asegurarme que el kernel era compatible y funcionaba. RECOMENDADO UNA RUTA COMO ~/Documentos/kernel o ~/kernel Comprobar que sea la misma versión que el kernel actual, en este caso, he empleado la versión actual a dia de hoy. No borrar la instalación. wget https://gitlab.com/xanmod/linux/-/archive/6.12.31-rt-xanmod1/linux-6.12.31-rt-xanmod1.tar.gz tar -xvzf linux-6.12.31-rt-xanmod1.tar.gz cp /boot/config-$(uname -r) .config yes "" | make oldconfig scripts/config --enable CONFIG_NO_HZ_FULL scripts/config --enable CONFIG_HZ_1000 scripts/config --set-val CONFIG_HZ 1000 make olddefconfig make -j$(nproc) sudo make headers_install sudo make modules_install sudo make install sudo update-grub sudo reboot Con esta serie de comandos realizamos la compilación y la instalación. cat /boot/config-$(uname -r) | grep -E "CONFIG_PREEMPT_RT|CONFIG_HIGH_RES_TIMERS|CONFIG_NO_HZ_FULL|CONFIG_HZ_|CONFIG_CPU_FREQ_DEFAULT_GOV_" Luego queda comprobar que efectivamente las caracterisiticas son las deseadas. # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_FULL=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_RT=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_500 is not set CONFIG_HZ_1000=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set OPCIONAL: Drivers AMD Radeon™ Software for Linux® version 25.10.1 for Ubuntu 24.04.2 HWE Version 25.10.1 wget https://repo.radeon.com/amdgpu-install/6.4.1/ubuntu/noble/amdgpu-install_6.4.60401-1_all.deb sudo dpkg -i amdgpu-install_6.4.60401-1_all.deb OPCIONAL: Drivers NVIDIA Linux x64 (AMD64/EM64T) Display Driver 570.153.02 | Linux 64-bit MANUAL wget https://es.download.nvidia.com/XFree86/Linux-x86_64/570.153.02/NVIDIA-Linux-x86_64-570.153.02.run chmod +x NVIDIA-Linux-x86_64-570.153.02.run sudo IGNORE_PREEMPT_RT_PRESENCE=1 bash ./NVIDIA-Linux-x86_64-570.153.02.run sudo reboot OPCIONAL: Problemas con las pantallas Eliminar archivos de configuración de Xorg : Si existe un archivo /etc/X11/xorg.conf , puede estar causando conflictos. Puedes eliminarlo o moverlo temporalmente: sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup sudo apt update sudo apt upgrade sudo systemctl restart display-manager sudo prime-select on-demand Luego, reinicia el sistema con la pantalla externa conectada. Esto permitirá que el sistema detecte y configure automáticamente las pantallas durante el arranque. Enlaces de referencia: https://linuxcapable.com/install-xanmod-kernel-on-ubuntu-linux/ https://docs.ros.org/en/jazzy/Tutorials/Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2.html Instalación de ROS 2 y librerias Instalación principal de ROS 2 Jazzy para Ubuntu 24.04 https://docs.ros.org/en/jazzy/index.html Instalación de ROS 2 Control https://control.ros.org/jazzy/doc/getting_started/getting_started.html https://control.ros.org/jazzy/doc/ros2_control/controller_manager/doc/userdoc.html Recomendable testear las demos sudo apt-get install ros-$ROS_DISTRO-xacro sudo apt-get install ros-$ROS_DISTRO-rqt* sudo apt-get install ros-$ROS_DISTRO-joint* mkdir -p ~/ws_dev/src cd ~/ws_dev/src git clone https://github.com/ros-controls/ros2_control_cmake.git git clone https://github.com/ros-controls/ros2_control_demos.git cd .. colcon build Importante leer: https://control.ros.org/jazzy/doc/ros2_control/hardware_interface/doc/hardware_components_userdoc.html https://design.ros2.org/articles/node_lifecycle.html Instalación de Ardupilot para ROS 2 https://ardupilot.org/dev/docs/ros2.html   Compilar el parche de tiempo real para Ubuntu https://github.com/2b-t/linux-realtime   Página nueva Chat Exportado 🧑 Usuario: Tengo un controlador Curtis 1234-5271, y en este controlador hay pines que tienen función de entrada y salida, además no tengo el VCL, y no sé qué función acaban de desempañar, por donde empiezo? 🤖 ChatGPT: Muy buena pregunta — trabajar con un controlador como el Curtis “1234-5271” (que forma parte de la serie 1234) sin tener toda la documentación completa (por ejemplo, el listado completo de funciones VCL) complica un poco las cosas, pero sí hay un camino ordenado para averiguar qué función cumplen los pines de entrada/salida. Aquí te dejo por dónde empezar y qué revisar, adaptado al modelo que tienes. ✅ Paso a paso para comenzar Identificar claramente el modelo y su variante Asegúrate de que tu unidad es exactamente “1234-5271” y que pertenece a la versión “E” / “SE” (o la que sea) de la serie 1234. Por ejemplo, aparece descrito como “36-48 V, 275 A” para el 1234-5271. Kit Elec Shop +2 Esto es importante porque los pines de I/O y su función pueden variar ligeramente entre variantes. Descargar el manual de instalación y conexión “Low power / I/O” Por ejemplo, en el manual “1232E/34E/36E/38E & 1234E/SE…” hay una tabla con “Low Power Connections – 35‐pin AMPSEAL connector” que da nombres de pines, descripciones generales y sus funciones programables mediante VCL. RICO Manufacturing +1 Eso te permite ver una lista básica de pines comunes (aunque puede que no sea exactamente “5271” pero la base será la misma). Revisar la tabla de conexiones de baja señal Por ejemplo, en el manual se ve que: Pin 1 = KSI (Keyswitch Input) – alimenta lógica del controlador. RICO Manufacturing Pin 2 = Prop. Driver (Proportional Driver) – que también “can also be used as a digital input”. RICO Manufacturing Pin 24 = “Switch 1 / Analog 1” (entrada analógica o switch) RICO Manufacturing Pin 8 = “Switch 2 / Analog 2” RICO Manufacturing Y otros pines de driver de salidas PWM, entradas digitales etc. RICO Manufacturing Esto te da una base para saber que hay pines que pueden funcionar como: entrada digital (on/off), entrada analógica (0-10 V), salida proporcional/PWM, driver de solenoide, etc. Determinar qué pines tienes conectados físicamente y cómo están usados Observa el conector de 35 pines (o el que lleve tu modelo) y localiza los pines que están cableados. Verifica si esos cables van a interruptores, sensores de pedal, pedales de acelerador, freno, contacto llave, solenoides, etc. Con ello puedes mapear “este pin va al pedal del freno” → entonces probablemente es una entrada de freno. “Este lleva a un solenoide” → podría ser un driver de salida. Verificar la programación (VCL) o configuración que lleva el controlador El manual indica que la serie 1234 “E/SE” usa un lenguaje de programa interno llamado VCL (Vehicle Control Language) que permite asignar funciones a pines, reasignar entradas/salidas. RICO Manufacturing +1 Si puedes acceder al programa o al archivo “SysInfo” o a los parámetros que vienen almacenados, podrías ver a qué variable VCL está asignado cada pin (“Sw_1”, “Analog1”, “DigOut6”, etc.). Esto te permitirá conocer su función real. Medir y verificar eléctricamente los pines Con el controlador desconectado de potencia (o con cuidado si está conectado), puedes medir los pines: Qué tensión tiene cada pin cuando está en reposo (por ejemplo +12 V, +5 V, 0 V). Si al activar un interruptor (por ejemplo freno) cambia la tensión. Si al accionar alguna función la salida cambia (en caso de driver de solenoide o PWM). Esto ayuda a confirmar si el pin es entrada digital, entrada analógica o salida de driver. Documentar lo que encuentres Haz una tabla con pin número, nombre en la etiqueta del conector, lo que mediste, y la función probable. Esto te servirá para futuras referencias y para que puedas programar correctamente. 📋 Ejemplo de algunas conexiones típicas de la serie 1234E/SE Aquí te muestro algunos ejemplos extraídos del manual que se aplican muy probablemente a tu controlador: Pin Nombre / Designación Función típica 1 KSI (Keyswitch Input) Entrada de encendido, lógica de arranque. hpevs.com +1 2 Prop. Driver Salida proporcional para válvula o puede usarse como entrada digital. RICO Manufacturing 24 Switch 1 / Analog 1 Entrada digital o analógica (p.ej. pedal acelerador potenciómetro) RICO Manufacturing 8 Switch 2 / Analog 2 Otra entrada digital/analógica. RICO Manufacturing 30 Analog Out (0-10 V) Salida analógica para instrumentación, no en todos los modelos. RICO Manufacturing +1 ⚠️ Consideraciones importantes / advertencias Asegúrate de desconectar la batería principal antes de manipular cables de alta tensión (fase U/V/W, B+/B–) del controlador. Eso es obligatorio por seguridad. Las conexiones de señal (los 35-pines) aunque de baja corriente, conviene tratarlas con cuidado para evitar ruidos, malos contactos o desgaste. El manual lo advierte. pdfcoffee.com Aunque conozcas la función “típica” de un pin, la programación VCL puede haber reasignado su utilidad en tu equipo. Es decir, un pin que normalmente sería “Switch 4” podría usarse para otra señal si así se programó. Si no tienes el programa ni los parámetros, tendrás que deducir parte del álgebra funcional mediante medición y observación. Guarda bien cualquier configuración que hagas, ya que un mal ajuste puede provocar comportamientos inesperados del vehículo o sistema. Si quieres, puedo ayudarte a buscar y descargar el manual específico para el modelo “1234-5271” (o su variante) y ver si consigo el listado completo de pines y funciones VCL. ¿Te parece bien que lo haga? 🧑 Usuario: No, es el 1234-5271, 36-48V 275A 🤖 ChatGPT: Perfecto — al confirmar que tienes un Curtis 1234‑5271 (36-48 V, 275 A), aquí tienes los pasos dirigidos específicamente a ese modelo + lo que he encontrado de documentación aplicable, para que puedas averiguar las funciones de los pines de I/O. 🔍 Qué sé hasta ahora En la web aparece este modelo listado con la versión 1234-5271 y su voltaje nominal 36-48 V. noco-evco.com Hay un manual de la serie Curtis “1234 / 36 / 38” que cubre la familia 1234 (aunque quizá no exactamente la 5271 variante) y muestra los conectores, pines, entradas/salidas programables. thunderstruck-ev.com Otro manual de la serie 1232E/34E/36E + 1234E/SE da tablas de pines y funciones típicas de I/O. RICO Manufacturing En la lista de especificaciones, para modelos 1234E/SE se indica que el voltaje nominal 36-48 V aplica. RICO Manufacturing +2 Por lo tanto, aunque quizá no tengo el manual de la variante exacta 5271 con cada pin documentado, sí tengo suficientes referencias para la serie que te van a servir como base sólida. 🛠️ Cómo aplicar esto al 1234-5271 para averiguar los pines de I/O Aquí tienes un plan concreto adaptado a tu controlador: Obtener el conector de señal Ubica el bloque de pines “low-power / I/O” del controlador. En los manuales de la serie 1234 es el conector tipo J1 (o similar) de 35 pines para la lógica. Ejemplo: en el manual “1234 /36 /38” aparece Pin 1 = KSI, Pin 7 = I/O Ground, etc. thunderstruck-ev.com +1 Descargar el manual de serie 1234 Puedes usar el manual “1234/36/38 Manual” como referencia general: contiene la tabla I/O de la serie. thunderstruck-ev.com Hacer una tabla de pines físicos para tu unidad Con el conector visualmente, realiza un listado pin-por-pin (ej: J1-1, J1-2, …) y los nombres que el manual de la serie asigna a esa posición. Ejemplos del manual: Pin 1 = KSI (Keyswitch Input) thunderstruck-ev.com +1 Pin 24 = Switch1 / Analog1 RICO Manufacturing +1 Pin 8 = Switch2 / Analog2 RICO Manufacturing +1 Pin 30 = Analog Out (0-10 V) en algunos modelos RICO Manufacturing +1 Esto te da un primer mapeado. Verificar la variación para la 5271 Debido a que la variante es 5271 (36-48 V 275 A) podría haber pequeñas diferencias (programación, número de drivers, etc). Verifica en el conector si hay pines no usados, o textos serigrafiados en la carcasa que mencionen “I/O J1-xx”. Identificar entradas vs salidas Las entradas típicas: interruptores digitales (“Switch X”), entradas analógicas (“Analog1/2”), pedal acelerador, freno, sensores posición. Las salidas típicas: drivers de solenoide (“Driver 1-4”), salida analógica “Analog Out”, etc. El manual de la serie 1232E/34E/36E/38E & 1234E/SE da listas de “Digital driver inputs/pins” y “Analog inputs/outputs”. RICO Manufacturing +1 Verificar la programación VCL Este controlador es programable con lenguaje Vehicle Control Language (VCL) y el menú de programación permite asignar funciones a pines. En el manual hay funciones específicas como SET_DIGOUT(), ENABLE_EMER_REV(), etc. RICO Manufacturing +1 Si accedes al programa guardado o al sistema de parámetros (por ejemplo con el programador de mano Curtis 1313 Handheld Programmer o el Curtis 1314 PC Programming Station) podrás ver qué función real se le ha asignado a cada pin en tu máquina. Medir los pines para confirmar Con alimentación de lógica (pero desconectado del motor, idealmente) mide los pines: ¿Cuál está a “activo” cuando el interruptor correspondiente está accionado? ¿Cuál cambia tensión al accionar el pedal, sensor, driver? Esto te ayuda a confirmar que el pin que el manual llama “Switch 3 / Interlock” efectivamente está conectado al interlock de tu máquina. Documentar lo que descubras Arma un documento o tabla con: Pin número → Nombre del pin según serie → Función actual (entrada/salida) → Tipo (digital/analógica/driver) → Observaciones. Esto te permitirá tener un mapeado fiable para mantenimiento o futura programación. 📑 Lo que aún NO tengo / revisar No he encontrado el manual específico con la etiqueta “1234-5271” que contenga una lista completa de pines I/O exclusivos para esa variante. Por lo tanto puede haber ligeras diferencias respecto al manual “1234/36/38” que tengo — sería prudente comprobar la factura de tu equipo, número de software/os, o contactar con Curtis para solicitar el “SysInfo” o plantilla de pines para ese número de parte. Si quieres, puedo buscar un manual específico para el número de parte 1234-5271 (o contactar con Curtis para ver si hay una hoja de “I/O pinout” para ese modelo exacto) y te lo podría enviar. ¿Te parece bien que lo haga? 🧑 Usuario: Que es el coil return? 🤖 ChatGPT: Coil Return en un controlador Curtis (incluyendo la serie 1234-5271) es simplemente el retorno a masa (GND) para las bobinas de los dispositivos externos, por ejemplo: Contactores Solenoides Electro-válvulas Relés Es decir: es el negativo común específicamente diseñado para las bobinas que son activadas desde los “driver outputs” del controlador. ✔️ Explicación clara y práctica Los controladores Curtis tienen salidas llamadas “Coil Drivers” o “Driver Outputs”. Estas salidas NO entregan una alimentación completa (positivo y negativo); normalmente proporcionan solo un lado del circuito (según modelo puede ser lado positivo o lado negativo). Por eso, Curtis proporciona un pin dedicado llamado Coil Return, que sirve como el otro lado del circuito. 🧲 ¿Cómo funciona? Imagina un contactor: +V batería → bobina del contactor → DRIVER OUTPUT del Curtis ↓ COIL RETURN del Curtis O en algunos modelos: powershell Copy code DRIVER OUTPUT del Curtis → bobina → COIL RETURN (tierra) El Coil Return funciona como: 🟤 GND seguro para bobinas Está pensado para manejar los retornos de corriente producidos por cargas inductivas. Internamente incluye protección contra picos, ruido y retornos inductivos. Es diferente del “Signal Ground” (tierra de señales), aunque a veces están relacionados internamente. ⚠️ ¿Qué NO es el Coil Return? No es una salida. No es un positivo. No es un GND general para sensores o lógica (aunque comparten referencia). No debe usarse como tierra de chasis del vehículo. Está diseñado solo para bobinas porque estas generan picos de voltaje al desenergizarse. 🔧 ¿Por qué existe un pin dedicado? Las bobinas generan picos de 50–200 V cuando se desactivan. El Coil Return: Protege los transistores de salida del controlador. Minimiza ruido en las entradas analógicas y señales. Garantiza que la corriente fluya por el camino previsto. 🗂️ En lenguaje simple Coil Return = el GND especial para las bobinas que el controlador activa. Si quieres, te puedo decir qué número de pin es el Coil Return en tu modelo 1234-5271 y cómo conectarlo correctamente según tu aplicación. ¿Quieres eso? 🧑 Usuario: El pin 1 KSI que función tiene? 🤖 ChatGPT: El pin 1 – KSI (Key Switch Input) en los controladores Curtis, incluido tu 1234-5271, tiene una función crítica: 🔑 ¿Qué es KSI? KSI = Key Switch Input = Entrada de interruptor de llave Es la señal que enciende la lógica interna del controlador. Sin KSI, el controlador está "muerto", aunque tenga batería conectada. ✔️ Función exacta del KSI Cuando le aplicas +B+ (tensión de batería baja) al pin KSI: El controlador “despierta”. Inicializa la lógica interna. Activa entradas, salidas y sensores. Permite que el controlador procese acelerador, freno, dirección, etc. En muchos casos habilita que la etapa de potencia pueda funcionar. Es el "ON/OFF" de la electrónica del controlador. 🔌 Qué voltaje lleva KSI En tu modelo 36–48 V, el KSI recibe normalmente: +36–48 V (igual al voltaje de batería de tracción) A través de la llave de contacto o un interruptor equivalente ⚠️ Importante KSI NO alimenta el motor, solo alimenta la lógica del controlador. El controlador tiene dos alimentaciones: B+ y B–: potencia (grande) KSI: habilitación de lógica (pequeña) KSI suele consumir muy poca corriente (50–150 mA aprox). Si KSI no recibe voltaje → el controlador no hace nada, ni activa salidas ni lee entradas. 📘 Esquema simplificado less Copy code Batería 36–48 V | Llave | KSI (Pin 1) → Activa la lógica del Curtis 🧪 ¿Cómo comprobar si funciona? Mides el pin 1: Con llave apagada → 0 V Con llave encendida → voltaje de batería (36–48 V) Si el controlador no enciende: ✔ Verifica que KSI realmente reciba +V ✔ Verifica fusible del KSI ✔ Verifica retorno de lógica (Signal Ground) Si querés, te puedo dibujar el esquema completo de conexión para tu 1234-5271 incluyendo KSI, Coil Drivers, Coil Return, acelerador, etc. ¿Lo deseas? 🧑 Usuario: Que entrada es el interlock? 🤖 ChatGPT: En los controladores Curtis serie 1234 (incluido tu 1234-5271) la señal llamada INTERLOCK no es un pin fijo, sino una entrada digital que depende de cómo esté programado el controlador. Peeeero… en los modelos estándar 1234/1234E la entrada de interlock casi siempre es uno de estos pines: ✅ Entrada de Interlock (la más común) En la mayoría de los Curtis de la serie 1234/1234E, INTERLOCK = Pin 7 o Pin 8 (Switch Input) según configuración VCL. Usualmente se asigna así: ✔ Pin 7 — Switch Input 2 → usado como Interlock ó ✔ Pin 8 — Switch Input 3 → usado como Interlock ¿Por qué? Porque el Interlock siempre es una entrada digital que indica al controlador: “se cumplen las condiciones para habilitar el motor”. 🔧 ¿Qué es el Interlock? Es una entrada que debe estar activa para que el controlador permita mover el motor. El Interlock suele venir de: interruptor del pedal de freno interruptor de asiento interruptor de tapa/cubierta microswitch del contactor sistema de seguridad del vehículo Es decir, cualquier señal que Curtis necesite para permitir la propulsión. 🚨 Cómo identificar cuál es tu Interlock REAL en el pinout Como tu unidad es 1234-5271, y no tienes el VCL, la forma correcta es: 1️⃣ Ver qué pines están físicamente cableados De los pines Switch (7, 8, 24, etc.), revisa cuáles tienen un cable que va a un interruptor de seguridad. 2️⃣ Medir voltaje en esas entradas El interlock típico funciona así: Activo → recibe +B o +KSI Inactivo → queda en 0 V Cuando el interlock no está activo → el controlador NO habilita accionamiento 3️⃣ Ver qué entrada cambia cuando activas la condición de seguridad Por ejemplo: Si presionas el freno y un pin cambia de 0 a 36–48 V → ese puede ser el interlock Si al levantar la máquina o abrir una tapa la señal cambia → ese pin es el interlock 4️⃣ Confirmar con comportamiento El Interlock debe ser una entrada que, si la desconectas, el controlador deja de habilitar salida al motor. 📌 Tabla típica de Curtis 1234E (referencia) Aunque puede variar, la tabla más común es: Pin Nombre Uso común 7 Switch 2 A menudo usado como Interlock 8 Switch 3 Alternativa para Interlock 24 Switch 1 / Analog 1 Acelerador, freno o señal variada 😎 En resumen ➡️ El Interlock es una entrada digital “Switch Input” asignada por programación. ➡️ En la mayoría de los 1234 se usa el PIN 7 o PIN 8. ➡️ Para tu 1234-5271 exacto, la única forma de saber al 100% es revisar: qué pin está cableado qué pin cambia cuando se activa la condición de seguridad Si querés, puedo ayudarte a identificar exactamente cuál es el interlock mirando tu conector si me dices: ¿Qué pines están cableados? ¿A qué van esos cables (freno, asiento, micro, etc.)? Con eso te lo confirmo al 100%. 🧑 Usuario: El controlador Curtis se puede accionar mediante mensajes CAN, ¿Distingue entre modo automático y manual? 🤖 ChatGPT: Sí, los controladores Curtis con interfaz CAN (incluyendo muchas variantes de la serie 1234/1234E/SE) se pueden accionar mediante mensajes CAN siempre que el firmware/VCL esté configurado para ello, pero Curtis NO distingue automáticamente entre “modo automático” y “modo manual”. Lo explico en detalle: ✅ 1. ¿Curtis puede ser controlado por CAN? Sí, pero solo si la versión del firmware lo permite y si el VCL está configurado para interpretar comandos CAN. Cuando está habilitado, Curtis puede recibir: Demandas de torque Demandas de velocidad Activación de dirección Estados de habilitación / interlock Señales de fallos, etc. ❗ 2. ¿Tiene Curtis un “modo automático” y “modo manual”? 👉 NO. No existe esta diferenciación por defecto dentro del controlador. Curtis simplemente recibe señales de entrada (CAN o pines) y tú decides, mediante la configuración o el programa VCL, cómo interpretarlas. El controlador no entiende por sí mismo: “ahora está en automático” o “ahora está en manual”. ✔️ Lo que SÍ hace Curtis En vez de distinguir modos, Curtis: 🟦 Solo ejecuta lo que le manda el VCL El VCL puede: Leer entradas digitales (switches) Leer mensajes CAN Tomar decisiones lógicas Elegir qué señal usar como demanda de aceleración Cambiar comportamientos según una variable o bit lógico ⚙️ 3. ¿Cómo se implementa entonces un modo automático/manual? Se hace dentro del VCL, por ejemplo: c Copy code if (ManualSwitch == ON) { TorqueDemand = PedalPosition; } else { TorqueDemand = CAN_Torque_Request; } O también: c Copy code if (CAN_Mode_Command == AUTO) { Use CAN inputs; } if (CAN_Mode_Command == MANUAL) { Use local switches and pedals; } Entonces: El VCL decide qué señal usar. Curtis no trae estos modos por defecto. 🔧 4. Señales típicas que se usan para “cambiar modo” Tú mismo puedes seleccionar la lógica: Un pin digital (Switch Input) → “modo manual/automático” Un mensaje CAN (bit en un byte) → “modo remoto” Una combinación de señales (ej: freno + freno estacionamiento) Una variable persistente en VCL 📌 5. Importante En la mayoría de los casos, Curtis NO permite controlar el motor SOLO por CAN si no hay también: KSI activo Interlock activo Inhibits sin activar Parámetros mínimos correctos El CAN solo reemplaza la señal de demanda, no la lógica de seguridad. 🧠 Resumen claro Función ¿Curtis la tiene de fábrica? Control por CAN ✔️ Sí, si está habilitado en el firmware Modo automático/manual ❌ No existe por defecto Diferenciar modos y actuar ✔️ Sí, pero lo programas tú con VCL Conmutar entre pedal o CAN ✔️ Sí, mediante programación 📘 Si quieres, puedo: Explicarte cómo activar control CAN, Qué mensajes CAN usa Curtis, O cómo se programa un selector manual/automático en VCL. ¿Qué de esto necesitas? 🧑 Usuario: Entonces la prop driver, driver 1, 2, 3, 4 pueden activar relés? 🤖 ChatGPT: Sí, la salida Prop Driver y los Driver 1, 2, 3 y 4 del Curtis (incluido el 1234-5271) pueden activar relés, solenoides o contactores, siempre que no superes la corriente máxima que puede manejar cada salida. Aquí te doy la explicación bien clara: ✅ 1. ¿Qué son “Prop Driver” y “Driver 1-4”? Son salidas de potencia de baja tensión, diseñadas para activar cargas externas como: Relés Electroválvulas Contactores Solenoides Luz de marcha atrás (en algunos equipos) Estas salidas suelen ser PWM o ON/OFF, según lo defina el VCL. ⚡ 2. ¿Puedo usar estas salidas para activar un relé? ✔️ Sí, perfectamente. Es uno de sus usos más comunes. Sólo necesitas verificar: El relé debe ser de bobina de DC compatible con la tensión de tracción (36–48 V en tu caso, o usar uno de 12/24 V con fuente separada). La corriente de la bobina NO debe superar el límite de cada salida. 🔌 3. ¿Qué corriente soportan las salidas? Los valores exactos dependen de la variante, pero típicamente: Prop Driver: entre 2 a 3 A máx Driver 1–4: entre 2 a 4 A máx según modelo Esto es más que suficiente para relés comunes, que suelen consumir: 80–150 mA → relé pequeño 200–500 mA → contactor pequeño 1–2 A → contactores grandes (ojo aquí) Si tienes un contactor muy grande (5–6 A de bobina), entonces NO debes activarlo directamente desde el Curtis; debes usar un relé intermedio. 🔄 4. ¿Cómo se conectan correctamente? Curtis usa dos tipos de drivers según el modelo: ▶️ a) Driver de lado negativo (low-side switching) Activa la bobina conectando su extremo al negativo (Coil Return). Es muy común. Ejemplo: powershell Copy code +48 V ────── bobina del relé ────── Driver1 │ Coil Return ▶️ b) Driver de lado positivo (high-side switching) Entrega +V a la bobina y el otro extremo va a Coil Return o GND. El manual lo especifica. 🧲 5. ¿Qué salida conviene para relés? Todas funcionan, pero típicamente: Driver 1–4 → relés, contactores, actuadores ON/OFF Prop Driver → válvulas proporcionales o relés también (sin problema) La Prop Driver es PWM, pero puede configurarse como digital. ⚠️ 6. Protección: usar siempre Coil Return Curtis no quiere que las bobinas vuelvan a GND del chasis directamente. EL retorno correcto es: powershell Copy code COIL RETURN → negativo de la bobina Esto protege al controlador contra picos inductivos. 🧠 Resumen ✔ Sí, las salidas Prop Driver y Driver 1–4 pueden activar relés. ✔ Diseñadas justamente para eso. ✔ Usar siempre Coil Return como retorno. ✔ Verificar la corriente de bobina (no pasarse del límite). ✔ Con VCL puedes configurarlas como PWM o ON/OFF. Si quieres, puedo explicarte exactamente qué corriente soportan tus salidas en el 1234-5271, o hacerte un esquema de conexión para activar relés o contactores desde el Curtis. ¿Quieres eso? Pruebas experimentales Prueba experimental (2026-02-26) En el experimento realizado hoy, hemos elevado la parte trasera del vehículo utilizando unos caballetes y hemos retirado las ruedas con el fin de efectuar un ensayo en vacío. Durante la prueba se aplicaron distintos escalones en positivo a la acción de control, la cual está mapeada en un valor int16 que fija una referencia de velocidad. Esta referencia se convierte posteriormente en un valor de RPM del motor, cuya correspondencia ha sido determinada en el propio experimento. Dicho valor puede traducirse a la velocidad en el eje de salida y en la rueda mediante la relación de transmisión 16:1 y conociendo el radio efectivo de la rueda. Aunque la relación de transmisión se conocía previamente, se ha verificado nuevamente durante el experimento. A continuación, se muestran los resultados obtenidos: Prueba experimental (2026-03-24) En el experimento realizado hoy, hemos pesado el vehículo con unas básculas para saber la masa del vehículo de cara al modelado, para obtener en un futuro el centro de gravedad. En el siguiente, documento recortado hay una explicación sobre cómo hacer ciertos cálculos. Retail of TFM Center of Mass Calculation.pdf Medidas de peso de la parte delantera: Medidas de peso de la parte trasera: Primera parte de los cálculos Sumamos los kilos de la parte delantera y trasera y los pasamos a Newtons (aproximadamente): $205$ Kg $\approx$ $2100$ N $420$ Kg $\approx$ $4120$ N Con esto y el largo dado por el plano: Faltaría el plano El "Track width", la distancia entre los centros de las ruedas es l = $1.65$ m. Aplicando las fórmulas del trabajo "SIMULATION OF THE DYNAMIC BEHAVIOR OF A SELF-DRIVEN ELECTRIC VEHICLE by Federico Frera" (Retail of TFM Center of Mass Calculation.pdf). Y asumiendo que la masa que hemos obtenido por las básculas de forma parcial se pueden sumar, $625$ Kg. Por supuesto, este sería el peso total del vehículo, aquí habría que restarle el peso de las ruedas en caso que queramos hacer una simulación, el peso por rueda es $8.7$ Kg por rueda, cómo podemos ver en el bulto del paquete. Tenemos que "b", como la distancia del centro de la rueda trasera al centro de masa en el plano de perfil del vehículo, véase el trabajo para una mejor comprensión, da cómo resultado: b $\approx$ $0.565$ m Y en el caso de "a", cómo la distancia del centro de la rueda delantera al centro de masa en el plano de perfil del vehículo, véase el trabajo para una mejor comprensión, da cómo resultado: a $\approx$ $1.108$ m Que por simplificar cómo ambos, su suma debe ser igual a l, podemos utilizar otra aproximación cómo son los valores dados en el trabajo. Quizás la distancia entre ejes no sea exactamente está, también es posible. Y quizás está prueba que queda pendiente de hacer que es  Pesar el vehículo en cierta pendiente,  pues no tenga demasiado sentido hacerla.