Hello,
I am using 2 odrives v3.6 54V with firmware RC 0.5.1. The commands are send via ASCII on UART with a MCU.
The problem is that the configuration sometimes is completly wiped. Everything is back to stock values and it needs to be reconfigured.
This is really anoying since it can happen after a powercycle of after the MCU is being reset.
What could be the problem?
Are you by any chance accidentally sending se\n down the serial port? (i.e. the “Erase config” command)
No, that is never being send. The other system commands are also not being send
Is there any other command that you are sending that could somehow be corrupted into this?
I’m not very familiar with the ASCII protocol (I prefer to use either USB or CAN) but is there any way to turn on “remote echo” so that you can see what the ODrive received?
There is no other command being send that looks like se\n
The ASCII protocol does not have a option to enable “remote echo”. It needs to be added in firmware
You could edit the firmware and comment out the definition of the se command, to be absolutely sure that it isn’t being triggered somehow.
You’d just need to open Firmware/communication/ascii_protocol.cpp and comment out the lines
} else if (cmd[1] == 'e'){ // Erase config
odrv.erase_configuration();
Is there another way that the odrive can reset its config? ASCII is not the culprit
Did you try the above firmware modification and it still loses config?
If not, please try it, and see if your problem “goes away”.
It’s possible that “sr” has only 1 bit difference to something that you are sending regularly, and therefore some corruption induced by noise is causing this. There’s no CRC on the ASCII protocol, that’s part of the reason I don’t like it.
I can’t think of any way that the config could return to its default values except by an erase config command.
If the data is corrupted it will fail CRC and load the default config.
I am having this exact same issue. V3.6 56V 0.5.1 ASCII via UART. System uses 2 boards and 3 motors. Occasionally one of the boards resets to defaults (except index search on start up still works) but the problem is the default vel_limits, trap_traj, and current_limit cause the device to not function resulting in the customer having to send it back. I have also noticed erratic behavior when the mcu is controlling them via UART. Completely reseting (erase_config) and re-configuring from scratch (little luck with loading the jsons) fixes the problem, although only until it happens again. I can try the firmware mod suggested by towen but my problem is that re-creating this issue is tricky. I will have to try that, send it back to the customer and wait to see if the same problem occurs.
Yes, sorry about this. We’re still not sure why 3.6 does this sometimes. Our best guess is power supply issues or ground loops.