Hey guys thanks for the very interesting discussion!
On replacing step/dir:
I completely agree that step/dir is garbage and needs to be replaced yesterday. Still, I need to support it for connecting to legacy motion controllers.
There are many ways the ODrives could speak to the outside world and to each other, but indeed I have been keeping my eye on CiA 402, as I know that is what’s used in industrial servo drives. Hence, many software stacks meant to interface with industrial servo drives speak it, such as ROS.
For reference, the intoductory paragraph of chapeter titled interpolated position mode on page 105 of the CiA 402 spec reads:
“The interpolated position mode is used to control multiple coordinated axles or a single axle with the
need for time-interpolation of set-point data. The interpolated position mode normally uses time
synchronization mechanisms like the sync object defined in /3/ for a time coordination of the related
drive units”.
Further the spec says you must implement linear interpolation of position over time. However, they allow for manufacturer specific modes, which is good if we want to have higher order planning.
They also specify a standard mechanism for how to check for tracking error (i.e. ability to keep up), and how to signal them and what should be done when one occurs.
By the way @Giornoxx, it is not standard to slow down or take any sort of intermediary recovery action at the master: suppose you are decellerating, and one of your axes goes into torque limit, what do you do? You can’t slow down, that makes it worse. Changing the trajectory plan to mitigate is too complicated for most applications. Usually the approach taken is to plan the trajectory with sufficient margin that a limiting condition should “never” occur, and any small deviation/error is servo’d by the individual axis.
On G-Code interpreter on ODrive
Conceptually we have in a robotics/motion system (both using ODrive only, or otherwise): High level motion commands -> motion planner -> motion controller -> motion primitives -> motion execution.
While there are many other options too, for the purposes of this discussion, the high level motion commands could be original (not split into 1000 lines) G-Code, and the motion primitives could be CiA 402 “interpolation points”, or step/dir signals from an existing controller.
As both @dlang and @wetmelon mentioned, it is unclear if the ODrive is trying to be just a servo drive or both the motion controller and a servo drive, and if so, how much effort will be spent on the motion controller and planning part. I am intentionally leaving this unspecified.
I will put in place a simple cubic trajectories planner and motion controller, and something that can read just the G1 command. The main reason to do just that is because it is required for very simple point-to-point movements for standalone applications and demos.
Beyond that, I think we can use the step/dir interface (for now) to interface to existing motion controllers, and get working systems up and running quickly. We can in the mean while spend our time with making the servo drive part of the project really good. Stuff like automatic tuning, ease of use, etc.
Then we can come back to this topic once machines are running.
That said, if there is any of you who are really interested in starting to work on any of the following this early anyway, let me know, and I can provide any direction you may need.
- Porting any G-Code interpreter
- Runnnig an interpreter on the host, and converting to other primitives, to be sent over USB
- Motion planning, in general
- Implementing/porting CiA 402
Thanks again for the well thought out and civil discussion. This is how I always hoped the forum would be like ;D