Subject: Wheeltec Ackermann Chassis Drive Motors Inoperative Despite Successful Kinematic Command Echo on OLED (ROS 2 Jazzy)
System Configuration
- OS: Ubuntu 24.04 LTS (Noble)
- ROS 2 Version: Jazzy Jalisco
- Robot Platform: Wheeltec Ackermann Chassis (Rosbot Pro style / AKM)
- Driver Node: /wheeltec_robot
- Primary Sensor: LS (Leishen) LiDAR utilizing a WheelBoard S15C USB-to-TTL adapter
The Problem
The chassis steering mechanism responds correctly to kinematic steering angle commands, and the onboard OLED screen successfully displays live target velocity updates (e.g., L: +500, R: +500) when a command is published. However, the primary drive wheels/tracks fail to physically rotate.
Data & Topology Diagnostics
- Topic Mapping: The
/wheeltec_robot node expects an ackermann_msgs/msg/AckermannDriveStamped payload on the /ackermann_vel topic. Sending standard geometry_msgs/msg/Twist messages results in a "Waiting for matching subscription(s)" block due to type strictness in ROS 2 Jazzy.
- Bridging Success: A custom Python bridge node was implemented to translate
Twist messages from teleop_twist_keyboard into AckermannDriveStamped messages. Verbose topic tracking (ros2 topic info /ackermann_vel -v) confirms 1 subscription and active publishing.
- Microcontroller Response: When driving via the keyboard teleop + bridge, the OLED screen reacts dynamically, displaying appropriate non-zero encoder targets for Left (L) and Right (R) channels.
Physical & Electrical State
- Logic Power: Confirmed stable; OLED is functional and reads an adequate battery voltage of ~23.73V.
- Wiring Interconnects: All heavy-gauge red/black power lines, Anderson blocks, and Dean connectors are securely mated.
- Hardware Isolate: The green 'WheelBoard S15C' breakout module inside the chassis is verified as the UART-to-USB bridge specifically for the LS LiDAR data stream, meaning the lower motor-driver circuit is running on a separate internal serial pipeline.
- Actuator Behavior: The steering servo pivots smoothly to match angular target commands, but the main drive motors draw no physical power and do not engage or spin.
Request for Assistance
Given that the ROS 2 software stack is successfully communicating with the upper control logic (proven by the OLED echos and servo movement), what specific firmware parameter, hardware safety interlock, or lower-board serial mapping could be blocking the high-current power rail from reaching the drive motors?
Subject: Wheeltec Ackermann Chassis Drive Motors Inoperative Despite Successful Kinematic Command Echo on OLED (ROS 2 Jazzy)
System Configuration
The Problem
The chassis steering mechanism responds correctly to kinematic steering angle commands, and the onboard OLED screen successfully displays live target velocity updates (e.g.,
L: +500,R: +500) when a command is published. However, the primary drive wheels/tracks fail to physically rotate.Data & Topology Diagnostics
/wheeltec_robotnode expects anackermann_msgs/msg/AckermannDriveStampedpayload on the/ackermann_veltopic. Sending standardgeometry_msgs/msg/Twistmessages results in a "Waiting for matching subscription(s)" block due to type strictness in ROS 2 Jazzy.Twistmessages fromteleop_twist_keyboardintoAckermannDriveStampedmessages. Verbose topic tracking (ros2 topic info /ackermann_vel -v) confirms 1 subscription and active publishing.Physical & Electrical State
Request for Assistance
Given that the ROS 2 software stack is successfully communicating with the upper control logic (proven by the OLED echos and servo movement), what specific firmware parameter, hardware safety interlock, or lower-board serial mapping could be blocking the high-current power rail from reaching the drive motors?