read crc: 251, computed crc: 219 data: [255, 255, 32, 4, 0, 0, 0, 251]

[ddwy]

When I run the program and ask open_duck to walk, the following error occurs: open_duck cannot walk. How to solve this problem? I tried replacing the corresponding servo with an error, but it still reported an error.

(venv_duck) raspios@OPENDUCKMINI-V108:~/open_duck_mini_ws/Open_Duck_Mini_Runtime/scripts $ python v2_rl_walk_mujoco.py --onnx_model_path ~/open_duck_mini_ws/Open_Duck_Mini/BEST_WALK_ONNX_2.onnx
pygame 2.6.0 (SDL 2.28.4, Python 3.11.2)
Hello from the pygame community. https://www.pygame.org/contribute.html
Done parsing args
dict_keys(['left_hip_yaw', 'left_hip_roll', 'left_hip_pitch', 'left_knee', 'left_ankle', 'neck_pitch', 'head_pitch', 'head_yaw', 'head_roll', 'right_hip_yaw', 'right_hip_roll', 'right_hip_pitch', 'right_knee', 'right_ankle'])
d_coefficient: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
d_coefficient: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
turn on : low KPS set
turn on : init pos set
d_coefficient: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
turn on : high kps
Loaded joystick with 6 axes.
[Poly ref data] Processing ...
[Poly ref data] Done processing
Loaded: beep1.wav
Loaded: happy1.wav
Loaded: lamp.wav
Loaded: lamp3.wav
Loaded: motor.wav
Loaded: beep2.wav
Loaded: lamp2.wav
Loaded: happy2.wav
Loaded: happy3.wav
Done instantiating RLWalk
Starting
UNPAUSE
read crc: 226, computed crc: 98 data: [255, 255, 32, 4, 0, 114, 7, 226]
Checksum error
read crc: 226, computed crc: 98 data: [255, 255, 32, 4, 0, 114, 7, 226]
Checksum error
read crc: 226, computed crc: 98 data: [255, 255, 32, 4, 0, 114, 7, 226]
Checksum error
Parsing error
read crc: 251, computed crc: 219 data: [255, 255, 32, 4, 0, 0, 0, 251]
Checksum error
read crc: 251, computed crc: 219 data: [255, 255, 32, 4, 0, 0, 0, 251]
Checksum error
Parsing error
Parsing error

thread '' panicked at /root/.cargo/git/checkouts/rustypot-414449c1da94f63c/c8b8223/src/protocol/mod.rs:77:9:
assertion failed: self.is_input_buffer_empty(port)?
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::panicking::panic
3: rustypot::protocol::Protocol::send_instruction_packet
4: <rustypot::protocol::feetech::Feetech as rustypot::protocol::Protocolrustypot::protocol::feetech::PacketFeetech>::sync_read
5: rustypot::device::feetech_sts3215::sync_read_present_speed
6: rustypot::IO::pymethod_read_present_velocity
7: pyo3::impl_::trampoline::trampoline
8: rustypot::<impl pyo3::impl_::pyclass::PyMethodsrustypot::IO for pyo3::impl_::pyclass::PyClassImplCollectorrustypot::IO>::py_methods::ITEMS::trampoline
9: _PyEval_EvalFrameDefault
10: PyEval_EvalCode
11:
12:
13:
14: _PyRun_SimpleFileObject
15: _PyRun_AnyFileObject
16: Py_RunMain
17: Py_BytesMain
18: __libc_start_call_main
at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
19: __libc_start_main_impl
at ./csu/../csu/libc-start.c:360:3
20: _start
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Traceback (most recent call last):
File "/home/raspios/open_duck_mini_ws/Open_Duck_Mini_Runtime/scripts/v2_rl_walk_mujoco.py", line 463, in
rl_walk.run()
File "/home/raspios/open_duck_mini_ws/Open_Duck_Mini_Runtime/scripts/v2_rl_walk_mujoco.py", line 301, in run
obs = self.get_obs()
^^^^^^^^^^^^^^
File "/home/raspios/open_duck_mini_ws/Open_Duck_Mini_Runtime/scripts/v2_rl_walk_mujoco.py", line 147, in get_obs
dof_pos = self.hwi.get_present_positions(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/raspios/open_duck_mini_ws/Open_Duck_Mini_Runtime/scripts/mini_bdx_runtime/rustypot_position_hwi.py", line 165, in get_present_positions
present_positions = self.io.read_present_position(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pyo3_runtime.PanicException: assertion failed: self.is_input_buffer_empty(port)?

[redEddie]

This looks like a power issue — specifically voltage sag under load.

The checksum/CRC errors and the is_input_buffer_empty panic both point to the same thing: the bytes coming back over the serial bus are getting corrupted. The communication fails because the servos brown out mid-transmission.

What I saw in my case:

With a battery rated for only ~4A continuous discharge, everything worked fine at full charge. But once it dropped to around 50%, the serial communication started failing in exactly this way (at least as far as I remember).

When all the servos draw current at once — especially with raised KPs, as they all move toward the init pose — the voltage sags below what the servos need. Their responses come back garbled → CRC errors → the panic.

Two things fixed it completely for me:

1. Switching to a high-discharge battery (I used a 25A-rated Samsung cell).
2. Or just running off a bench power supply instead of a battery.

Hope this helps! One more thing worth checking down the line: in my case the motors couldn't keep up with the policy output, so the robot couldn't adapt or balance while walking. If you run into something similar once the power side is sorted, I'd be curious to hear about it.