I have made some progress by hacking the spi communication with an arduino.
I have been able to read the data that the encoder sends back to the Odrive, and it happens to be 0x11000000 witch is, according to the datasheet : “Error flag indicating a transmission error in a previous host transmission”.
I can’t quite identify what this bad host transmission could be.
Is there a way to log, from within the Odrive, the data that it sends through its spi port ?
Does anyone have an Idea as to where the issue could be coming from ?
Hmm, interesting. A few of us (including myself) have been having SPI issues with AS5047p recently, AS5048 is probably no different.
That error flag is new to me. maybe @madcowswe or @Wetmelon might be able to help?
If you have an ST-Link, or any one of the ST Nucleo development boards, you can put breakpoints in the code using Eclipse. You may even be able to use a raspberry pi as an ST-Link with a remote GDB server to Eclipse, but I wouldn’t recommend it if you’ve not done it before. There may be a way to program an Arduino to behave as an ST-Link.
If you have an oscilloscope, you might take a look at the signals on MISO, MOSI, SCK and check that they are clean-edged digital signals. You could also check the power supply to the encoder and see that there’s no noise on that.
I had this same error when I was setting up the AS5047 in SPI mode. It turned out that I had configured my odrive saved the config and rebooted via the odrivetool command but never power cycled the encoder after my changes. So the fix was to power the whole system off (odrive and encoder) after the odrive is properly configured for SPI and then power everything back on together. If this doesn’t fix it I’d try moving your abs_spi_cs_gpio_pin to 3 or 4 instead of 1.
Since I think it is good practice to unplug any hardware when playing around with the connection, you can be sure @jdow that I have rebooted both the odrive and the encoder several times. I do not see how changing the abs_spi_cs_gpio_pin to 3 or 4 would change anything, but anyway. I did change the CSn pin to be connected to the gpio 4 and I did not notice any change.
The error flag reported by the encoder was due to the fact that I was trying to send some command from the Odrive to the encoder. Just plugging (as instructed in the docs) the encoder MOSI to 3.3V solved this issue. I sadly do not have access to an oscilloscope. But with my crappy arduino hack, I was able to make sure that every piece of data send through the spi connection was actually correct. (I was even able to read the encoder position while the Odrive was the master of the spi connection).
The Odrive still gives me this 0x0080 error and this very high spi failure rate. Thus, the point of failure has to lie in the SPI reading of the Odrive. I did notice that the Odrive Firmware makes great use of dma witch makes for an efficient but hard to debug SPI connection.
Has anyone experienced something similar ? Is there some values in the code that I should check in priority ?
Similar experience to jdow here - I had weird 0x80 errors - and eventually solved it by powering my encoder (btw not a ODrive supported encoder, but wrote a custom driver for it) with the ODrive instead of using an external PSU (even though they shared grounds).
Ok, I can’t quite put my finger on the source of the issue, but the encoder I was using was behaving very weirder by the day to the point that it did not even work with arduino (although it worked fine some days ago). I switched to a new spare encoder (exact same model, exact same batch) and it worked first try.
I don’t know what could have caused the worsening of the encoder. (EM environnement ? Reversed polarity ?)
Weird indeed. I suppose it’s possible that the AMS chips could have an inherent fault, caused by humidity perhaps? But that sort of thing would warrant a recall I’d have thought… Those things could be used in medical devices for example.
Yes indeed. We do not want such behavior in a medical device.
I would like to add that the error flag sent by the encoder is always high. I had to comment out the check that threw the ENCODER_ERROR_ABS_SPI_COM_FAIL (error 0x0080) if such flag was high for too long. This is very similar to this thread (SPI AMS encoder stops responding) in witch they also see this flag set to 1 although the Odrive does not send anything (because the encoder MOSI is tied to 3.3V).
Finally, although the encoder gives a sensible reading of the angle, I can’t quite get the precision I was hoping to get. It seems that the encoder reading fluctuates randomly in a range of -5cpr to +5cpr around the center value. Has anyone experienced better readings or is it a as good as it is supposed to get ? The issue with those random fluctuation is that is gives very high random speed estimate that drive the controller crazy.
not sure if commenting that check is the way to go. if it’s always high it means that parity check is failing, meaning perhaps noise on your SPI bus.
I don’t have experience with the AS5048 but +/- 5 count seems a bit high for a 12 (or 14?) bit encoder. +/- 5 count RMS is what I have on my 24bit encoder. Are you observing this +/- 5 count while in closed loop or idle?
have you played with encoder.bandwidth? that parameter alone has the most significant impact on your noise out of closed loop. Once into closed loop / position control, the actual gains will play on your position readings. If not tuned properly you can end up in a situation where your oscillating around your input position.
Do you have another AS5048 to try? I had one of my AS5047s go bad while I was testing and it caused several hours of headache. I was never able to figure out exactly what happened but I think I may have damaged a trace on the carrier board (had to toss it). My AS5047s don’t show any SPI failure rate issues (you’re looking at odrv0.axis0.encoder.spi_error_rate right?).
I’ve been working with some AS5047Ps attached to KV-85 motors and I have been seeing very similar errors. The issue seems to crop up when I am using two encoders on the same SPI bus, and sometimes when I run the motor in closed loop mode.
Graphing the SPI error rate in the second case, it climbs up to 1 within a second or so.
Did you get any further in determining what the root issue was here?
I’m confused. Both the AS5048/AS5047 and the ODrive use single-ended SPI, don’t they?
Do you mean a pair of boards to convert to differential signalling and back again?
Reopening this thread as I’m having similar issues with the same AS5048 board. I’m able to follow along with the documentation present under the SPI section on the ODrive encoder page. When spinning the rotor by hand, encoder.pos_estimate works perfectly. Running encoder_offset_calibration works as well after adding a 56 ohm resistor to MOSI. After calibration, no errors are present and the SPI error rate reported by the ODrive is around 1E-7. After the encoder is calibrated I saved and restarted the ODrive and tried to initialize closed_loop_control, but the SPI error rate climbs to 0.997 within 1-2 seconds and dump_errors reports ENCODER_ERROR_ABS_SPI_COM_FAIL. I’m not sure how to proceed here, the encoder seems to be working perfectly up until closed loop control. If this is a shielding problem as I suspect, are there any other ideas people have used to limit this problem?
Differential signalling, make sure your shield is grounded properly, etc. I had one user with shielded wires, but the shield wasn’t grounded, so it was just acting as a noise coupler and ruining his SPI