Bug with Motor Error enums?

1

Hi there, i am confused about the motor error enums.

Everywhere i looked there were many motor errors and the values for the last enum values are very large. So large that is is in fact too large for a 32-bit integer. However, all error codes are supposedly int32’s. What am I not seeing or is this a mistake and no one has seen it since ODrive exists?

This is an example from the ODriveArduino library ‘ODriveEnums.h’:

enum MotorError {
    MOTOR_ERROR_NONE                         = 0x00000000,
    MOTOR_ERROR_PHASE_RESISTANCE_OUT_OF_RANGE = 0x00000001,
    MOTOR_ERROR_PHASE_INDUCTANCE_OUT_OF_RANGE = 0x00000002,
    MOTOR_ERROR_DRV_FAULT                    = 0x00000008,
    MOTOR_ERROR_CONTROL_DEADLINE_MISSED      = 0x00000010,
    MOTOR_ERROR_MODULATION_MAGNITUDE         = 0x00000080,
    MOTOR_ERROR_CURRENT_SENSE_SATURATION     = 0x00000400,
    MOTOR_ERROR_CURRENT_LIMIT_VIOLATION      = 0x00001000,
    MOTOR_ERROR_MODULATION_IS_NAN            = 0x00010000,
    MOTOR_ERROR_MOTOR_THERMISTOR_OVER_TEMP   = 0x00020000,
    MOTOR_ERROR_FET_THERMISTOR_OVER_TEMP     = 0x00040000,
    MOTOR_ERROR_TIMER_UPDATE_MISSED          = 0x00080000,
    MOTOR_ERROR_CURRENT_MEASUREMENT_UNAVAILABLE = 0x00100000,
    MOTOR_ERROR_CONTROLLER_FAILED            = 0x00200000,
    MOTOR_ERROR_I_BUS_OUT_OF_RANGE           = 0x00400000,
    MOTOR_ERROR_BRAKE_RESISTOR_DISARMED      = 0x00800000,
    MOTOR_ERROR_SYSTEM_LEVEL                 = 0x01000000,
    MOTOR_ERROR_BAD_TIMING                   = 0x02000000,
    MOTOR_ERROR_UNKNOWN_PHASE_ESTIMATE       = 0x04000000,
    MOTOR_ERROR_UNKNOWN_PHASE_VEL            = 0x08000000,
    MOTOR_ERROR_UNKNOWN_TORQUE               = 0x10000000,
    MOTOR_ERROR_UNKNOWN_CURRENT_COMMAND      = 0x20000000,
    MOTOR_ERROR_UNKNOWN_CURRENT_MEASUREMENT  = 0x40000000,
    MOTOR_ERROR_UNKNOWN_VBUS_VOLTAGE         = 0x80000000,
    MOTOR_ERROR_UNKNOWN_VOLTAGE_COMMAND      = 0x100000000,
    MOTOR_ERROR_UNKNOWN_GAINS                = 0x200000000,
    MOTOR_ERROR_CONTROLLER_INITIALIZING      = 0x400000000,
    MOTOR_ERROR_UNBALANCED_PHASES            = 0x800000000,
};

These error codes are also in the documentation, so I assume they are correct.

In C++, enums are by default interpreted as ints, which is in many cases by default int32, just like the endpoints say. But when putting this code into Visual Studio it screams that the last 4 enum values are too large and are all interpreted as 0!

What am I overlooking?

If I’m not mistaking this would result in the last 4 errors never getting called (and not even handled, simply ignored as if nothing happened)

2

Also, i keep getting the Axis Error 0x200 along with motor and encoder errors, but I cannot find it anywhere in the documentation, what is this error?

3

Use dump_errors(odrv0) to decode it. Make sure you’re on the newest firmware (0.5.4) first.

I can confirm I’m seeing the same thing. I think it’s just a bug :slight_smile:

The way we implement errors means it will still shut down the controller, but it might not properly indicate an error.

4

