I’m on the Devel branch using an SPI AMS encoder. I swapped over to the devel branch because I needed CAN + SPI encoder support.
When I try axis.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE, the motor starts to spin but then stops and the encoder stops publishing data.
I’ve modified the CAN code so it constantly publishes encoder CPR and shadow counts.
Any thoughts as to why the encoder would just stop publishing data? It does error out with this error: ERROR_ABS_SPI_COM_FAIL. I don’t understand why the motor motion would kill the encoder. A reboot fixes the issue.
Did you check out the RC-v0.5.0?
Head over to the encoder.md in the docs of that branch. It’s been updated with the most recent info. I believe you should only need to do an offset calibration after first setting your encoder mode/cpr/pin, saving and rebooting.
That being said, this error message is sent when the parity couldn’t be validated multiple times in a short period of time. If you were able to read position estimates during the calibration, perhaps you have some noise that’s sometimes making the parity check to fail?
edit: in the RC running only offset calibration is not enough, so yeah you should still do full calibration I think
hi,
i don’t test with only the pull down resistors. i think it doesn’t need caps. I used this because i have a PCB.
my connecting wire can not be good and need a Schmitt trigger IC
Interesting - I have recently been having this problem too. Previously my ODrive worked fine with several motors with AS5047p sensors attached, and now with no hardware changes I get ERROR_ABS_SPI_COM_FAIL. Once I have the error, I have to power-cycle the encoder. If I just call reboot() then it doesn’t go away. It’s as if the encoder is being sent a bad command and goes into some kind of sulk-state.
I thought perhaps it was related to the new firmware somehow - e.g. not setting the pin to the correct drive mode, or it wasn’t sending the right commands all the time, or not setting the CS pin properly.
But I reverted to an old Wetmelon branch and I still have the issue.
Also, it is mainly a problem above 20 volts - at low voltages it works fine, so definitely seems to be some common-mode noise issue. I thought perhaps it was my power supply, so I put it directly on a 44V battery, but there’s no difference.
how long is the wiring to your encoder?
I have about 3 metres of Cat5e cable (signals twisted with GND) and 2 connetors although using a ahorter 1m cable with one connector also didn’t seem to help much
Are you using 5v or 3v3 supply? I’m using 5v but maybe the 3v3 is cleaner as it’s from an LDO… That said the decoupling caps on the stock AMS board should sort that out
Mine is about 2 ft. Ribbon cables no shielding yet.
The issue seems more frequent when calibrating (motor on) than by just moving the rotor by hand. I have a custom spi driver in a custom odrive firmware so I am also clocking at higher speed. Although it’s disabled now i do have a CRC on the spi message that I can use to verify the data. The issue is that the SPI FAIL error is triggered by successive comm errors. The only reason for this error to take place is when your parity is off (or in my case my crc verif failing). So more than likely the api fail really is related to noise on the signals.
The logical level on the odrive Side is 3.3, and on the encoder it is 5v. I am powering the encoder with the odrive (5v). Mosi in my case is wired to the encoder as the command for position reading is not FF so I couldnt cut that corner.
I have a pull down on Miso and line resistors.
Ultimately my wiring will be a lot shorter so I hope I can get around the issue with mild shielding for now.
Yeah I wanted to confirm this again. I happened to have this happened to me with the scope connected and everything looked good (messages from the encoder were going through). Almost as if the SPI callback wasn’t taking place anymore. Weirdly power cycling the encoder fixes the problem. A bit off topic sorry.
Huh that’s weird. But it only happens when the PWM is running and a fair bit of current is flowing?
It’s almost as if the ODrive is causing interference that disrupts the operation of its own CPU…?
You have an ST-Link, right? Are you able to debug it?
Maybe the ODrive is looking for an edge to finish the SPI transaction, but due to noise transients it doesn’t see it?
I am almost positive it’s noise on MOSI. On MISO with my CRC verification it either avoids bad comms or if noise is really bad, it will eventually throw a SPI FAIL error due to abs_spi_error going above the 0.005f threshold
I am considering this. I am going to shorten and shield stuff while getting rid of the ribbon cable. I might try a schmitt trigger or go straight for differential drivers and twisted pairs.
This sounds very similar to the problem I have with AS5047p, see the thread I created. If you watch the traffic with a logic analyzer, you may see the error bit go high and stay that way. Higher voltages are probably causing more EMI on the encoder SPI bus and the induced noise causes confusion.
The odrive never (intentionally) sends commands to the sensor, so by my reading of the datasheet the error bit should never go high. I haven’t had time to try this theory out, but I bet if the odrive were configured to send explicit “please give me the sensor reading” commands instead of relying on the default “send reading” behavior, it would reset the error flag when those commands are received.
Did anybody managed to get this to work with higher voltages? Mine manages to calibrate with lower voltages (lower than 20V) but above I get high spi_error_rate and error ENCODER_ERROR_ABS_SPI_COM_FAIL.
That’s exactly what I was getting, too.
I’ll try again with updated firmware, and if that doesn’t work I’ll try a new AS5047p chip…
I think the problem could be that the error flag gets set if the new request comes in before the ADC/Cordic conversion has finished, and the ODrive never clears that flag.
It could be that an aging chip that has been exposed to humidity takes longer to converge, and also that the higher noise floor from running at higher voltages also makes it take longer.
All my problems went away when I shorted the 3.3V and 5V lines on the AMS AS5048A encoder. AMS data sheet, see page 10.(ams.com)
The evaluation board data sheet has misleading information.
These evaluation boards give a misconception that you can hook up the 3.3V line and leave the 5V line open. However, digging deep in the data sheet of the chip, it says to short the two pins. What is even more frustrating is that this IS NOT mentioned on the data sheet of the AMS AS5048A Evaluation board. It just says to connect the 3.3V to 3.3 V supply. Also, connecting just the 5V line to the 5V of the ODrive, does not work.
