Add message downsampler to avoid logger flooding when changing control mode

[mfussi66]

This PR aims to fix the issue: #768
To downsample the error messages rate, the logic of a simple Finite State Machine is implemented inside a yarp::os::Timer. The timer runs at 100Hz. If they exceed a threshold of 5 events, the FSM prints the number of error events occurred each second.
The proposed solution was tested on a desk setup with one joint, addressing the three types of error events mentioned in the issue.

The videos below show the results on the setup.

On the top left there's the Yarpmotorgui, where I change the control mode. On the top right there's the program tutorial_arm that sends the requests, and triggers the errors in the yarprobotinterface if the control mode is not the expected one. On the bottom there is the yarprobotinterface.

• From Position to Velocity

downsampler_position_to_vel-2021-11-16_09.41.15.mp4

• From Velocity to Position

downsampler_vel_to_pos-2021-11-16_09.58.11.mp4

• From Position Direct to Velocity

downsampler_direct_to_vel-2021-11-16_10.07.27.mp4

[pattacini]

cc @S-Dafarra

[pattacini]

Hi @mfussi66

Nicely done 👍🏻

I've only a minor comment and a request for improving the printouts.

[S-Dafarra]

Thanks a lot! Just as a curiosity, I have seen in the video above, you only change the control mode of a single joint. What happens if you do the same with multiple joints?

[pattacini]

Thanks a lot! Just as a curiosity, I have seen in the video above, you only change the control mode of a single joint. What happens if you do the same with multiple joints?

Good question!

In that file, there are only 3 "skipping"-like error messages and we address all of them, which are joint dependent.

@marcoaccame, how does it work with multi-joint commands? Are they unpacked and dealt with at the single joint level? If so we're ok, otherwise we're required to catch where else the error messages are yielded and manage them accordingly.

Perhaps, @mfussi66, you could quickly test the multi-joint approach as well (most likely straight on the robot).

[mfussi66]

Perhaps, @mfussi66, you could quickly test the multi-joint approach as well (most likely straight on the robot).

Yep, I'll check the availability of the robot and book it asap. I assume the code could be tested also on iCub2? In case iCub3 is not available.

[pattacini]

Perhaps, @mfussi66, you could quickly test the multi-joint approach as well (most likely straight on the robot).

Yep, I'll check the availability of the robot and book it asap. I assume the code could be tested also on iCub2? In case iCub3 is not available.

Yes, but wait for @marcoaccame's input first.

[S-Dafarra]

@marcoaccame, how does it work with multi-joint commands? Are they unpacked and dealt with at the single joint level? If so we're ok, otherwise we're required to catch where else the error messages are yielded and manage them accordingly.

By experience, I think this is the case

[marcoaccame]

@marcoaccame, how does it work with multi-joint commands? Are they unpacked and dealt with at the single joint level? If so we're ok, otherwise we're required to catch where else the error messages are yielded and manage them accordingly.

So far, every call to velocityMoveRaw(), positionMoveRaw() and setPositionRaw() for any joint contributes to reach the threshold.

So, if the threshold of events is 5 and the device is for instance left_arm-eb24-j4_7 which manages 4 joints, then one velocity move of the entire part increments 4 times and the next velocity mode exceeds 5 and triggers the threshold.

If desired, it is possible (and easy) to modify the implementation so that there is one counter per each joint.

[pattacini]

Thanks @marcoaccame 👍🏻

So, if the threshold of events is 5 and the device is for instance left_arm-eb24-j4_7 which manages 4 joints, then one velocity move of the entire part increments 4 times and the next velocity mode exceeds 5 and triggers the threshold.

That's how it is supposed to work, so far so good 👍🏻

If desired, it is possible (and easy) to modify the implementation so that there is one counter per each joint.

We can certainly make things more general and configurable but I would like to go on with this current state to reach a first MVP.

Therefore, I'm waiting for the CI to complete and then merge the PR.

[pattacini]

Minor refactoring.

[S-Dafarra]

I would just suggest a more descriptive message. I am afraid that Detected 1024 events on aggregate since the last message might be a little cryptic if you miss the first message about the wrong control mode.

[pattacini]

I would just suggest a more descriptive message. I am afraid that Detected 1024 events on aggregate since the last message might be a little cryptic if you miss the first message about the wrong control mode.

We have just added the new logging component and we may rely on that.
See #770 (comment).

Perhaps, @mfussi66, you may call the component something like mc.msgdownsampler.skipped-cmd-wrong-mode instead of mc.downsampler.