I recently came across the lamprey2 absolute encoder (Lamprey2 Absolute Encoder - AndyMark, Inc) which seems like pretty excellent bang for your buck compared to other absolute ring encoders and I’m trying to figure out if it’s possible to integrate as a load encoder somehow, or even just to update the output position. I’m currently using hall sensors as a commutation encoder with no issue.
They have a PWM output and an analog output, but it’s not sin/cos like most encoders, it’s essentially a potentiometer encoder. I was thinking maybe I could map the ouput through an analog pin to the odrive encoder estimator using this procedure: Analog Input — ODrive Documentation 0.5.4 documentation, but I’m not confident that will work.
Anyways I wanted to check to see if there was no chance before I bought an encoder to attempt this with. Thanks!
Hi there,
Unfortunately PWM is too slow and analog too noisy to be used as an encoder. There’s a chance that we’ll support one or either of those two in the future as a load encoder, but right now it’s unfortunately not a development priority. One approach could be to use an Arduino or similar as an external PWM-to-SPI converter, emulating a supported encoder protocol (e.g. MA732).
That being said, I’d maybe caution using the Lamprey. Those sort of magnetic ring encoders are pretty difficult to do well (RLS makes a whole business out of it 
), and I’m not seeing any sort of published information on the INL/DNL/ENOB. Definitely depends on your required accuracy though.
much appreciated! Good to know, followup question if you don’t mind. Do you think the OA1 or a MA732 style magnetic sensor would work with a ring magnet? Assuming poor SNR is acceptable on the ouput and we could manage a tight and consistent interface.
I think it could be extraordinarily useful to have large bore encoder options compatible with the ODrive especially if they’re affordable, RLS is quite steep, and the tradeoff for position noise could be an acceptable one. Thanks again for the info!
Funny you should say that now, we just made a proof of concept of an off-axis OA1 in collaboration with another customer definitely something we’re looking into! Off-axis takes some extra steps – there’s an additional calibration step that’s necessary, and you only get about +/- 1-2 deg of accuracy + 11-12 bits of resolution – not much compared to RLS’s 14-20 bits and high accuracy, but good enough for a lot of applications! Is there a specific ring magnet you have in mind?
1 Like
I have one of the Lamprey2 encoders that I might try that ring with an OA1, but if you’ve got another one you can recommend I’m definitely interested! (Also happy to alpha/beta test if that’s useful). 1-2 degrees is more than sufficient for our use case.
Sorry to follow on with this post, but I had another thought! Is it possible to add an index instead to the output end of an odrive pro?
So the hall sensor works decently well for coarse position tracking, but drifts over time for any kind of absolute tracking. There aren’t any affordable absolute encoders, but I thought perhaps there’s a way to use a magnetic or optical switch to act as an index on the output. Is this possible with stock firmware?
Essentially as the index is triggered the Odrive resets it’s output position to 0. Thanks!
No worries, thanks for the followup!
OA1 should be ok with lamprey2 ring, just make sure that it’s a strong enough magnet to turn the OA1’s field strength indicator blue/green.
So the hall sensor works decently well for coarse position tracking, but drifts over time for any kind of absolute tracking
Hall sensors should never drift, can you elaborate more what you mean? Do you mean the coarseness of the velocity/position control is causing issues with odometry?
Sorry, that was poorly worded! I mostly meant that we know our gear ratio and can use that to determine the position on the output from the halls. We see drift over time in that output estimate so I assumed noise in the hall sensors might result in occasionally lost positional increments or extra increments added, but it sounds like that’s not necessarily true so it must just be that the gearing ratio we have assumed isn’t exactly correct. It’s one of those unfortunate irrational ratios so perhaps it’s a floating point or precision issue.
Anyways, thanks for all your advice and guidance. We’re developing a large scale electric excavator for a lunar analog experiment and the ODrives have been pretty great! Thanks for all your hard work and development efforts.
Hm, yeah that sort of output estimate drift definitely sounds like just a weird gear thing. Floating point issues can be avoided a bit better by using circular position control mode – effectively bounding the position count to 0-1 so that floats stay high precision.
That being said – how are you measuring position drift? Do you have an external encoder? Or do you mean that your rover’s position drifts over time from expected, as you drive?
Happy I can help! That sounds like an incredibly cool project, would love to learn more!
Thanks! It’s been exciting work. We’re building a version of the RASSOR excavator (File:NASA's Regolith Advanced Surface Systems Operations Robot (RASSOR).jpg - Wikipedia) that has two rotating excavation drums. To get the position of the drum we divide our ODrive reported position by our gearing reduction. We zero our drums at a specific position such that the digging teeth are parallel with the ground, but over time this zero position drifts. It’s most notable as the two drums, which are programmed to stay synced in position with each other, slowly fall out of matched position (which we validate visually). It’s important that they stay relatively synced as the digging forces cancel out as long as they are excavating at the same time.
The rover is a part of NASAs Break the Ice Lunar Challenge (https://breaktheicechallenge.com/) if you’re curious.
Oh wow, super super cool! Would absolutely love to see some pictures if you have any!
The position drifting is very strange - could a shaft be slipping in there or something? I generally think encoder drifting shouldn’t be possible with ODrive.
