Improve HRIM module error management

[carlossvg]

Describe the feature that you would like to include:

This is an open discussion on order to extend HRIM error management.

Additional context

Currently errors in HRIM are just a subfield on certain topics. There is not a common way to deal with errors for all the components. For instance, in the case of HRIM/models/actuator/servo/topics/state.xml the error are specified in field called fault with the following faults:

• "FAULT_NONE": 0
• "FAULT_CURRENT": 1
• "FAULT_TEMPERATURE": 2
• "FAULT_BUS_VOLTAGE": 3
• "FAULT_BRIDGE_DRIVER": 4

It would be good to have a common definition of error that can be shared by all modules. In this way, error management could be consistent for different types of modules. The error semantic would be different for each component, but not the structure. That means that I can call the same function in order to retrieve the error for an actuator or a gripper.

I propose to follow a structure similar to the one used in CMM machine standard language (I++ DME (Dimensional Measurement Equipment) | NIST) (chapter 8 Error Handling):

---

---

In this implementation the error is composed by:

• A severity code (F1)
• A code defined inside the standard (F2). This could be an error defined in HRIM.
• Native error code (F3). An error code which is provided each component vendor. i.e: 0x0080 (Position following error).
• A string describing the error.

Apart from the message structure we would need to define an error classification for each component type. Some error codes could be common for all modules (i.e: communications failure, generic, wrong parameter, etc..) and other specific for each module type.

[ahcorde]

A quick fix could be to have a bigger error field. Instead of 8 bits use 32. Using the first 8 bits for the HRIM error and the rest for the specific error code.

---

But it's true that probably we need to add a generic message with error codes. I really like the proposal. Do you think this should be a topic or a service?

[carlossvg]

IMO it fits better with a service. The error could be signaled in a subfield of a topic, for example as boolean has_error or knowing that the node is in an ERROR transition or by other means. Then, once we know there is an error we could retrieve the error information as a service.

[ibaiape]

As a quick pitch, how about conveying the state (like the F1 you mention @carlossvg) in a general way in state (not just a boolean), and have the specific error information as a service? Might not be necessary and maybe just indicating there is an error, as you say, is enough.

I'd say whether we include this into generic or into each component's model depends on if we are going to specify error codes or not.

Meaning, if we'll specify possible error codes the list could probably get long quite quickly for a single interface (unless we are going to specify a couple and the rest are implementation-specific), and it would make sense to break that up into components, or at the very least into component types (sensor, actuator...).

Alternatively, if we are going to leave it open to be implementation-specific, we could just add it as a generic service.

I do have a question with this: wouldn't it being a service instead of a continuously published topic affect logging to some extent? I might be overthinking it, but wouldn't the operator want to know the moment of the error with as much precision as possible? I guess a "logger" node could react to that state change and call the service itself...