Move_to_pos not works well

I have some trouble when I using position mode,
if I send a new command to odrive before last one complete
sometimes it will be occoured that the pos_setpoint not act as what i want
just like the picture below pos_setpoint sudden changed and my motor out of control

i set encoder.config.cal_range to 0.5 , is there any negative effect?
how can I prevent it?

I also have another question that how can I stop the motor when it running in position mode

can anyone help me to slove the problem?

Hey @zjqtzzc,
Can you give some additional information about your setup. I think to properly troubleshoot this we will need some general information about your setup. What kind of motors and encoders are you using? What kinda of mechanical load are you trying to move (pictures would be great)? How are you attempting to control the ODrive (Arduino controller, step/dir, or something else)?
If you haven’t already you need to tune your PID gains in order to change how the ODrive reacts to changes in your setpoint.

1 Like

thanks for you reply @robopilot99
C6374 motor (24V, 170Kv, 2800w, 60A, with 7 pole pairs)
omron E6B2-CWZ6C encoder (1024P/R, abz output)
with no load
I control odrive by using usb
The error occured in Trajectory control when a nearby position was given to odrive
the following was my setting details

In the screenshot with the plots you sent - what was your input?
It looks like it was holding at 12000 for a while and then you sent it to some other position (what position?) and before it arrived there you sent it to -8192. Is that correct?

Did you do anything else while it was moving?
How reliably can you reproduce the issue? Does it also happen when using the command line odrivetool?

It looks like it went from trapezoidal trajectory control into normal position control mode, thus hitting your controller.vel_limit of 40960.

encoder.config.cal_range does not affect the trajectory control.

Did you try lowering your PID gains? Your PID gains how hard the motor will try and push back to reach your setpoint. If it pushes too hard it will overshoot the setpoint and may begin oscillating until the ODrive’s safety features kick in. Try following the tuning procedure that I linked to in my first post.

Thanks for your reply.(forgive my poor English)
The input of the plot is move_to_pos(-8192). I sent it twice.
And each time I push the “go” button, it will also change trap_traj.config.
But I also can reproduce it on terminal.

the issue happened when I send several move_to_pos(TARGET) command.
if the previous is not complete and send a similar one (target is a same or near by position) ,
sometimes the problem will be occoured( It seems always happened on dec step, not 100%)

I think there are something wrong happend to change pos_setpoint to TARGET, vel_setpoint to 0.

By the way, is there any good idea to let the motor move along a irregular spline?
I tried to give odrive position frequently, but the issue above knocked me.

Ok I’m able to reproduce the issue reliably with

while True: odrv0.axis0.controller.move_to_pos(-8192)
# ... press Ctrl+C to exit loop

Interestingly the problem only seems to happen when moving in the negative direction.

I’ll have a closer look at this and let you know when I find out more.
Thanks for the report!

For your application, since you’re sending frequent setpoints, you can also set <axis>.controller.config.control_mode to CTRL_MODE_POSITION_CONTROL and then send position setpoints with <axis>.controller.set_pos_setpoint(...). Be sure to set <axis>.controller.config.vel_limit to a safe value first. You can also pass feedforward terms for velocity and current so you can technically run an arbitrarily fancy controller off-board.

There’s a numerical issue in the trajectory planner which leads to a variable becoming NaN which then causes a sudden jump to your final goal position.

If you’re comfortable with compiling the firmware yourself you can try out the hotfix/trajectory branch. Otherwise, there’ll be a hotfix release shortly.

1 Like

thank you, It help me a lot!

Fixed in firmware v0.4.12.

I had tested your branch and it works well!