Looking at the documentation, I’m getting the feeling that configuring an automated startup homing sequence for a multi-turn axis isn’t possible using an Odrive system. I can’t imagine I am the only one that needs a system like this though, so I am creating this post as a last resort that I am hopefully misinterpretting the documentation.
I have the following specs in my system:
Odrive Pro (V 0.6.11)
M8325s Motor
AMT212B-OD absolute incremental encoder with RS485 capabilities (I actually don’t think this is a multi-turn encoder, but I wanted to make this post before I buy one)
My goal is as follows: I have a motor that is configured to spin two full rotations in the clockwise and counterclockwise directions. I am controlling this motor using position control, and would like the following behavior:
The motor loses power when the position is, as an example, 1.4 turns in the clockwise direction
Reboot the Odrive motor
The Odrive motor automatically spins in the counter-clockwise direction 1.4 turns to get back to the zero position
Has anyone implemented anything like this? Obviously the encoder itself won’t store the total counts, but is there a way to save the counts directly on the Odrive Pro to be able to return to the true zero position?
Hi! This is actually a surprisingly tricky problem. There’s no native functionality to store the turn count on the ODrive, as writing to the internal nonvolatile memory locks the application thread, so there’s no way to ensure there isn’t any movement after the memory write starts. And of course, there’s also no way to ensure there isn’t any movement when the ODrive is powered off. Systems that need to track turn count even while powered off usually require something like a battery backup multiturn encoder, which are expensive, and come with their own problems (typically a maximum speed limitation while powered off, and limited battery life).
Three options:
If you’re completely confident that there will be absolutely no movement while powered off, and you know when the system will be powered off, you could read the turn count and save it to one of the ODrive’s user storage properties. However, note this will take a few seconds to save and require running save_configuration(), which requires the ODrive to be in the IDLE state, and forces an ODrive reboot after saving. Additionally, the ODrive has a limited number of write cycles (around 10,000 at 25°C ambient), so this may not be suited for an application that requires a very long lifetime/number of reboots
Of course, if this is connected to e.g. a gearbox or a linear gantry system, you could just use an endstop, and use the ODrive’s onboard endstop homing. Alternatively, if there isn’t room for an endstop, but your application has a hard stop that you can safely drive the motor into at some limited/reduced torque, you could write a homing routine to move the motor in velocity control with some low velocity setpoint until you see a current spike (corresponding to the mechanism hitting the hard stop), at which point you can write the zero position.
If you can’t use an endstop, you could connect a multiturn potentiometer to the shaft (or a singleturn through a gear/belt reduction), and connect it to either your ODrive through the analog input pins, or your motion controller (whatever’s commanding the ODrive). From there, if you enable the absolute encoder reference frame (which initializes the ODrive position to the encoder’s 0-360° count), you could read the potentiometer data and use that to determine the turn count to supplement the encoder’s high resolution 0-360° position.
If your motion controller has a SPI or I2C output, you could add an external FRAM IC (a form of expensive yet very fast to write nonvolatile memory), and write the turn count at some speed greater than 2/60 * max_rpm, where max_rpm is the highest speed your motor will ever spin when the ODrive is powered on. Then if you detect the ODrive has lost / regained power, you can write the saved turn count, similar to option (3). However, this will of course not cover the situation where the motor turned more than 0.5-1 revolutions when the mechanism was powered off.
If I were designing a system with these requirements, I’d definitely see if I could add an endstop or hard stop so that I could just run a homing routine on startup, like in option (2). If that’s not possible, I’d pursue option (3). We do have a customer who uses option (4), but this is only possible in situations where no (or very limited) rotation is possible when the motor is powered off, e.g. if you have the motor connected to a worm gearbox, leadscrew, electric brake, or other non-backdrivable mechanism.
Please let me know if any of these options will work for you, or if there’s any other questions I can help answer!
Option 3 is intriguing and a potential solution for our system. We ultimately decided to add another gearbox between our component and our encoder so with an appropriate ratio so the encoder only ever does one rotation, thus meeting the ± 1/2 turn requirements. This way, even though our component will be spinning multiple rotations, from the encoder’s perspective we won’t have to worry about multi-turn.
I just thought I would share this other potential solution in case someone is browsing this forum in the future and has a similar system.