I’m part of a project where we’re considering to use ODrives as our motorcontroller of choice. Last year a C++ interface was written to communicate over USB (native protocol). Though after updating the ODrive firmware from v0.4.12 to v0.5.0 we started experiencing time-out errors. I think this is caused by a wrong CRC value as it is currently hard coded and imported from the library we based our interface on. As I’ve read on the forum here, firmware changes are likely to change the CRC which is also why I’d like to calculate it instead of hard coding. The documentation (https://docs.odriverobotics.com/protocol) gives the specs for the CRC calculation, however, as I’ve read at another topic (Using native protocol with Arduino) the CRC is not actually calculated over the whole package.
So long story short: what is used as input to calculate the CRC?
P.S. isn’t using CRC without incorporating the data kind of beating the purpose, as you won’t check whether the transmitted data has remained unchanged?
Thanks for the help!
The CRC is used to gaurantee that you are talking to the correct firmware-version.
If you connect to the ODrive using python/odrivetool you can monitor the communication using wireshark and determine which CRC is being used.
The python code that calculates the CRC is here: https://github.com/madcowswe/ODrive/blob/3c49b7f8caa6bebbae1de740109ddd5088e18b04/Firmware/fibre/python/fibre/protocol.py . If you want to know how it works, try setting a breakpoint while you are talking to the ODrive.
There have been quite a few changes to object names between 0.4.12 and 0.5.0, so the most likely issue is that your code is trying to access an object that does not exist, which depending on your code might result in a timeout. Have you made any changes to your C++ code to reflect this?
Do your errors happen all the time, or are they intermittent?
We’ll first give using wireshark a shot, as a quick fix.
Thanks for the reply.
The C++ code checks whether the requested objects are present in the imported ODrive json and gives errors if they are not found. Our test currently only requests to read/write to a very limited number of objects that we’re sure of that no changes to them have been made. This should’ve eliminated any errors ocuring due to name changes.
The errors do not occur when the json file is imported at initialization. This is one of the reason I suspect that a wrong CRC is at fault. As the CRC for requesting the json is a static 0x0001 even between the firmware updates.
The problem was the CRC as expected. As you suggested, using wireshark, I’ve backtracked the new CRC which is 0x9b40. The interface now runs smoothly.
Thanks for the help!