“Cannot set motor position in mode c_int(1)”

Support & Troubleshooting Hardware
1

Hi everyone,

I’m working with an OpenSourceLeg setup (knee + ankle, Dephy Actpack) and I consistently get the following warning right after homing, when starting a simple position-control script:

WARNING: [knee][DephyActpack] Cannot set motor position in mode c_int(1) WARNING: [ankle][DephyActpack] Cannot set motor position in mode c_int(1)

Some context:

  • I’m using position control mode (set_mode(control_modes.position))

  • The warning appears right after homing, on the first position command

  • The motors do move afterward and track the trajectory reasonably well

  • I’m running on a Raspberry Pi, headless, using Python

  • Frequency: 200 Hz

What I already tried:

  • Explicitly setting position mode after homing

  • Adding a delay (time.sleep(0.2)) after set_mode

  • Calling multiple osl.update() cycles (warm-up) before sending the first position command

  • Re-checking the mode inside the control loop

Despite this, the warning still appears once at the beginning, then disappears.

My questions:

  1. What exactly does mode c_int(1) correspond to internally? (current mode? impedance init? safety mode?)

  2. Is this warning expected during the transition right after homing?

  3. Is there a recommended or “official” way to arm the position controller before sending the first set_output_position()?

  4. Is it safe to ignore this warning if the motors subsequently behave correctly?

Any clarification on the internal state machine of the Dephy Actpack / OSL firmware would be really appreciated.

Thanks a lot!

2

Hi @mioki

Can you share a minimal error script ?

I did not get this warning when using the OSL. I would suggest to not ignore it and to try fix it first.

3

image
image1280×210 85.2 KB
sure, thank you

4

Can you share the script in its minimal version ?

5

“”" A basic motion script that moves the osl joints through their range of motion. This script can be helpful when getting started to make sure the OSL is functional.

Kevin Best Neurobionics Lab Robotics Department University of Michigan October 26, 2023 “”"

import numpy as np

from opensourceleg.osl import OpenSourceLeg from opensourceleg.tools import units

osl = OpenSourceLeg(frequency=200) osl.add_joint(“knee”, gear_ratio=9 * 83 / 18, port=“/dev/ttyACM0”) osl.add_joint(“ankle”, gear_ratio=9 * 83 / 18, port=“/dev/ttyACM1”)

def make_periodic_traj_func(period, minimum, maximum): amplitude = (maximum - minimum) / 2 mean = amplitude + minimum return lambda t: amplitude * np.cos(t * 2 * np.pi / period) + mean

ankle_traj = make_periodic_traj_func(10, -20, 20) knee_traj = make_periodic_traj_func(10, 10, 90)

with osl: osl.home() input(“Homing complete: Press enter to continue”) osl.knee.set_mode(osl.knee.control_modes.position) osl.ankle.set_mode(osl.ankle.control_modes.position) osl.knee.set_position_gains(kp=5) osl.ankle.set_position_gains(kp=5)

for t in osl.clock:
    osl.update()
    knee_setpoint = units.convert_to_default(knee_traj(t), units.position.deg)
    ankle_setpoint = units.convert_to_default(ankle_traj(t), units.position.deg)
    osl.knee.set_output_position(knee_setpoint)
    osl.ankle.set_output_position(ankle_setpoint)
    print(
        #"knee_case_temp {:.2f} deg C, knee_winding_temp {:.2f} deg C, ankle_case_temp {:.2f} deg C, ankle_winding_temp {:.2f} deg C, " \
        "Ankle Desired {:+.2f} rad, Ankle Actual {:+.2f} rad, Knee Desired {:+.2f} rad, Ankle Desired {:+.2f} rad".format(
            #osl.knee.case_temperature,
            #osl.knee.winding_temperature,
            #osl.ankle.case_temperature,
            #osl.ankle.winding_temperature,
            ankle_setpoint,
            osl.ankle.output_position,
            knee_setpoint,
            osl.knee.output_position,
        ),
        end="\r",
    )

print(“\n”)

6

Thanks @mioki

  1. Next time try to use the formatting tools form the forum to share the code to make it easier to read. I had to get it into my own IDE instead of just looking at the forum
  2. Minimal error script means that you need to remove everything that is not necessary to get your error. For example here you could have remove the prints. → More infos here: https://stackoverflow.com/help/minimal-reproducible-example

Otherwise I think the problem come from the lines:

osl.knee.set_mode(osl.knee.control_modes.position)
osl.ankle.set_mode(osl.ankle.control_modes.position)

If you look at the basic example provided in the repository (opensourceleg/examples/basic_motion.py at main · neurobionics/opensourceleg · GitHub):

It should be

knee.set_control_mode(CONTROL_MODES.POSITION)
ankle.set_control_mode(CONTROL_MODES.POSITION)

Check also the version of the opensourceleg library that you are using and of flexsea (the Dephy actuator package)

7

Thanks a lot for the clarification and for pointing me to the official example — I really appreciate it.

Just to give a bit more context on why I ended up using that specific code: the script I posted is actually based on an example that was shown to us directly by the CEO of Humotech when he brought the Open Source Leg 2.0 to our lab. For that reason, I assumed it was a “safe” and up-to-date reference, but I now realize that the API usage may have evolved, which is where part of my confusion comes from.

At the moment, my main difficulty is understanding which signals and interfaces are the correct and recommended ones to use, especially because my final goal is dynamic parameter identification. In particular, I need reliable measurements of:

  • joint position qqq

  • joint velocity q˙\dot{q}q˙​

  • joint acceleration q¨\ddot{q}q¨​ (offline estimation is fine)

  • joint torque τ\tauτ

Currently, I am logging signals like this:

# Measurements
qk  = float(osl.knee.output_position)
qa  = float(osl.ankle.output_position)

qkp = float(getattr(osl.knee,  "output_velocity", np.nan))
qap = float(getattr(osl.ankle, "output_velocity", np.nan))

tau_k = float(getattr(osl.knee,  "joint_torque", np.nan))
tau_a = float(getattr(osl.ankle, "joint_torque", np.nan))

ik = float(getattr(osl.knee,  "motor_current", np.nan))
ia = float(getattr(osl.ankle, "motor_current", np.nan))
However, I am honestly not 100% sure which of these quantities are:

directly measured vs internally estimated

intended to be used for system identification

reliable enough for inverse dynamics regression

That’s also why the initial warning confused me: I wasn’t sure whether it was just a transient state-machine issue (which now seems likely), or a symptom of using the wrong control/measurement interface.

Any guidance on:

the recommended signals for identification

how joint torque is computed internally (current-based, model-based, etc.)

best practices when using OSL + Dephy Actpack for offline dynamics identification

would be extremely helpful.

Thanks again for your time and for the help — it’s really appreciated.
8

Hi @mioki

I would suggest that you open a dedicated post for this matter. Keeping the forum organized help everyone finding the information needed :wink: