PST-360 SPI Encoder Compatibility with ODrive Pro (v0.6.8 or later)

Support ODrive Pro Support
1

Hi everyone,

I am trying to interface the “Piher PST-360 rotary position sensor” (SPI output type) with ODrive Pro using firmware v0.6.8. The encoder features an open-drain SPI protocol and requires a specific timing sequence, including a sync byte (0xAA) and a 10-byte frame.

The encoder documentation:
PST-360_SPI Encoder

I would like to know:

  1. Is this encoder supported in the current or latest firmware?
  2. Will upgrading to firmware v0.6.11 help in this case?
  3. Has anyone successfully interfaced SPI sensors using open-drain communication with ODrive Pro?

Thanks in advance for any help or insights!

Encoder model used:PST360G2-1S-C0000-ERA360-05K

2

Hi!

We don’t have support for this encoder at the present moment. However, from an electrical perspective, it should be feasible to add (with a simple transistor and resistor added to the output wiring), which we could discuss. That being said, I have some significant concerns here, namely:

  1. SPI is already very sensitive to electrical noise and interference, and an open-drain SPI bus will have these issues even moreso. You’d likely need to be very careful with wiring, making sure to route the SPI wiring away from the motor wiring and ideally shielding your cables
  2. The ODrive typically requires the ability to read the encoder at the internal loop update rate (8kHz). This encoder requires a period between reads of 1.5ms, which would result in a maximum update rate of about 667Hz. It’s technically possible to modify the firmware to allow this, however all things considered this is very slow and will significantly affect your ability to do position and velocity control. I would generally say that this makes the encoder unusable above about 100 RPM.
    image
    image1766×1088 133 KB
  3. The encoder seems to have a significant nonlinearity in the output, which will make it wholly unusable as a commutation encoder – it would only be able to function in conjunction with another encoder directly connected to the motor, and only if the mechanism’s movement range is constrained to the linear output range of the encoder:
    image
    image1619×664 46.8 KB

    So it may be suitable for limited range position control, but you’d need another suitable encoder directly connected to the motor, this alone wouldn’t be enough.
  4. The datasheet indicates a very significant jitter in the internal position sampling of 350us. While this may not seem like a big deal, it’s actually a very significant issue at nonzero speeds, and will result in a very rapid falloff of encoder resolution as the speed increase – from 14-bit (16384 CPR) at zero speed, to an effective resolution of 10.74 bits (1710 CPR) at 100 RPM and 7.42 bits (171 CPR) at 1000 RPM (and going even lower as velocity increases).
    image
    image1584×377 49.5 KB

Here’s a graph of resolution vs speed, x axis is speed in RPM, y axis is encoder effective resolution in bits: Desmos | Graphing Calculator

This is also an issue that the AMT21 has as well – it has about three times less jitter than the PST-360, but it’s still such an issue that we actually had to rewrite the encoder firmware, which is why we sell a custom version.

So, generally I would say that this is a very very bad encoder for any sort of motor control application. The only situation where it could possibly be effective is where all of the following are true:

  1. You have another encoder connected directly to the motor
  2. The maximum speed seen by this encoder will be always less than 100 RPM or so.
  3. The mechanism this encoder is connected to is limited to a single turn, inside the encoder’s linearity range.
  4. You use shielded cable for the encoder wiring to the ODrive, and can add the external transistor and resistor needed to adapt the electrical signaling.
  5. We add protocol support for this encoder to the ODrive firmware.

These are significant constraints, and I’d probably advise you to throw this encoder away and get one more suited for motor control. Specifically, if you have an existing 14mm shaft, I would recommend the RLS Orbis over SPI or BiSS-C, or the AMT24 over RS485, which we could discuss programming with the custom firmware we use on the AMT21 to increase performance.

If you’re able to change the shaft diameter, or use an end-of-shaft mounting, then there are more possibilities.

Maybe you could provide a bit more information as to your application? What is your use case and constraints?