I am trying to get a dual motor platform to work properly in velocity control mode. I got 2 200KV 7 polepair hallsensored motors - https://alienpowersystem.com/shop/brushless-motors/63mm/aps-6374s-sensored-outrunner-brushless-motor-200kv-3200w/ using a Odrive V3.5 that I had lying around from another project (cost is an issue). Updated fw to latest. Setup worked following the hoverboard motor guide and velocity control generally works well but I keep on getting motor current limit violations not only during acceleration/deceleration but also just running at a constant speed.This happens more frequently during higher velocity operation. vel_limit for both motors is 50 so 50x7=350<600Hz should be fine. I’m running from 7S Li-Ion so around 25V (25V*200KV/60s=83,3>50, should be fine) Motor current limit is set to 80A. Iq setpoint as well as Iq measured as plotted using odrivegui are only about 6A when it cuts out. I’ll post an image soon as I forgot to take a screenshot. → I don’t know why the motor current limit error even appears but another more general question that I have is if it is possible to (instead of erroring out) make the odrive work within the set limitations.
In my application, which is similar to the shopping cart from the hoverboard example, it doesn’t really matter much if position is lost or the commanded velocity just can’t be reached within the current limit → it should in this case just go as fast as it can within the current limit. Is it possible to configure such a behaviour ? Erroring out should be the very last thing it does only allowed to prevent damage to itself - all other conditions I would rather it to do it’s “best effort” instead of just erroring out and giving up.
I did try using torque control mode and changing the vel_limit rather than velocity control but that produced significantly less torque at low speeds invariant to the commanded torque ,which may be due to improper tuning of the torque controller but I’m uncertain if it is even the right stategy to achieve the expected behaviour.
Yes, you can increase motor.config.current_lim_tolerance to suppress the CURRENT_LIMIT_VIOLATION error.
ODrive will always try to stay inside whatever current_limit you set, but sometimes there can be noise, high inductance etc which means that the current controller overshoots, or thinks it has overshot.
The tolerance is variable for exactly this reason, to prevent spurious errors.
However I would also advise using a common mode choke e.g. the ferrite ring from the ODrive shop - this should help a lot and may mean that you don’t need to increase the error tolerance.
Hi towen,
Thank you very much for the quick answer. Good and interesting idea using a common mode choke - as I however work in a fairly confined enclosure and the motor leads are pretty short (about 5cm) I have no room nor the length in wire to place them. I could probably extend the leads to add the choke but still would have no room to put them. I did manage to get a screenshot in the meantime however, so here it is:
As you can see the measured Iq is fairly noisy as you expected but the Iq setpoint is actually below 5 A in this case I think - and it cuts out though the limit is set to 16 times the setpoint.The negative current spike on axis 0 is just breaking after axis1 stopped - did not trigger a fault. Current_lim_margin was set to 8A for both axis - but I don’t quite see the point in increasing that as I need to also put some actual load on the motors at some point so they would draw some heavy current (like maybe 60A for a half minute or so). Right now they are just driving the planetary gearsets and the tracks the rig runs on, suspended in the air on a big cardboard box. Also I did experience this on both channels but way more frequently on axis1.(only happened like once on axis0) If it matters at all - i did use the hall sensor 22nF cap mod discussed somewhere here in the community as before this i had frequent illegal hall state errors - the mod using small perfboard adapters fixed this without issue - just for sake of completenesss - also I use the stock 2Ohm resistor that came with the 3.5version of the Odrive.
Is there maybe some controller setting I need to tweak ? Current control bandwith is stock(1000) up from the 100 in the hoverboard guide (didn’t change a thing).
Looks to me like the “encoder” estimation is changing suddenly, probably due to noise. Can you also plot the encoder position or velocity estimate?
Hi,
Thanks for having a look ! - the above screenshot actually has the velocity estimate in the top plot. Putting all graphs in a single plot window was sort of cluttered. Doesn’t seem to contain the spike that I think you were expecting though, just the ramp down to zero speed from when the error occurs (red line). As you can see the input_vel is higher than the vel_limit for both axis but I think that shouldn’t matter,or does it ?
I’m a little lost on this one - I guess over all noise could be the issue but don’t quite know how to reduce it … on the other hand is it possible that the encoder actually does change but the plot just missed the hickup in the estimate ? I guess the plot update frequency is way lower than the encoder update frequency … how can I find out - and if it is the case what can I do ? is there a way to enable sensorless commutation once a speed of say 20turns/sec. is reached ?
So I have tried and tried again braided the motor leads as much as i could, or just tied them together, - Axis 1 always fails a couple seconds in - I could not plot a high current measurement (close to limit) even once. Also it just plain didn’t happen on Axis0 - I tried to make it error out on Axis0 as well - no chance… Any ideas ? also this seems to be a very similar problem to multiple threads here like Odrive grinding to halt after a couple of seconds, giving current limit error - #3 by RobotGuy , mine and this ODrive controlled by Paspberry Pi - one motor spin could actually be the same issue ? → maybe we can join the threads and use a single one to tackle the issue ?
Yeah it sounds like its the same issue. Mine also only happens on Axis 1. Calibration works fine but as soon as I start sending commands (I’m using position control), I always get the error within a second or two. Sometimes I can get it to move a couple times before it errors, but other times its immediate.
The strange thing is that on some boards it works correctly on both axis, but on the board I’m currently using it doesn’t work. This leads me to believe that its an issue with the board itself, maybe a defective current sensor.
Did you guys had any luck solving this issue? I’m facing the same problem just on axis1 with ERROR_CURRENT_LIM_VIOLATION. At this point my project is halted because of this error. Can someone please help me?
