Error_msg: 65536

[sfrenot]

I have a Diablo robot that does not respond anymore to the remote controller. I am booting on the raspberry, and interracting with ros2.
ros2 topic echo /diablo/sensor/Body_state has a msg_error: 65536.

Any clue of how can I get out of this ?

[ATemova]

The error_msg field is a bitmask, so the number is more informative than it looks. You can decode it.

The DDTRobot diablo_ros2 docs give one worked example: error_msg = 2064384 means "all six motors disconnected." That number is exactly bits 15 through 20 set (2^15 + 2^16 + ... + 2^20 = 2064384) — i.e. one bit per motor. Your value, 65536, is 2^16 — a single one of those six motor bits. So this almost certainly means one motor has dropped its connection / faulted, not all six. That also explains why the robot won't respond: if a drive/joint motor is faulted, the balance controller can't engage, so it won't stand or obey the remote.

What I'd check, in order:

1. The 40-pin ribbon cable. The docs' first troubleshooting step for motor-disconnection codes is to verify the 40p cable between the development board (your Raspberry Pi carrier) and the robot control board is fully seated. A partially disconnected cable, or one motor's connector, is the most common cause of a single-motor bit like this. Power down, reseat both ends of the 40p cable and the individual motor connectors, then power back up.

2. Confirm it clears on reboot. After reseating, echo the topic again:

   ros2 topic echo /diablo/sensor/Body_state
   

   You want error_msg back to 0. If it's still 65536, the fault is persistent (bad cable, connector, or that specific motor) rather than a transient.

3. Check it's in standing mode before expecting control. The Diablo only accepts drive commands in standing mode — in Body_state you should see robot_mode_msg = 3 when standing. If a motor fault is blocking it from entering standing mode, that's consistent with the remote doing nothing.

One honest caveat: the exact bit-to-motor mapping isn't fully published — I'm inferring it from the documented 2064384 = six motors example, which lines up cleanly with 65536 being one of those six bits. DDT's own docs say that for status codes beyond the documented ones you should contact their FAE to confirm the precise diagnosis, so I'd reseat the cabling first and, if it persists, reach out to DDT with the 65536 value to confirm which motor it maps to.

[sfrenot]

Thanks very much for your answer and explanation.
I found a more straightforward solution. In my case, one of the motor LEDs was dead, which was the root cause of the issue.
My advice is to first check that all the motor LEDs are lit before investigating anything else.

[sfrenot]

Check led activity first, then software messages