ODrive Micro Issues with SPI and AS5048a

[js_eka]

Hello - we are trying to get an AS5048a encoder working with the ODrive Micro; however, we’re bumping into several issues. We’re using an AS5048a Dev Board AS5048A-TS_EK_AB. MOSI is pulled high to 5V as per the ODrive docs.

The main issue is an intermittency issue - when viewing plots on the ODrive GUI, there are clearly points where data is missing. However, when viewing the MISO line on the scope, I can clearly see data.

This intermittency issue can be reproduced easily by physically disturbing the cabling in between the encoder and the ODrive Micro. We thought it might be a cabling related issue, but after testing numerous harnesses and reworking connections, it does not appear to be a component level or wiring issue with respect to the cabling. I have also tested changing up power sources.

I also scoped the V+ and GND lines to look for dips or bounces, but nothing seemed out of the ordinary,

Additionally, we observed that the ODrive Micro has some strange behavior that upon a power cycle or the above-described intermittency issue, it will reset the encoder position plot to 0. I was able to observe this behavior by: a) Setting the encoder position to a non-zero value as shown by the ODrive GUI, b) recording the scope readings, c) trigger a reset such that the encoder position shows 0 on the ODrive GUI despite not changing the physical position of the encoder, d) recording the scope readings. Before and after the position reset, the encoder readings on the scope looked characteristically the same, which makes me suspicious that the ODrive Micro is zeroing the reading for some random reason. Additionally, we put a scope on the PWM output of the encoder, and that value persisted between power cycles, intermittency, etc, which makes me believe the encoder readings are behaving as expected.

Any advice on this intermittency issue, as well as the ODrive’s strange zeroing response to said intermittency issue would be greatly appreciated.

Also, if this is an issue that is related to SPI encoders, are there any encoders that are compatible with the ODrive Micro that either are tested to have fewer issues than the AS5048a, or use another communication protocol that works with the ODrive?

Thank you!

[solomondg]

Hi! The AS5048A has a lot of issues with its protocol and EMI resiliency, I generally recommend against it for this reason. SPI additionally can be quite sensitive to EMI – I would recommend shielding the cables (terminating shield to the digital ground at the Micro) and/or routing them away from the motor and power wires, if possible.

You can also try updating to devel firmware (in the firmware update tab of the GUI) and setting ignore_error_flag to true (and then running save configuration). Alternatively, you can try increasing max_error_rate to e.g. 0.5, which will allow the ODrive to ignore a few cycles of intermittent missed data.

Regarding the position reset-to-zero, this is expected functionality – by default, the ODrive will use the relative position since power-on. If you want to instead use the absolute position of the encoder, you can set up the absolute encoder reference frame.

Typically I would recommend using the MA702 encoder IC, it’s much higher performing than the AS5048A and with a more robust protocol. However, breakout boards are typically not available, which can be tricky.

Overall, I would recommend:

1. Shield the encoder lines. This can be done with some aluminum foil, connected to a GND pin on the Micro’s J1 FEEDBACK IO header.
2. If you’re still getting issues, try increasing max_error_rate to a maximum of 1
3. If that doesn’t help, you can update to devel firmware and set ignore_error_flag to true.

[js_eka]

Thank you for the reply @solomondg

We ordered some MA702 and MA732 to test. I wanted to ask, these encoders are 3V3 and the ODrive Micro documentation says that these encoders are supported - but the SPI connector on board appears to be for a 5V encoder. Do I need to pull lines from the board, and if so could you advise where from the board to solder to for 3V3 SPI?

[solomondg]

Hi there,

Yes, you’ll ideally need some sort of step-down regulator. Assuming you’re designing your own PCB, a simple LDO should work fine. If you’re referring to the MPS eval boards (e.g. this one), then you’ll ideally add an external 3.3V power source. However, you can derive power from the Micro’s 3.3V rail with some very careful soldering, from this test point:

That being said, it’ll likely be much easier to just have an external LDO powered from the Micro’s 5V rail to step down to the 3.3V the MA702/MA732 needs.

[js_eka]

Hello @solomondg

Thanks for the quick response - understood on the need for shifting down the voltage. We’re currently not designing our own PCB so we’re trying to make the MA702 and MA732 work with the ODrive Micro board.

Shouldn’t simply using an LDO to step down the supply voltage be insufficient, given that the SPI logic out of the SPI connector on the ODrive Micro is 5V logic on the CS, CLK, and MISO lines?

[solomondg]

Hi @js_eka ,

