Add Interfaces for reporting of error and warning messages from HW

[mamueluth]

Part of some bigger changes to Command-/StateIntefaces and Handles in general. First this PR has to be merged.

Add report interfaces for emergency stop, error and warning:

• The available report interfaces are: EMERGENCY_STOP_SIGNAL, ERROR_SIGNAL, ERROR_SIGNAL_MESSAGE,WARNING_SIGNAL and WARNING_SIGNAL_MESSAGE
  The idea behind this PR is that each component provides some default interfaces for reporting of errors, error messages and warnings and warning messages. StateIntefaces are used for this which default names (e.g. <component_name>/ERROR_SIGNAL).

The component interface (actuator_inteface, sensor_intefrace, system_inteface) creates and stores them locally. The interfaces are named like <hardware_name>/<report_interface_type>. E.g. if hardware is called rrbot -> interface for WARNING_SIGNAL is called: rrbot/WARNING_SIGNAL. Later with variant support the interfaces will hold following datatypes:

• Emergency Stop (bool)
• Error Code (vector(32))
• Warning Code (vector(32))
• Error Message (vector<string(128)>(32)
• Warning Message (vector<string(128)>(32)

Where the <error/warn>message_interfaces holds the error/warn message at position X for the <error/warn>interface's error signal at position X .

[mergify]

This pull request is in conflict. Could you fix it @mamueluth?

[destogl]

First batch of comments.

[destogl]

When we define those types, we should think about how to name them in URDF too. This looks a bit complicated.

What do you think if we say that the syntax for vectors/arrays is vector<_type_>[size] for example here would be vector<uint8_t>[32]. As long as we are pre-initializing the whole memory, by using reserve for example`, we should not be breaking real-time capabilities of the system.

Suggested change

	error_interface_info.data_type = "std::array<uint8_t>";
	error_interface_info.data_type = "vector<uint8_t>[32]";

[mamueluth]

The naming is to complicated. I will change it. But since the size should not be changeable, I would rather go with array then vectors.

[mamueluth]

wouldn't array also be better for realtime because of memory allocation?

[destogl]

Didn't we say to remove this and go directly with variants?

[codecov]

Codecov Report

Attention: Patch coverage is 51.89310% with 216 lines in your changes are missing coverage. Please review.

Project coverage is 48.04%. Comparing base (35bb5f7) to head (c27990a).
Report is 19 commits behind head on master.

❗ Current head c27990a differs from pull request most recent head 3d017a6. Consider uploading reports for the commit 3d017a6 to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #1319       +/-   ##
===========================================
- Coverage   75.51%   48.04%   -27.47%     
===========================================
  Files          41       42        +1     
  Lines        3328     3973      +645     
  Branches     1921     2160      +239     
===========================================
- Hits         2513     1909      -604     
- Misses        421      481       +60     
- Partials      394     1583     +1189     

Flag	Coverage Δ
unittests	48.04% <51.89%> (-27.47%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
..._interface/include/hardware_interface/actuator.hpp	100.00% <ø> (ø)
...re_interface/include/hardware_interface/sensor.hpp	100.00% <ø> (ø)
...re_interface/include/hardware_interface/system.hpp	100.00% <ø> (ø)
...rface/include/hardware_interface/hardware_info.hpp	60.00% <60.00%> (ø)
...re_interface/include/hardware_interface/handle.hpp	80.64% <83.33%> (-19.36%)	⬇️
hardware_interface/src/sensor.cpp	50.46% <55.55%> (-18.22%)	⬇️
hardware_interface/src/system.cpp	56.71% <61.11%> (-16.17%)	⬇️
hardware_interface/src/actuator.cpp	55.97% <55.55%> (-16.92%)	⬇️
hardware_interface/src/component_parser.cpp	44.48% <55.55%> (-48.76%)	⬇️
...ce/include/hardware_interface/sensor_interface.hpp	56.41% <52.23%> (-43.59%)	⬇️
... and 3 more

... and 23 files with indirect coverage changes

[bmagyar]

Can this be closed? Or massively refactored?

[mamueluth]

Can this be closed? Or massively refactored?

I Will refactor as soon as other stuff is merged. There are a lot of duplicate changes since i based on first PRs.