Clarification on STS3215 Motor Specs in BOM

[redEddie]

Hello! Thank you for sharing this amazing project. I'm currently building the openduckmini and having a great time with it.

I have a quick question regarding the BOM. I noticed that the STS3215 motor is listed, and I ended up using the STS3215-C001 version. However, I'm experiencing an issue where the motor speed is too slow to maintain a proper gait.

Upon checking the hardware limits, the C001 model (1:345 gear ratio) seems to max out at around 2.7 rad/s. It looks like the motion requires a target velocity of around 5.24 rad/s, which my current setup physically cannot reach.

I was wondering if the BOM originally intended for a faster variant, such as the C046 (1:147) or C044 (1:191), instead of the C001?

I wanted to politely check if there might be a minor omission in the BOM regarding the specific sub-model, or if I am perhaps missing some software configuration that allows the C001 to work.

Thank you again for your hard work and contribution to the community!

[zykuzmanov-code]

I am facing the exact same issue. I just placed a back order for 15 units based strictly on the BOM note ('7.4v ones, also called 19kg.cm'), which points directly to the C001 in retail stores. Can the maintainers clarify immediately if the C001 will be supported via a software update/slower gait, or if we absolutely must change our hardware orders to a faster variant like C044?

[redEddie]

Looking at videos from people building OpenDuck Mini on YouTube, I can see several of them using the 1:345 gear ratio version, so my guess is that the BOM is probably correct.

Also, considering that the project owner identified and published the motor model through BAM, it seems unlikely that the specific gear ratio would have been accidentally documented incorrectly.

My feeling is that there may be something else going on besides the gear ratio. That said, at least both of us here are observing lower-than-expected motor speeds, so there does seem to be a genuine issue that merits further investigation.

[redEddie]

I did a more detailed comparison between the policy commands and the measured joint trajectories over one gait cycle.

For each joint, I computed the motion range

Δ = max - min

and the tracking ratio

Δratio = actual Δ / commanded Δ.

The commanded ranges are identical between simulation and hardware because both runs use the same policy checkpoint and reference.

Joint	SIM cmd min..max (Δ)	SIM actual min..max (Δ)	SIM Δratio	REAL cmd min..max (Δ)	REAL actual min..max (Δ)	REAL Δratio
left_hip_roll	-0.10..+0.16 (0.26)	-0.13..+0.19 (0.32)	1.21	-0.10..+0.16 (0.26)	-0.10..+0.16 (0.27)	1.01
left_hip_pitch	-1.01..-0.64 (0.37)	-1.00..-0.67 (0.33)	0.89	-1.01..-0.64 (0.37)	-0.84..-0.70 (0.14)	0.37
left_knee	+1.10..+1.79 (0.69)	+1.15..+1.60 (0.45)	0.65	+1.10..+1.79 (0.69)	+1.20..+1.50 (0.30)	0.44
left_ankle	-0.85..-0.53 (0.32)	-0.86..-0.56 (0.31)	0.95	-0.85..-0.53 (0.32)	-0.70..-0.55 (0.15)	0.46
right_hip_roll	-0.20..+0.05 (0.25)	-0.22..+0.06 (0.28)	1.11	-0.20..+0.05 (0.25)	-0.19..+0.06 (0.24)	0.97
right_hip_pitch	+0.69..+1.09 (0.40)	+0.69..+1.02 (0.33)	0.81	+0.69..+1.09 (0.40)	+0.69..+0.84 (0.14)	0.35
right_knee	+1.20..+1.97 (0.76)	+1.24..+1.60 (0.36)	0.47	+1.20..+1.97 (0.76)	+1.25..+1.49 (0.24)	0.31
right_ankle	-0.94..-0.58 (0.36)	-0.90..-0.59 (0.31)	0.85	-0.94..-0.58 (0.36)	-0.76..-0.58 (0.18)	0.49

The most interesting observation is that the hip roll joints track the commanded motion almost perfectly on hardware (Δratio ≈ 1.0), while the hip pitch, knee, and ankle joints only achieve about 31–49% of the commanded motion range.

For example, the right knee is commanded to move from 1.20 rad to 1.97 rad (Δ = 0.76 rad), but on hardware it only moves from 1.25 rad to 1.49 rad (Δ = 0.24 rad, Δratio = 0.31).

This behavior is still present when the robot is unloaded and suspended off the ground. In simulation, the same policy produces enough foot clearance for walking (~12–15 mm), whereas on my hardware the feet barely leave the ground.

Based on these measurements, my current conclusion is that several joints are not reaching the motion amplitudes commanded by the policy.

It would be very helpful if others could log and compare the policy outputs against the measured joint positions on their robots. That comparison may help determine whether this behavior is specific to my setup or a more general issue.

[zykuzmanov-code]

I took a closer look at both the Open_Duck_Mini and Open_Duck_Mini_Runtime repositories to understand where the 5.24 rad/s value comes from.
From what I found:

1. The walking stack (PlacoWalkEngine) generates joint positions, not joint velocities.
2. The real robot interface sends position commands to the motors ("write_goal_position" / "set_position_all"), not velocity commands.
3. In "v2_rl_walk_mujoco.py", there is indeed a "max_motor_velocity = 5.24" rad/s parameter.
4. However, the velocity clipping code associated with this parameter appears to be commented out.
5. The runtime currently seems to operate in position control mode rather than explicit velocity control mode.

Because of this, it is not entirely clear whether the 5.24 rad/s value is an actual hardware requirement or simply a leftover simulation/training parameter.

Thanks for the project and for any clarification.