I have run into some issues getting my O-drive running as there are some intermittent hiccups. The entire description of the system might not even be fully relevant, and you can probably skip this next section in which I will describe my application/setup.
Currently the setup I use has the O-drive connected to a BLDC motor, the O-drive working in current control mode. A secondary microcontroller runs the main (torque) control loop, and thus sends current control commands to the O-drive over serial (native protocol). The serial settings are 921600 baud, and I don’t expect/want a response from the O-drive. The rate at which current control commands are being send is 1khz, which can be done with 921600 baud. However, I have not considered whether the O-drive is able to handle this update rate without being overloaded.
I can set a torque, and I can see that the microcontroller does indeed send this command. The problem is that sometimes the O-drive responds as required, sometimes it shows a delayed response, and sometimes there is no response at all.
So that gives rise to the following three questions:
What is the maximum update rate that the O-drive can handle?
What kind of behavior does the O-drive show if it would be overloaded?
Are there any things I can check to isolate the issues I am having?
When you say “responds as required”, do you mean the time it takes to set the input_torque to the correct value, or are you waiting for a response on UART?
The ODrive polls for data at 8kHz. We anticipated users using up to 1mbps on UART ASCII, so really there should be no reason that the ODrive cannot keep up. That being said, @Samuel did just make some changes to the UART transmit buffers that will be available in firmware update 0.5.3. Perhaps that would help, if your problem is lack of UART response.
When you say “responds as required”, do you mean the time it takes to set the input_torque to the correct value, or are you waiting for a response on UART?
I am not expecting any response over the UART (and have indicated that in the appropriate fields in the native protocol). So when I am talking about ‘responds as required’, I mean that the O-drive sets the appropriate current as instructed.
The ODrive polls for data at 8kHz. We anticipated users using up to 1mbps on UART ASCII, so really there should be no reason that the ODrive cannot keep up.
Do you know if anyone has actually tested this and confirmed it working? If that would be the case then the problem ‘should’ lie with my code and micro.
That being said, @Samuel did just make some changes to the UART transmit buffers that will be available in firmware update 0.5.3. Perhaps that would help, if your problem is lack of UART response.
That is some good news, I am looking forward to that. Although that would also mean porting my code because of the large amount of changes in commands/endpoints and such compared to the version I am using now (I believe it is V3.6-56).
A short update, I have tried two different ideas to see if I could solve the ‘response’ issue.
Firstly, I tried to run the controller at a reduced update rate, so that the O-drive is being send commands at 500Hz instead of 1kHz. This did not seem to make any difference at all.
A second idea was to only send a current setpoint command if it was different to the last one that had been send to the O-drive. This did seem to help, at least for some simple step responses (after the dynamics of the step, the setpoint of course remains stable).
I am afraid that this is not a final solution, because some experiments I want to run have a continuously changing setpoint for an extended period of time.
At the very least, this does seem to confirm that the issue is with the O-drive software as nothing else has changed in the rest of my code. I am not sure if it is the UART RX buffers being overrun, or if the bug is elsewhere in the code.
Have there been any significant changes since the V3.6 software that fixed serious bugs in the UART buffers?
Sorry to cause some confusion, it is not custom firmware, all standard.
Sadly I do not have access to the O-drive until Thursday, I do have access to the JSON and the firmware file. The firmware file that I use (straight from github) is “ODriveFirmware_v3.6-56V.hex” of 634kb. If I look at the file sizes of previous releases I think that is version 0.5.1.