I looked at both and both are acting up like pos_estimate.
Pos_cpr seems not to show have sign of problem tho
Update:
I added chart series for pos_cpr, shadow_count and count_in_cpr.
Also fixed an error in my CRC verification code which was ported from the Due - that fixed the 0x80 error when the rotor was standing still. I had disabled the CRC (before I realized the error in the code) which allowed me to at least get past the error.
Now why all these jumps on pos_estimate? my theory right now is noise. And now that the CRC verification is active, I am pretty sure that’s what’s happening.
Yesterday without the CRC verif corrupted data all positions were accepted, causing the estimators to see large increases in speed, hence throwing the position estimation way off.
Today, with correct CRC verification I am still able to see these weird jumps when moving the rotor by hand, although most of them were taking place after many turns with pos_estimates extremely large (hundreds of millions counts). If the CRC was bulletproof (no CRC is, and a 6bit CRC of 24bit CRC certainly isn’t) one explanation would be overflow. I can’t rule that out yet, but one thing is almost certain is that my pos_cpr and count_in_cpr aren’t showing any sign of jump. Jumps are only seen on shadow_count and pos_estimate. I have separated the graphs for the 2 CPR type variables for better scaling. I forgot to screenshot when jumps were taking place (shadow_count and pps_estimate).
The other nice piece of info is that with the CRC verification working, I am NOT able to get as far in the OFFSET_CALIB, with a 0x80 error after the very first part of the calib, before the 2 scans. This error suggests a failed SPI communication, and my theory is that the short period of time where the motor is powered on is causing sufficient noise on the SPI bus to trip that 0x80 error.
Yesterday with the CRC disabled, the crazy jumping during the calibration does correlate that. I was fully ignoring 0x80 so I would actually run the first scan during which crazy jumping would be explained by significant noise on the SPI bus causing wrong positions to be read.
Beside line resistors and a pull down on MISO I have literally nothing else to shield the SPI bus so I’ll do that next and report back.
When you talk about CRCs, do you mean the ASCII interface over USB, or are you talking about the SPI comms with the encoder? I don’t think the AS5047p provides a CRC?
Which actual chip are you using?
Can you post your plots for shadow_count and count_in_cpr?
Does the “crazy jumping” tend to happen in the same physical position? It may be that you have your bit mapping wrong somewhere
However, if count_in_cpr is correct then it could be an issue with the ODrive firmware. Maybe nobody has tried a 22bit encoder until now? Can you truncate it to 16bit and see if it works then?
By CRC I mean, actual custom code to verify the CRC that’s transmitted at the end of the 5 byte message.
I don’t have a screenshot right now but I’ll take one later. You can also take a look at the one I posted with comments yesterday you’ll see pos_cpr and pos_estimate. As far as I could tell pos_cpr did not jump.
For sure since I added shadow_count and count_in_cpr to the graphs, I can tell that shadow_count is following pos_estimate closely.
count_in_cpr is the raw data and I have not seen it jump anytime so I am not ruling out a bug (overflow or something). But I am pretty sure that aside from that I do have a noise problem which is constituent with the last 2 days of observations and it only trips the 0x80 error when the motor is spinning.
update: everything seems to be up and running.
the issue with calibration was electrical/noise (feedback from using separate PSU’s for encoder and ODrive). Powering the electronics with the ODrive’s 3.3 fixed the noise issue and calibrated on the first try.
I’ll be testing pre-calibration next
cheers
1 Like