We have a working dual axis system using odrivev3.6 56V based on the precompiled firmware from (A) ODrive v3.6-56V 0.5.5 2022-08-11 12:25:27.963 ).
A python application does overall control via usb. It all works really well.
I get completely different (and faulty) operation between for .elf code built from the (B) the git hosted firmware compiled either bare-metal cross compile via vscode or through docker
I need to do some changes, to the C source code to support a special control mode which runs too slow in python. The git-derived firmware fails on motor calibration, with multiple motor-related errors. It also takes ~7 seconds to identify the odrive when starting odrivetool (compared to ~2sec for the other firmware)
I’ve tried exporting and importing the .json configurations with no luck. Uploading the .elf always fixes the problem.
Are the .elf files at (A) and (B) built from different source code which is not on git? is this source code available?
thanks for the reply. All of the different versions compile OK, but all of the source-code branches all fail in operation with various things like this after attempting a full calibration
they almost always involve both motors,
even though I only request a calibration of axis1
Only the (closed?) source .elf from the documentation part of odriverobotics.com works.
I would have expected at the same 0.5.5 version that the docker build to produce the same .elf, but its a much different file size and operates very differently.
e.g. with version 0.5.2 compiled from source using docker, I get this
axis0
axis: no error
motor: Error(s):
MotorError.CONTROL_DEADLINE_MISSED
MotorError.BAD_TIMING
axis1
axis: no error
motor: Error(s):
MotorError.CONTROL_DEADLINE_MISSED
MotorError.BAD_TIMING
Well I compiled it and am successfully running motors with it, so the issue must be at your end.
How are you uploading the firmware to you ODrive? Did you try using odrivetool with the generated .hex file?
There isnt a problem compiling and uploading the firware - I use STLINK cable supplied by Odrive. The problem I think is that the open-source version of motor calibration routine, esp. the inductance / resistance measurement which is not very good. It often fails on smaller motors I’ve been using as well as the bigger motor. From the fact that Odrive-company supplied firmware works much better, it seems like they improved the code but it hasnt made it back into the open source git version. I will fix the C code with STLink/GDB - its just a case of LI=VT and V=IR and I can see all of the variables for PWM and ADC in the C++ source, so it cant be too hard. No idea though why it reports both motors failing when I only start one channel though. I’ll share the C++ code once Ive fixed it. I think one of the reasons that not many people are adding to this code is because it is in C++. Most engineers use only C iin the microcontroller world, and I cant really see C++ helps here ( could just do C and have a this-> pointer to choose the channel. ).