I’m finally making progress with my ODrive project, lots of time to hack now that I’m “working at home”.
A good descripion of what I’m building is like a pick and place machine, but this will be some test equipment for work (eventually). I’m planning to use the ODrive for motor control, and do external motion control to feed it target positions, feed rates, etc.
While I noodle with this I’m just using an Arduino Due for the motion controller, it has lots of serial ports and plenty of memory, so I’ve got a big canvas to work. Might eventually move this to an STM32F micro of its own.
I’m using the ASCII protocol today (super easy to get started), and have looked at a native protocol implementation as well. I specifically don’t want to use step and direction, that seems silly when I can just send positions directly to the motor controller.
I’m somewhat mystified as to why the ODrive doesn’t have a command/protocol/whatever to say that it’s “done”; that is, it has caught up with position changes and all axes are now at their targets. I could poll the current position or velocity I suppose, but I’ve got to believe that knowing when you’ve reached your target, like a “wait for all axes to reach targets” API would already be there. I guess other applications like this have another feedback loop in the external controller that watches the motor’s current position, my motion control requirements are so primitive that I don’t need to do that.
… or is the right thing to do just to poll? I’ve been hacking commands into the ascii protocol to do what I want, then I’ll either re-implement in the native protocol or make someting special for my application, but somehow I think that I’m overdoing this.
Anyway, ODrive is neat and lots of fun to work with. A bunch of my colleagues at work are tinkering with theirs now.
Because that’s only available if you’re using the Trajectory Planner. By default, ODrive is never “done”. It’s simply going to do what it can to follow your target but there’s no guarantee it ever reaches it. With the trajectory planner (trapezoidal), you’re telling ODrive “Hey, I’m going to guarantee that this is an achievable path”. Then ODrive can set a flag that says it’s done.
I suppose you could set parameters that ODrive could recognize as “steady state”, like all values within some value of their target, but that doesn’t currently exist, sorry.
We don’t have a good way to setup flags for “send on event” or similar communication inside ODrive right now, unfortunately, so the best is to just poll.
Awesome, thanks – I totally get the “never done” part, all ODrive is trying to do is keep the actual position the same as the setpoint. That is never “done” even when you’re at your final position.
My project is kind of a cross between a CNC and pick-and-place (cartesian robot), and if it was only “move to x,y” the trajectory planner would be fine as-is. However, I do need my axes to be coordinated like a CNC, so the two trapezoid profiles sent to the planner should yield a relatively accurate linear motion as viewed from the effector.
I’m totally comfortable changing the firmware, it’s well-written and easy to modify. I’ve extended the ASCII protocol a little but will implement a new binary protocol shortly to meet my immediate needs.
I understand the basic concepts behind 2D trajectory planning but this is my first implementation (explains why my questions may seem naive). To that end, for the moment I’m basically implementing a trapezoid planner in an external micro and feeding setpoints to the ODrive from there.
Thanks for your help; this forum is a great resource!