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.
that sounds like a good starting point.
David Lang