I am currently finding a lot of things, maybe because i am working on a new ODriveGUI.

I am developing for fw-0.5.1 because we are bound to that version because the UART native protocol is unusable. Have many enums been changed since then?

I’m seeing many enums like e.g. axis0.requested_state (which are essential) are simply wrong in the documentation (off by one), the same is for other enums and especially errors. I didn’t take a lot of time to compare versions to see if my firmware is outdated, but it seems that the firmware is still up to date and the documentation is simply wrong.

Maybe i overlook something, but what’s behind this? I don’t want to offend anyone but if my observations are corrent, how can it be that something so essential has not been recognized for so long?

EDIT: I originally looked at ODrive Reference — ODrive Documentation 0.0 documentation, there the information is wrong. I thought this was the up to date documentation. Later i looked at the beta docs ODrive.Axis.AxisState | ODrivePrivate and there the information is correct, but weirdly it’s hidden in “ODrive” instead of “ODrive3”. What’s the reason behind those two documentations, which is correct? Is the beta doc usable or is it in long time maintenance?

5

I am developing for fw-0.5.1 because we are bound to that version because the UART native protocol is unusable

? What are you referring to?

Yeah sorry there is a bug in the new docs in regards to enums. The enums are correct in the .yaml, the generated files (See ODriveEnums in the Arduino library), and in the old docs. The updated docs (which released last week) use a slightly different code to generate them and we forgot to account for “skipped” values. I’ve already informed the team.

Is the beta doc usable or is it in long time maintenance?

Beta docs are for the V4 / Pro / S1 boards. The protocol may not match between V3 and V4 hardware

Any reason why you don’t want to fork and upgrade the existing V3 GUI?

6

I am referring to this thread: ODrive ignores most requests in UART native mode

The UART Native backend has been completely rewritten since fw-0.5.1 and as others confirmed in other threads, it’s mostly unusable in its current state as about 95% of the packets are simply ignored. That’s why we need to stay with fw-0.5.1 until this gets fixed. We don’t have the knowledge and time and resources to do it ourselves.

Me and my colleagues have used the ODriveGUI Beta sporadically for about half a year now and we had a very frustrating experience. It’s slow, constantly hangs and randomly disconnects all the time for no reason and doesn’t reconnect. Even when simply setting some things and not unplugging it, it randomly disconnects and you have to restart the entire ODriveGUI every 5 to 10 minutes. Additionally, the inputs are very vague and you never know if numbers arrived.

I am convinced the developers have put a lot of effort into it, but unfortunately it was very frustrating for us to use.

There’s no way i’m going to write JavaScript code so i’m certainly not able to fork the original.

TL;DR; I decided to do it myself and wrote it completely from scratch in about 4 days using C++, based on libusb, Allegro5 and ImGui. It’s still work in progress but it’s already fully functional.

image
image1282×754 71.1 KB

It was only intended to be a little side project to see how hard it’s gonna be and it’s going great. When it’s finished i may make the source code public or upload the ready-to-use executable, if someone is interested.
(It’s currently Windows only, but it could be ported to linux if someone has the time to do it)

It’s not intended to replace the original ODriveGUI but I think it’s a lot more robust and better for setting a lot of data without interruptions: Just a much more performant alternative. (Plotting and wizard are still on the to-do list)

2 Likes
7

Hmm… I’ll investigate.

Seems like a waste of existing code, but sure

Why not? We’re not supporting the original GUI, so please do replace it!

Error enum issue in the docs is fixed, btw, the docs just need to be regenerated.

1 Like
8

Thanks. I’ll see what i can do.

When I have enough time to continue work on it and i think the code is in a usable state for public use i will make sure to publish it in a new thread, but i can’t assure anything.

1 Like
9

Sounds good. I have some news about the fibre-over-uart. Unfortunately we just don’t have the time to debug this at the moment. But we suspect it’s probably something in PacketUnwrapper… Because the same did_receive function is used for ASCII which works fine, and has robust testing.