Kinematics within the ODrive?


#1

I have been messing around with some SmartMotors from Animatics. They are pretty kewl. They are aware of each other so they are synchronized in movement. My ultimate implimentation for my Odrives is basically a delta printer. Can the Odrive do stuff like that? So instead of sending step-dir signals from my application i can have the kinematics built into the Odrive code? I am not even sure how I would start to do such a thing. Am I barking up the right tree?


#2

I think I understand what you’re saying. You want to be able to select “Delta” and “Move to point XYZ” and it just does it, right? And selecting “Cartesian” or “SCARA” would change the kinematic model and be transparent. That kind of functionality is planned for the future of ODrive, but it is not currently implemented.


#3

Thanks for the info. The second half of the question is. Are the motors aware of each other, for instance could we do gearing or camming. Like you could gear M0 to M1 @ a 2:1 ratio? And while gearing will the motors sync up and look at the encoders at intervals. I know that it could be done in software but has the hardware been lmplemented in a way that would make this possible at a low level. I am a hardware guy and am having a rough time with all this software. The thing is that I have been using step and direction for all of my projects up until now and never knew what I was missing. I have not had any problems with step dir but am realizing that I have pretty much just been lucky. So if I want to get to the next level I have got to get my head around this.


#4

Are the motors aware of each other

The motion controller should be aware that the motors must move together. This is how it’s done in industry, so that you can do stuff like this:

The PLC talks to the screen & tells the motion controller where to go & which motors to use as “synchronized motion”. The motion controller plans the moves & ensures that the motors are moving in a synchronized way. The Servo Amplifiers read the encoders and make sure each individual motor is doing what the motion controller says. Right now, ODrive is pretty much JUST a Servo Amplifier. It will eventually have PLC & Motion Controller functionality, so I expect to be able to replicate that video in the future.


#5

Are the motors aware of each other, for instance could we do gearing or camming

Could you give an example application for this? I don’t understand why the motors would have to be synchronized at all here.


#6

I think he means coordinated motion for axis transformation. For example move along a straight line with a SCARA linkage.

Some reference:
http://www.ormec.com/LinkClick.aspx?fileticket=1xw3v6XpQ4E%3D&tabid=145&mid=621

https://www.princeton.edu/~stengel/MAE345Lecture5.pdf


#7

Yep, That is what I am talking about. From my limited understanding. I have been using step and dir for controlling my projects which actually seems fine. I just want to get to the next level and also get a better understanding of motion control.
I have built a couple of delta robots and used RepRap. The math for the kinematics is done in the micro on the controller (Arduino, BeagleBone, Smoothie, etc…) none of those guys have any feedback from the motor drive. So. I am guessing that it is not as accurate as they could be with something that is aware of the position of the motors.


#8

Yep, we’re talking about the same thing. In the case of grbl, Marlin, TinyG, etc, that’s embedded in the product. In an industrial system, it would be a separate component called a “Motion Controller”. Some products such as the Parker “PAC” can be loaded with different kinematic models and it will solve the kinematics and disburse movement commands to each separate servo amplifier. The servo amp executes the move, and reports its position/velocity/acceleration back to the motion controller. The servo amplifier itself isn’t “aware” of the other motors, it simply responds to commands from the motion controller, which is itself responding to an End Effector position/velocity/acceleration command from the PLC or computer, etc.

See Thoughts on ODrive Architecture for my thoughts on ODrive’s possible architecture for handling this. TL;DR: I envision it as 3 separate modules, the PLC, the Motion Controller, and the Servo Amp. Each module could be enabled or disabled in software. If you want it to behave like a 3D printer controller, you enable all the modules and it’ll be just like using Smoothie (or something similar). If you want to just use ODrive as a powerful, inexpensive servo driver, then disable the PLC and Motion Controller modules.