Hi everyone, I’m the lead developer of the ODrive project.
ODrive is a closed loop controller that can drive 1000W brushless motors with high precision using encoder feedback. The single board can control two motors. Here it is on my LitePlacer:
So I’m checking in to see if anyone’s interested in sticking these kind of motors on their Maslow? Obviously you don’t have to use all of the 1000W per motor, but even at a fraction of that it should provide a very decent speed upgrade.
I saw that the Maslow controller is Arduino based, and I went and had a look at the source. I think it should be quite straightforward to use the ODrive Arduino library that connects to the ODrive via UART. This library makes it easy to send position setpoints, just like this: odrive.SetPosition(motor_id, position);.
This could be substituted in here in the Maslow code.
If anyone is interested, or has questions or comments, I’d love to discuss or help as much as I can!
I have one of your controllers and am interested. One issue is that the maslow
reuires that the motors not move when things are shut down (or you have to go
through a calibration step to know where you are)
Maslow does this by having a worm gearbox between the motor and the output shaft
so that pull on the chains cannot back-drive the motor and change it’s position.
we want ~4000-8000 steps/rev on the encoder, and I have some 1000p/r encoders
that I could use for this, or the encoder can go before the gearbox.
The stock maslow produces 30Kg/cm of torque, but at slow speeds (30 rpm or
under)
right no, the maslow software does no acceleration planning. We really need to
copy the grbl g-code parser and movement planning software and then change the
output to drive DC motors instead of steppers. Especially with the high speeds
and high power that the odrive supports, this would become critical.
The other problem we would have is how to coordinate the odrive controlled
movement with the Z-axis movement (which is currently another brushed DC motor,
but could be replaced by a stepper and gearbox, it doesn’t need nearly the
speed, power, and resolution of the main motors)
I’ve posted thoughts on how to keep multiple controllers in sync with each other
before (here and on your forum)
Hello Oskar, welcome! I’ve watched your project and I’m impressed with the support and the community there.
One difference about the Maslow machine is that the workarea is vertical, so the motor-gearbox assemblies must support the router in place when no power is present. I guess that a suitable gearbox could be fitted, though that very nice speed of the ODrive motor-encoder would be reduced.
At present, the Maslow kinematics uses the encoders to calculate the value to send in the code you cite. We might need to look for a different point in the flow to communicate to the ODrive.
I hope that members more knowledgable with the Maslow firmware chime in on this interesting possibility.
Hi @dlang, nice to see you here too!
Yes I see the issue with the vertical load, and calibration. I see two possible approaches:
Count the turns when offline. This is possible on encoders like these ones, that have an energy harvesting magnetic device that can take enough energy from the rotor moving to record its movement. A bit pricy though at $75 each.
Lock the rotor when offline. Worm gear boxes are probably the best approach here, since they achieve the locking required, and also provides a large reduction at the same time.
Yes putting the encoder before the gearbox seems like a sensible solution, then any encoder will do. Also commutating the motor stays straightforward.
We just need to find a gearbox that is correctly dimensioned for the speed/torque/reduction that an ODrive motor setup would use. I would derate the torque in the ODrive Motor Guide by factor 3 to factor 6, since it will need to support a static load, which is particularly demanding in terms of heat in the motor. There were some inexpensive planetary gearboxes mentioned here if we would need that on top of a worm gear.
With regards to motion planning and GRBL, there is some similar work being started for use with ODrive, see this post. I assume you are proposing to do the Maslow motion planning in Cartesian space, and then project the velocities onto the chain direction vectors?
Coordinating Z-axis movement is actually completely straightforward with the integration that I propsed: no further action would be required. This is because the level of integration would be at the motor-control level, not at the motion-control level. That is, instead of sending “go to this position” to the ODrive, and sending some position that is the end of a line segment; we would be still running the motion control on the Maslow controller, and this would generate realtime position setpoints. Currently the Maslow does this but sends the realtime setpoints of the X,Y and Z axes to internal PID controllers. We would just substitute that for sending the X and Y offboard to ODrive, but still send the Z one to the onboard motor controller. With 115200 baud UART we can easily hit 200Hz setpoint rate, and higher with higher baudrates.
@blurfl: So actually you can just as easily query the ODrive for the current encoder position. Though from my experience, usually it is a bad idea to compute trajectories or kinematics based on current position, instead using the previous commanded position is better. I can elaborate on that if you want.
Thanks for the quick reply. I found the section of the manual that details querying for encoder position. An amazing variety of information available over that interface!
Hi @dlang, nice to see you here too!
Yes I see the issue with the vertical load, and calibration. I see two possible approaches:
Count the turns when offline. This is possible on encoders like these ones, that have an energy harvesting magnetic device that can take enough energy from the rotor moving to record its movement. A bit pricy though at $75 each.
Lock the rotor when offline. Worm gear boxes are probably the best approach here, since they achieve the locking required, and also provides a large reduction at the same time.
Yes putting the encoder before the gearbox seems like a sensible solution, then any encoder will do. Also commutating the motor stays straightforward.
We just need to find a gearbox that is correctly dimensioned for the
speed/torque/reduction that an ODrive motor setup would use. I would derate
the torque in the ODrive Motor
Guide
by factor 3 to factor 6, since it will need to support a static load, which is
particularly demanding in terms of heat in the motor. There were some
inexpensive planetary gearboxes mentioned here
if we would need that on top of a worm gear.
the motors are not facing a static load if they have a non-backdrive gear
besides the worm gear, another interesting option would be a cyclonic gearbox,
they also give you high reduction without backdrive
With regards to motion planning and GRBL, there is some similar work being
started for use with ODrive, see this
post.
I assume you are proposing to do the Maslow motion planning in Cartesian
space, and then project the velocities onto the chain direction vectors?
That seems to be the place to start at least. Evenually we will need to replace
the simple acceleration limits with something far more complex (taking into
account the different gravity vectors involved in different areas, and the
simple fact that motors can apply more than 1G of force, so the force available
to accelerateis different in different directions.
Coordinating Z-axis movement is actually completely straightforward with the
integration that I propsed: no further action would be required. This is
because the level of integration would be at the motor-control level, not at
the motion-control level. That is, instead of sending “go to this position” to
the ODrive, and sending some position that is the end of a line segment; we
would be still running the motion control on the Maslow controller, and this
would generate realtime position setpoints. Currently the Maslow does this but
sends the realtime setpoints of the X,Y and Z axes to internal PID
controllers. We would just substitute that for sending the X and Y offboard to
ODrive, but still send the Z one to the onboard motor controller. With 115200
baud UART we can easily hit 200Hz setpoint rate, and higher with higher
baudrates.
Okay, but even going very slowly upwards you would need to apply the torque equivalent to the sled’s weight. Kind of like pseudo-static load, when going upwards.
The 370 is a standard motor size in RC, so finding a high-powered brushless motor that fits the gearbox should be trivial. You can get brushless motors with shafts at both ends, too, so the fitting of the encoder should be possible with the wormbox. What may be problematic is a 6mm shaft, but not insurmountable - most high-powered brushless motors are on a 5mm shaft.
As the only component of the gearbox affected is the worm itself, it should probably be reasonably easy to source a 5mm shaft worm gear instead of a 6mm one
Edit: a quick search returned worm gears with a 5mm bore in any combination you could imagine, so it looks like it would not be much of a stumbling block.
Instead of GRBL it might be worth looking at Smoothieware or TinyG2 and going to one of the inexpensive ARM boards. GRBL’s focus has been wresting more out of a 328 than anybody thought was possible (I know they’re working on a 2560 fork, but that’s showing it’s age too) but low end microcontroller hardware has passed it by. I know G2 does higher order acceleration planning (not sure about smoothie, but Arthur has a way of finding discussions and popping up), but I’m not sure how helpful that is with closed loop devices. Really need to learn more about servos. Guess I could ask Art Fenerty (edit, was somebody in another forum, my bad) about it.
Hard to know you have a difference of opinion when I’m not even sure what the subject is… I find it’s always useful to ask.
Never had any involvement with closed-loop, servos, or any such devices. My motion-contol experience is lengthy, but conservative, much like my men
Ive only run a couple of grbl devices for my diy stuff - I went straight to TinyG and Smoothieboard and yes, Smoothieware is all about intelligent forward planning
So back on topic: For now we should be fine without any acceleration planning and just let the feedback controller deal with the velocity discontinuities. I think you would have to turn it up really fast for any problems with insufficient gravity to keep the tool in place.
The main thing that needs to be sorted out, I think, is to find a suitable gearbox and mechanical arrangement. @Zootalaws had a nice suggestion, though I think maybe we’d want something a bit larger? Not too sure though.
The ODrive board could technically be made to run brushed DC motors, but it’s really not meant for that to be honest. It would be a bit of a waste of capability, there are cheaper brushed DC controllers out there.
I think it would be interesting if the Odrive would be availble for single motors
this way it would be possible to mount the controller next to the motor, keeping the powerlines short.
Then only connect (shielded) data lines to the drivers from a Maslow controller board. (could this be done via CAN-bus?)
Also for the Zaxis
Not sure if this could be kept within a limited budget. As it looks like the deal breaker would be the price. With the Odrive. Maybe not when scaling up one step… Hmmmm
The main issue with this compared to the current ODrive is that the price is higher, since it can’t share some of the components between two motors, like the processor, connectors, etc.
I’m pretty new to this type of system, but instead of reducing speed by using a worm gear and holding the chains in place, would it be possible to just use a known starting point. Maybe a sensor or microswitch placed at the bottom or a resting cradle? With that, the controls would always know where they where and chain position would not have to be locked when off.
Again, noob to this kind of CNC system so maybe there is an obvious reason why this wouldn’t work.
unfortunantly we are already seeing problems with this.
It’s not a problem with the router not staying in the wood, but when you are
near the bottom left corner, the left chain gets to 80 degrees (10 degrees
from vertical), and when you want to move left and the right chain loosens, you
only have 17% of your sled’s weight available to move you to the left. This
includes the force needed to overcome friction to start moving. We are seeing
some cases where friction is large enough to cause problems, let alone any
desire to accelerate any faster.
