Hi,
I was having a lot of deadline_missed failures in 0.5.1 and in the hopes of resolving these, I just ported my code to 0.5.2. Unfortunately, they still happen:
axis0
axis: no error
motor: Error(s):
MOTOR_ERROR_CONTROL_DEADLINE_MISSED
sensorless_estimator: no error
encoder: no error
controller: no error
axis1
axis: no error
motor: Error(s):
MOTOR_ERROR_CONTROL_DEADLINE_MISSED
sensorless_estimator: no error
encoder: no error
controller: no error
They don’t occur immediately, but usually don’t take long to happen, maybe 1-5 minutes.
I use two AMS absolute encoders and INPUT_MODE_POS_FILTER. The firmware is slightly modified. dump_timing(odrv0) results in this:
Hi,
I changed the reading of the ams encoder so that it wouldn’t fail when the error flag of the encoder is set. Otherwise the odrive would fail with ERROR_ABS_SPI_COM_FAIL immediately in my setup. I also added a bunch of special cases that trigger when I set some variables, but the deadline-missed error happens even if I don’t trigger that code. So I don’t think that code is related to that. Still, if you want to have a look, here is the code of my firmware, relative to the current 0.5.2 branch:
I command the ODrive via native protocol and USB from a Jetson Nano. An USB to USB isolator is between the Jetson and the ODrive.
The controlloop on the Jetson takes about 16ms per frame, and about 10ms of that is spent communicating with ODrive. But there are very frequent spikes where communication takes about 30ms:
Hmm… Oscilloscope 36k items maybe? If not that, then the watchdog feed returning any_error() but I’m not sure that’s wrong.
Btw you don’t need that stack overflow crap for converting types to floats & back. std::memcpy(&var, &floatVar, sizeof(float)) is defined behaviour. See the can_helper.hpp header for ideas. ODrive is little endian btw
Hi,
what do you mean about the oscilloscope? I increased the buffersize in my firmware as much as possible. I also added code to compress the floats into 16-bit values and also added code to monitor multiple variables. But the deadline missed error happens before I trigger the oscilloscope, so I don’t think that is the issue.
I also added get_any_errors_and_watchdog_feed, simply to save time while communicating with odrive. This way I can check for errors and feed the watchdog for both axes with one usb command instead of three. But I also don’t see how this can cause this error.
I did some more experiments and found out that odrive doesn’t seem to crash, once I stop the watchdog timers and all usb communication (but the motors keep running). Of course this is not conclusive, but it seems plausible that usb communication causes the error. Does anyone know how I can profile the communication stuff? It doesn’t seem to appear in dump_timing(odrv0).
My theory is, that the lowest level of the usb stack randomly keeps resending packets due to EM noise. Does anyone know where this code is and how I can change it? Maybe the timeout is configurable?