The ODrive Micro uses 3.3V logic levels for SPI, so there shouldn’t be an issue there (it’s tolerant of 5V inputs, hence the compatibility with 5V SPI encoders).

[js_eka]

Many thanks @solomondg , the encoders from MPS so far are cooperating much better than the AS5048a.

[jc_eka]

Hi Solomon,

Thanks to your help, we are now successfully using the external MA702 and MA732 encoders. We really appreciate your assistance.

I did notice one thing, though. The position value for the MA702/MA732 always starts at 0, while the AS5048A returns the absolute motor position at boot. I believe the MA702 and MA732 are also absolute encoders, so I was wondering: is there a setting I can adjust to change this behavior?

Best,
Jinwon

[solomondg]

Hi Jinwon,

I believe this is a configuration issue – I previously guided your colleague to set up the absolute encoder reference frame, see this message: ODrive Micro Issues with SPI and AS5048a - #2 by solomondg

I’m very glad to hear the MA702/MA732 encoders are working well for you! If I may ask, are you using an evaluation board, or some other breakout PCB? I’m not aware of any available MA702/MA732 PCBs, so it would be great to know so that I can recommend them in the future to our customers!

[jc_eka]

Hi Solomon,

I believe we are facing a slightly different issue.

Previously, we observed that the position value would reset to zero when the encoder signal was intermittent, which I understand. My understanding from that thread was that the ODrive reads the initial absolute angle from the encoder and then functions like an incremental encoder, adding or subtracting angles to accommodate multiple turns.

However, I am now seeing that the ODrive is not reading the initial absolute angle. Instead, it always starts from 0 degrees at boot when using the MA702/732. To be clear, I don’t need the absolute angle to be read continuously. I want the intended behavior: reading the initial absolute angle at startup and then operating as an incremental encoder.

I tried setting odrv0.axis0.config.startup_encoder_index_search = True, but that did not resolve the issue. Is there anything else I can try?

For context, we are testing the MA702/MA732 with this component: https://www.digikey.com/en/products/detail/monolithic-power-systems-inc/TBMA732-Q-LT-00A/14563164. It is available on Digi-Key now (though only 9 parts are left! ).

Best,
Jinwon

[solomondg]

Hey Jinwon,

Sorry – the fact you’re using startup_encoder_index_search makes it sound like you’re connecting the encoder over A/B/Z instead of SPI. If that’s the case, I would strongly recommend using it over SPI. Otherwise you will have to use the index-based reference frame, which requires movement / index search on startup.

To add clarity about the ODrive operation – yes, it does only track deltas of the encoder position. By default it uses a startup-relative position frame (which is why it initializes to zero by default). However, you can use a position frame initialized by the encoder angle, which is the absolute encoder reference frame, and requires an absolute encoder. If you’re only using an A/B/Z incremental encoder, this is still possible, but requires an index search procedure (up to 360° of movement) before the encoder index pulse is observed and the absolute position can be initialized.

[jc_eka]

Hi Solomon,

I am using MA732 over SPI and I guess I was not supposed to use startup_encoder_index_search.

you can use a position frame initialized by the encoder angle, which is the absolute encoder reference frame, and requires an absolute encoder.

This is precisely what I wanted and I believe MA732 is an absolute encoder that can support this, right? I am not sure what configuration I need to change to make it work that way.

[solomondg]

Hi Jinwon,

You just need to set the absolute encoder reference frame.

[js_eka]

Hello @solomondg

Thanks for the info - I was able to configure the settings you described. However, I found that this did not result in our desired behavior, which is preservation of the angle reading between power cycle of either the encoder or the ODrive board. Setting all the flags and values in the Absolute Encoder Reference Frame docs still resulted in a zero angle reading between ODrive power cycles.

However, through some noodling, I found that setting the Absolute Encoder Reference Frame (circular) produced the desired power-cycle handling behavior. That being said, we would ideally like to have the angle tracking behavior not to be circular, so there’s a bit of a conundrum where we like the power-cycle handling behavior of the below depicted configuration, but it seems that there’s something deeper about the odrv0.axis0.controller.config.circular_setpoints flag.

Any advice would be greatly appreciated!

[solomondg]

So just to confirm, in the picture you linked, if you disable circular setpoints and then reboot, the position will be initialized to zero on boot, no matter the motor/encoder angle?

[js_eka]

Hello @solomondg

I just checked to reverify, and it seems that I must have done some sort of setups wrong when I sent my previous message. The behavior is good with circular_setpoints unset, so our issue is resolved. Sorry for the confusion!

[solomondg]

Great! No worries at all!