Absolute encoders - still not supported? Do I actually need them?

#1

Hello ODrive people :smile: I need to build a pan-tilt unit for a camera and I’m looking for motor driver options. It would be something like a gimbal, but not exactly. A gimbal is 3-axis, has an IMU and it’s job is to stabilize the camera in relation to the ground while the frame is moving. I only need 2-axis and I don’t care about stabilization, but I want to be able to define angle set points for pan and tilt, and have a PID loop which keeps those angles in relation to the frame (not to the ground). Seting angles in relation to the frame is what is missing in off-the-shelf gimbal systems. Using a direct drive BLDCs for that has the advantage of being fast, light, and mechanically robust. Would ODrive be good for that? I imagine I need an absolute encoder, otherwise I would need to either initiate the system at certain known position every time, or perform a homing procedure after each power-up.

#2

You need an absolute encoder if you don’t want any calibration at startup. You need an encoder with an index pin if you’re okay with “homing” each time you boot up. You do not need either if you’re okay with +/- movement at startup and then setting some known position as “0”.

#3

Hey Wetmelon,

I’ve heard through the grapevine that you’ve created a firmware feature update to support the AMT203 absolute encoder.

I happen to have one kicking around and I’d love to try out your feature. I’m a new initiate to the software/firmware Dev world, though, and am a bit intimidated by trying to merge your feature with the latest firmware release/compiling/flashing it onto my odrive.

Any tips for getting started with that?

Alternatively - I’m thinking about trying to spoof the absolute feedback - without changing the firmware first - by having my teensy board (Arduino) talk over SPI with the encoder to get absolute position on startup and then write (uart ascii) the encoder position, the offset, and the encoder.is_ready to true. Then have the odrive continue to read the incremental A/B pulses from there.
Think that’ll work (on unmodifed firmware 3.6)?

Thanks,
Lewis

#4

The AMT203 branch I believe only has the API for communicating with the device (?) It’s been a while tbh. You would have to add the exact process you just explained somewhere in the startup code. And yes I think that would work fine with the Teensy