Just had a couple of ideas for new features for ODrive v4, and wanted to see what people think:
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).
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.
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.
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.
what are the “relevant industry standards” that you are suggesting that ODrive comply with?
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).
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.
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.
Complete Odrive noob here, only discovered it <24hrs ago.
This is my first post and I am replying to this thread because this is the first thing that I considered.
It would be really neat if Odrive supported BiSS C. These are still incremental encoders that retain their count. When power is restored to the controller, it can grab the encoder’s count…a bit like SPI.
Regarding safety; it’s been a while since I got in to this stuff but I think that the general consensus (if not a rule) is that one should not rely on a semiconductor input to remove power to an actuator.
We always put an actual contactor on the motor power lines that was maintained by the general e-stop circuit. I guess, for the Odrive, one 4-pole contactor could serve both axes (2 phases of each motor?)
Factory brown-outs or complete outages are all-too-frequent in North-America and these can be a real pain when you have to re-home a piece of process machinery. I have machines with 17 and 21 axes that use incremental encoders. Many times you scrap a work-piece or many work-pieces if it is a production line. Furthermore, in the event of a loss of power, some axes coast and crash.
Here is what I would like to see, with the Odrive:
A large enough PSU to drive the motors and charge batteries on the same line. In the event of a loss of power, my microcontroller and Odrive remain powered up and the microcontroller commands the Odrive to bring the axes to a rapid-but-controlled halt. The safety contactor for the motor lines would be a hardware delay-off type that would be set to open within milliseconds of losing power to its coil (just enough time to let the axes come to a standstill).
The Odrive would remain powered-up.