Ideas for Next Version: Batteryless Encoder Count Retention, Integrated Safety


#1

Hi all,

Just had a couple of ideas for new features for ODrive v4, and wanted to see what people think:

  1. Batteryless Encoder Count Retention
    This is fast becoming a standard feature in most commercial industrial servos. As I understand (though I may be wrong EDIT: the following is probably incorrect ), a supercapacitor is used to power the encoder and thereby maintain the encoder count during power down and drive reset conditions. This would mean we no longer have to worry about selecting an absolute encoder for applications where homing is not an easy process (e.g. robotic arms). This also addresses the multi-turn issue. I think this feature would improve the standing of ODrive significantly when compared to commercial hardware. I’m not sure exactly how this would be implemented, but I imagine the supercapacitor would power only the encoders and an auxiliary microcontroller that is used to keep the encoder counts (including as many turns as possible with the remaining bits).

  2. Integrated Safety
    All commercial servo systems include integrated safety features that comply with relevant industry standards. As ODrive gains popularity, and is used to drive higher power motors, the need for integrated safety becomes more and more important. This wouldn’t have to be anything complex… I think the standard is just two Safe Torque Off inputs for a servo drive.

Please let me know what you think of these ideas.

Regards,
David


#2

the TODO list of odrive feels pretty packed already
those ideas make a ton of sense.
Somehow to move closer to industrial servos, we will need some “maker-oriented” gearbox.
ok. ok. i know it’s nothing odrive can deliver.
that said, something you could make with a simple cnc milling machine to trade speed for torque will be mandatory in many applications. I think a harmonic drive is likely too complex/precise to make. Same for planetary gears. Belt systems do work (gt2 is a great) but is not as compact as a gearbox.
A cycloid drive (like this one) feels doable.


#3
  1. it’s not a matter of powering the encoders, but rather powering the chip and/or storing the encoder positions in eeprom/flash to later survive power off.

I question the value of this as a general item due to the fact that in most cases, the motor can be back-driven (turn the wheel manually, pull/push the thing being positioned by the motor)

to continue to track changes in position, you would have to have some chip powered all the time to watch the encoders. That’s more than a supercapacitor can easily do.

  1. what are the “relevant industry standards” that you are suggesting that ODrive comply with?

#4

Thanks for your reply David.

Regarding the encoder count retention:
I was in fact suggesting a means of tracking encoder position/count during power down. Most industrial robots that use incremental encoders use batteries to power the encoders so that encoder counts are maintained during power down. I was hoping that a supercapacitor would suffice to replace a battery in this application, but reading through the AS5311 and AMT102 datasheets, I realise that current requirements for these encoders (16 and 6mA respectively) are too high for a small PCB mount supercap. Realistically, you could use a 2500mAh 3.7V LiPo battery, that might get you a few days of runtime, but that’s not as elegant a solution as the supercap might have been (which would only power an AS5311 for a few minutes as it turns out). I was really hoping for a way to use the AS5311 in my robotic arm project, without having to rehome every time the encoders lose power. If only there were a super low current encoder similar to the AS5311.

Regarding safety standards:
I believe the relevant ISO standard is EN ISO 13849-1. I’m not saying ODrive should comply fully with the standard, but it would be useful to integrate some kind of safety functionality into the hardware that takes its design from commercial servo systems (because the design is well thought-out and field-proven).


#5

I see two solutions.

  1. Keep the ODrive logic power rail online (with an externally fed source) while powering down the main drive voltage. This you can do today, and the ODrive will keep counting. The axis will go into DC undervoltage error, but you can just clear the error when you bring the drive voltage back up, and you are good to go.
  2. Use a batteryless multiturn absolute encoder. Yes they solve your exact problem. They are actually not ridiculously expensive either, on the order of $50-$70 IIRC.

What are the requirements here? I assume it’s not reliable enough to just sample a pin in software and turn off the drive if it’s asserted?
There is actually a hardware line offered in the STM32 for putting the drive into a safe state, but it’s not available on ODrive v3 due to pin conflicts. I can make a note to make it available in ODrive v4.
EDIT: today you could also pull the ODrive’s reset line low, that will torque off the drives with hardware certainty.