Hi am running the Odrive v3.6 on the latest release firmare and am running in this error. I have never seen this pop up before. I have checked odrv0.axis0.fet_thermistor.temperature and it never goes above 30 degrees. The lower and upper temp limits are stock (100, 120). I am not sure why this error is being triggreed. It usually always occurs when I try to make the motor go above a certain rev/s. I am powering the Odrive using 56V
Any adive is greatly appreciated
First suggestion I have is to simply use odrv0.erase_configuration() to make sure the odrive doesn’t have a weird configuration that’s breaking something.
Thanks for the quick reply and I just want to say I love your work.
I don’t think it’s the configuration. I will try your suggestion but I think the issue may be EMI. I did a test where I lowered the PSU voltage down to 32 V and now I can push the motor much higher and hit a new error MOTOR_ERROR_CURRENT_LIMIT_VIOLATION. This one is also confusing since the motor current limit is set to 50 A and at 32V my PSU starts to current limit pretty quickly.
So would it be correct to say EMI is my issue at the voltages we need to run. The odrive is being used to drive the motors of our 4 wheeled robot with a 56V battery. We want the torque/low ohmic loss benefits of 56V as well as other systems on the robot need 56V. If you agree this is EMI what do you suggest I try. I have alredy ordred ferrite rings that I can wound the motor cables around. I had to use LVDS signaling on my encoder (AMS absolute encoder). That was a real pain but LVDS + decent spacing from the motor has fixed the SPI comm errors.
EMI is very new to me and I really didn’t anticipate soooooooooooo many issues. I also tested the setup at 48V and the over temp error pops up again. Only around 32ish V can i avoid it.
Yeah, start with the ferrite rings. We have some solutions in the works for the AMS encoder / SPI comms problem, using SSI voltage levels instead of LVDS, would that be something interesting to you? If so, what would you like the connector layout to look like? At the moment it’s RJ45.
Frustratingly, the current limit violations can come from bad encoder data because of how the FOC works, so let’s get the noise down and see what it looks like after that.
my current solution is using LVDS and RJ45 and the connector is super convenient (it’s a custom PCB + another on the ODrive side to convert back). I had to add some AND gate logic stuff to make sure LVDS is only active when either CS line is active or comms with the motor driver ic fail. I also have to run a seperare power cable since RJ45 doesn’t have enough conductors. All 4 SPI lines are LVDS for my setup. It’s very good you guys are developing a proper absolute encoder solution for the Odrive, there are way too many applications in industry that need absolute encoding so thumbs up to that.
If the EMI is causing bad encoder data then spi_error_rate should go become non zero when I get the current violation or do you think the SPI comms are fine but the AMS chip is loosing tracking on the magnet ?. I will do another test to see if this if there are SPI errors when that error occurs.
Another thought I had was to design a 3D printed enclosure for the motor and line the inside with copper tape and ground the tape. Only have a small hole for the encoder magnet to stick out and motor cables to stick out and maybe some small cooling holes. Bad idea ?
Yeah, re encoder stuff we did the same thing, but we left off the MOSI line and ran power instead.
Yeah, if you’re watching the SPI error rate and it’s zero, you’re probably ok. The absolute encoders don’t “drift” with noise like the incremental ones. There are other reasons that you can get the current limit violation, particularly if your encoder or current controller bandwidth aren’t quite right. What motor are you using?
I left the MOSI line just in case in the future there was a reason it would be used but I am regretting it now, it’s such a cleaner solution having a single RJ45 cable. I think I might change the board to your design for the next rev.
The motor is a very generic 4250-800KV outrunner from China. We are trying to be very frugal with our robot hardware. The motor is connected to a 100:1 gearbox that then drives the wheels of the robot. The controller and encoder bandwiths are stock
Another question I had was using higher than 56V. I know that wil increase the EMF and the Odrive components are max rated for 60V. We have an oppertuniny to use a 14s motor (again economic reasons). That would mean at full charge 58.8V Vbus. That’s a headroom of 1.2 V. Another option is to not charge the battery to 100 % but to 90 % which would result in a Vbus of 57.4 V and thus a headroom of 2.6V. I just wanted to get your thoughts on this. I can create a seperate thread for this if you prefer.
I’m surprised you’re having a lot of problems with EMI, it sounds like a totally normal set up to me. The ferrite rings really do make a huge difference though.
For the bus voltage, your biggest risk is the energy getting dumped onto the bus during deceleration. That will cause the bus voltage to rise. It’s less of an issue with a battery but at 100% charge you have no battery headroom, so VBus will spike. So 90% for sure, max…
I am surprised as well. There must be something in the setup that’s causing it. I am going to do the motor inclosure idea. That + the ferrite rings I hope will put this to bed.
As for the Vbus headroom, what abouit if I use a braking resistor. I still plan to do 90 % charge. I suppose it’s better that the voltage goes into the battery instead of a braking resistor to increase battery life but would using a braking resistor be safer ?
Braking resistor will prevent the vbus from rising (provided it can sink enough current per V = IR). You can also enable a P-gain controller on the bus voltage (called dc_bus_overvoltage_ramp)
very cool. I also plan to run the robot using ramp control which should also limit the regen current based on the ramp rate. I will put updates here once I do the EMI stuff, hopefully it works.
So:
Still when I set input_vel to 100 I get the AXIS_ERROR_OVER_TEMP. I can go to 50ish but after that I always get that error. When I check the thermistor for that axis the temp is ~ 35 C and everything is cool to the touch
I am not sure what to do next…
What firmware version are you using? On the devel branch we recently added a 2nd-order low pass filter for the thermistor to help filter out any glitches caused by noise. To flash devel you will need to compile it from source, some instructions here. You may also be able to get a binary from someone else who has it set up already if you ask on our discord.
Thanks for the reply Oscar,
I am running the latest release of the firmware (not devel) I did confirm that once I disable the thermister temp limit I am able to push to 100 rev/s. Don’t like the idea of disabling thermal limit obviously. I will compile the devel branch from source and try the 2nd order filter.
I just want to add that the ferrite rings make a BIG difference to EMI and does twisting the power and BLDC calbes to minimize loop area especially when are you are running at 56 V like I am
I met the same problem with you. How did you solve it in the end?
The following errors are randomly encountered:
(1)MOTOR_ERROR_CURRENT_LIMIT_VIOLATION (2)Axis_error_over_temp (3)THERMISTOR_CURRENT_LIMITER_ERROR_OVER_TEMP.
Looking forward to your reply. Thank you
I use 0.5.1 firmware