Option to ignore error frames

[mathias-luedtke]

Alternative to #264 with proper interface definition
Parameter parsing is not implemented yet.

ToDo:

• implement parameter parsing for ROS packages
• supppress CAN_ERR_LOSTARB by default
• test, test, test

[mathias-luedtke]

@yanick-douven, @Timple: I have refactored this now, please give it a try.

It features an element-wise mask setting (like #388), but for the entries of the mask, not to ignore them.

CAN_ERR_LOSTARB is part of the default error mask (gets reported to ROS), but it is not fatal anymore.
The behavior can be changed by setting error_mask/CAN_ERR_LOSTARB to false or fatal_error_mask/CAN_ERR_LOSTARB to true.
Either from ROS or in a SettingsMap.

[Timple]

Code looks good. It's good to have the option tot ignore, inform and error.

From a code perspective it's approved. We will have an opportunity to test this friday.

[MCFurry]

Thanks for the effort @ipa-mdl
Indeed codewise looks good, we'll try to verify tomorrow on our hardware!

[Timple]

Running the code with default settings we noticed a lot of errors:

[W 0:29:07:407] Received frame is error: 20000002#0f00000000000000
[W 0:29:07:615] Received frame is error: 20000002#1100000000000000
[W 0:29:07:633] Received frame is error: 20000002#0900000000000000

We know now that these are arbitration errors because of the 2 before the #. But the error description could be more clear I guess.

[mathias-luedtke]

We know now that these are arbitration errors because of the 2 before the #. But the error description could be more clear I guess.

This is how socketcan_bridge reports error frames.
Which output would you like to get?

In general I do not recommend socketcan_bridge for production anyway..

[Timple]

Which output would you like to get?

The outcomes of this function seem quite readable. But this is a nice to have, not blocking.

In general I do not recommend socketcan_bridge for production anyway..

In the prototype phase it is very convenient to have all canbus messages in the bagfiles instead of setting up a seperate can logging system :)

[mathias-luedtke]

@ipa-hsd: Do you have time to test this PR with the robot in our lab?

[hsd-dev]

@ipa-mdl I could do this next week.

[mathias-luedtke]

@ipa-hsd: That's fine! Just check if the robot still moves properly :)

[Timple]

plan is to have a solution ready (merged..) until World ROS-Industrial day (July 7) :)

We came a long way, so a subtle ping to not let this fall asleep...

[hsd-dev]

I tried out the PR today with pilz robot with:

roslaunch prbt_moveit_config moveit_planning_execution.launch sim:=false pipeline:=ompl

It "works". But I get the following error message (it is the case even on melodic-devel branch of ros_canopen though):

[ERROR] [1595944295.136523793]: EMCY received: 83#0000000000000000
[ERROR] [1595944295.140129373]: EMCY received: 84#0000000000000000
[ERROR] [1595944295.143812940]: EMCY received: 85#0000000000000000
[ERROR] [1595944295.148101649]: EMCY received: 86#0000000000000000
[ERROR] [1595944295.151605465]: EMCY received: 87#0000000000000000
[ERROR] [1595944295.155340520]: EMCY received: 88#0000000000000000

[jschleicher]

@ipa-hsd Those aren't errors (all zeros) - the message is an Error (was stdout) since #286.

[mathias-luedtke]

@ipa-hsd: Thanks!

As already pointed out, these "errors" can be ignored (tracked in new issue #396)

[Timple]

Great! I'll make sure we test the debian release as well before the sync

[mathias-luedtke]

I pushed a new release: ros/rosdistro#26275