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?
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?
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.