Synchronizing both motors


Hey Oskar, it seems from the second demo posted on the site that both motors move together in a coordinated way. Do you achieve this by sequentially issuing independent commands for both motors through USB, assuming that the delay is tiny?


From the source code the command is parsed by motor_parse_cmd() when received over USB, it sets the parameters of global data structure motors[]. Then I’m assuming motor threads read those parameters and execute motor motion

Would it be possible to synchronize both motors by having another command that sets parameters for both motors simultaneously?


This is the code that handles the position commands:

if (buffer[0] == 'p') {
    // position control
    int motor_number;
    float pos_setpoint, vel_feed_forward, current_feed_forward;
    int numscan =
        sscanf((const char *)buffer, "p %u %f %f %f", &motor_number,
               &pos_setpoint, &vel_feed_forward, &current_feed_forward);
    if (numscan == 4 && motor_number < Motor::getNumMotors()) {
        Controller::set_pos_setpoint(*Motor::getMotorByID(motor_number), pos_setpoint, vel_feed_forward, current_feed_forward);

The easiest way to have this handle both motors in one command is to create a NEW command that accepts values for both motors simultaneously. Alternatively, give it an X/Y coordinate and have some mapping from X and Y to motor0 and motor1. However, this won’t necessarily result in coordinated motion.

The “real” way to synchronize the motors is to plot a trajectory from the current position to the new position, then execute that. It’s something I want to do but I don’t have time for right now.


It would be great if there was a way to include a virtual axis in the control, to which real axis’ are synchronized, as is the case in real world motion controllers, but this would likely need to be a separate controller to provide this functionality.


So the correct way to do this is to use a trajectory generator and follower, as mentioned by @Wetmelon. This is a planned feature with quite high priority, as seen here.
The pen plotting demo did indeed use a coordinated trajectory tracker, but that was from an old code-base which won’t work directly here, and we want to improve it anyway.

Until the trajectory generator is completed, you can indeed send position commands to both M0 followed by M1, back-to-back. You will not get straight-line movement, nor any information about when the move is done; but the machine will go to the location you specified via some arbitrary path and by some arbitrary time.

To answer @JTRACKER’s question: The trajectory generator/follower sits separately from the individual motor controllers, and we would only want one of them to coordinated between multiple axis. So in the first instance we would make a single generator/tracker on the ODrive guiding the 2 axes.
However, there is no particular reason why we would be restricted to coordinating between two axes only, we could make it plot n-dimensional trajectories. We would then need to broadcast the trajectory parameters and trigger signals to other axes, to be tracked locally; or we track all axes on one board and stream realtime position set-points at a high rate.


So for my application of coordinating 6 O-drive axis, how would you suggest the application would be developed to run a Stewart platform? :wink:


ODrive Stewart platform sounds very badass! Is this for a person to ride on, like a simulator? ;D
I think the trajectory generator/follower is the way to go for pre-defined moves. Another way to do it is to have your host (say simulation software if that’s your application) stream position and velocity set-points to all the drives at some high rate, 100Hz - 200Hz or so.


Check this out :wink:

I’m going to be driving some linear actuators with your hardware, in lieu of large 3-phase motors or commercial servo motors. There are some quite costly BLDC actuators available, but will be fabricating the actuators myself.

I’ve been working on this project for years, but your project along with Thanos (look him up if you’re interested), Ian (@BFF) and Douwe (glider sim) have provided a ton of resources. These guys have provided significant direction and support to the DIY Flight Sim network.

I’ve worked on Flight Simulators while in the Air Force and spent 15 years in the industrial automation world while employed at Bosch. I love to bring my work home :slight_smile:

Thanks for the continued effort on this awesome new product.


Woah awesome!! Thanks for choosing to pioneer this with ODrive!
The motion controller that’s on that kickstarter should be compatible with ODrive through the PWM interface on ODrive v3.3 and newer.
The firmware for PWM input isn’t ready yet, but it should be quite easy to add; and we have the hardware timers (TIM5) on the GPIO pins ready for that on v3.3.


I only have 3 of the ODrive v3.2, so I will need to figure something out. Just getting into the details.
The motion controller has a servo interface option which provides +/- 10V command outputs to the drive.