Where are the trajectories?



I was waiting to see my odrive board functionning… and finally it seems to work. fingers crossed. :smiley:

In the past, I have used some pretty classic steppers from arduino with step/dir commands to move two steppers in parallel.

In order to better use my motors, instead of linearly sending steps (basically use a fixed delayMicroseconds(us) between steps, ex: 200us ), I have designed a simple math model calculating “how much time should I wait between steps” to have a much smoother acceleration and decelleration. (prevent missed steps, go faster, and move more weight)

Typically, from what I understand, when i send to odrive
p 0 1000 0 0
The first motor will make 1000 steps in a linear fashion

I would like to get similar acceleration/deceleration functionality with odrive. But i’m puzzled about how i should implement it.

  • should i code it directly in the odrive fireware ? => I beleive it’s where this code would belong. but unfortuntately i am really uncomfortable with odrive source code and brushless motors principles generally speaking)
  • so maybe i can fall back to fast clocked arduino-like platform (ex: chipkit maybe?) and use odrive step/dir interface to send steps one by one with the right timing between steps. => it’s a bit ugly/clumsy but i think i can do it.
  • should i use some raspberry pi to send p commands through usb by small chunks of x steps with increasing speed until i have the right count of steps? (then race between steps per commands and usb communication speed?)
  • or should i sponsor someone for the code to be implemented in odrive since i seem unable to code it myself ?

How do you suggest I proceed ?


I’m not sure I entirely understand what behavior you would like to achieve, but let’s make sure we’re on the same page as far as current functionality is concerned.

At the moment, if you send the command p 0 1000 0 0, motor 0 will use a cascading PI controller to move from its current position to the position 10000, which is represented as encoder pulses. This generally results in the highest current appearing at the beginning of the move, as the Proportional term is greatest at that point. Sometimes, this results in significant overshoot.

This is not an acceleration controlled movement. For an acceleration controlled movement, you need to change how the ODrive responds to position requests by creating a trajectory and tracking it with the position and feed forward terms (the last two 0’s in the position command). This is a planned functionality.

Right now, the best way to achieve this is probably to use a CNC controller (RAMBo, Smoothie, Yaskawa, etc) and feed ODrive the PULSE and DIRECTION pins as if it were a stepper motor driver. The # of encoder pulses per step is already configurable in the firmware.


Hi @alexisdal,
Thanks for your persistence with your ODrive, and I’m glad you are looking to take the functionality to the next level.
Let me take some time to explain how the ODrive is working right now.

This is not quite correct. When you send that command, you are simply telling the ODrive: Try to be at position 1000 NOW. This is an absolute position coordinate, so it will not make 1000 “steps” if it is already at position 1000. Also, since it tries to be there NOW, it will try as hard as it can to get there, it won’t go there linearly (constant speed). Like @Wetmelon demonstrated, the trajectory it takes depends on your tuning, but is generally more aggressive acceleration at the start and then a smooth slowdown.

A planned motion, with acceleration/deceleration, is called a planned trajectory. We intend to make a sinusoidal velocity profile planner/tracker, see here. If you simply wish to wait for us to finish this, you can subscribe to that issue. It is not the highest on our priority right now, though if you would like to sponsor this feature, we can bump it up in priority :wink:.

Diagram of some different velocity profiles.

If you would like to implement our planned trajectory feature, or your own, let me know and I can guide you to where it makes sense to put it in the code. Otherwise, either of your other suggestions should work:

  1. Use an external trajectory planner on an arduino-like platform, and send step/dir signals. @Richard_Parsons has some experience with this, and should be able to give more detailed advice.
  2. Use your PC or a raspberry pi to send p commands at a fast rate. Though it wouldn’t be with increasing speed, it can be constant speed: since the p command is absolute. To move in a linear velocity profile with motor 0, you should send something like this (in this example every 100ms):
    • p 0 0 0 0 (no movement)
    • p 0 0 1000 0 (start of move here)
    • p 0 100 1000 0
    • p 0 200 1000 0
    • p 0 300 1000 0
    • p 0 400 0 0 (end of move here)
    • p 0 400 0 0 (no movement)
  • As you can see the second parameter is the absolute position, and the third parameter is the velocity. You can ignore the 4rd parameter for now


thanks to you both. you hit the nail right on the head. I simply wasn’t aware of the vocabulary of a “trajectory” but it’s exactly what i had in mind.

Before i can sponsor or even code myself anything related to trajectories (be it in the code of odrive or otherwise), i first need to build a working prototype without it.

so it then becomes a timing issue: will i make an prototype exploiting odrive before the odrive firmware implements trajectories?

for now i’ll just wait and see.

thank you very much for your explanations