Hi all,
I am undertaking a design project at the moment: https://hackaday.io/project/154264-rm1-an-affordable-industrial-robotic-arm
…that uses the ODrive to drive the six motors that form the basis for my robotic arm.
Previously my idea was to have each joint with its own independent PID controller, with each PID controller being fed continuous joint angle commands from an IK solver (requiring three regular ODrives). This will probably work just fine, but if possible, I’d like to implement a controller that offers better performance.
There are some papers (e.g. https://arxiv.org/pdf/1506.09084.pdf) that demonstrate model predictive control of robotic arms, which seems much better than what I’ve described above.
This control implementation would necessitate a 6-axis servo controller - i.e. a device that can read the outputs of six encoders, do some combined control computation, and output torque commands to the six corresponding motors at high frequency as part of its control loop.
At the moment, I don’t believe the current ODrive is capable of this (as most other servo drives aren’t), but is there any feasible way to redesign the ODrive without too many modifications to allow it to control six axes instead of two?
If anyone has any ideas on how I might be able to accomplish this, your comments are much appreciated.
Regards,
David
Hi,
I unfortunately have no idea about how to make that 3-in-1 odrive board. @madcowswe should have an idea.
however, i’m really interested in the outcome of RM1 that is basically something i’ve been willing to do for years. Can’t we live with 3 odrive boards in the mean time?
We made a robot arm with 3 odrives using ROS & MoveIt for IK. Seemed to be the fastest approach 
We made some handy functions to send odrive commands to multiple odrives: https://github.com/moorage/odrive_cpp_sdk –
Hi Alex/Alexis,
I will be using 3 ODrives for now…
I don’t think it’s worth doing fancy stuff till I have a proof-of-concept working.
@moorage
send a video. i want to see that arm flushin those toilets 
I can DM you or anyone a video on Discord 
– I’m matt#8971
Hi Moorage,
I am an Odrive noob, so forgive my lack of knowledge…
I take it the PC is running the IK solver - was that coded up in Python, and would you mind sharing what the functions did?
Cheers
Wire
I used MoveIt! In ROS on the PC, which has an IK solver.
Ah ok thanks! I did a project with the Kuka KR210 and it used moveit, but we had to write the IK solver for it. I can’t remember why, maybe it was the point of the exercise, after all it is also a 6DOF robot arm so I would have thought the built in solver could do it too. We did that in Python, was quite good fun!
So you can do all that with a few odrives, motors and a PC running ROS? Thats pretty cool.
Hi
I am at the stage of researching a build for a quadruped type robot, and came across the odrive platform as a potential low cost, high torque application. Is it possible to use Odrive to coordinate the movements between joints and control them with IK modules, or is extra hardware needed for that? This would be in relation to controlling the legs - I intend to have 4 lots of 3dof legs, each leg with a hip up-down, hip rotational and elbow joint.
Cheers
Wire
1 Like
It really depends on what you mean by “coordinate”. You can read positions and velocities and write torque in semi-realtime (less than 1ms delay) over USB. Is that sufficient?
@BrotherCreamy What is your latency requirement? I got 250us latency on reads from the ODrive over USB to a Windows PC in my tests. Is that sufficient to implement your central 6-axis controller? In that case you can do the control on a PC and send torque commands out to the ODrives.
If a PC is not realtime enough for this, then you may have to wait until we have CAN support ready.
moorage,
This is quite interesting. I can’t help but wondering what the robot arm is doing over the toilet.
I’m interested to know what kind of performance you achieve in terms of time from sending the motion request, to the motor windings being energised.
Also, what IK solver did you use? I was planning on using IKFast, but I wonder if Trac-IK is also decent? It’s completely new to me to be honest.
RM1 is intended to be a high speed, high precision arm, so these
Hi Oskar,
250us is really quite decent.
Just to double check, is that 250us the time taken from sending a command to receiving back the encoder position?
I think that should be enough, but still looking forward to seeing what kind of performance is achievable over CAN.
Yes, from executing the encoder read command to getting it back.
Okay, so it should be the same for sending a motion command, and receiving back an encoder value right?
Well the protocol doesn’t really work like that, right now it would take one unit of time to send the command and another unit of time to read the encoder value. There is plenty of room for optimization, but that’s what we have now.
Yeah no worries.
I’m sure 250us will be fine anyway.
I’m using MoveIt! In the future, I would want to investigate a GPU-powered one.
