imuFilter device is no longer in sync w/ incoming data

[pattacini]

Bug description

With the imuFilter device driver's addition in #592, the component is no longer in sync with the incoming data.

As a result, we have been experiencing warnings generated by the velocity estimators and as a consequence the necessity to sub-sample the data.

Steps to reproduce

See detailed discussion in #728.

Expected behavior

The imuFilter device should be able to handle each single incoming data with a callback instead of using a periodic thread.

Example repository

No response

Additional context

No response

[traversaro]

@traversaro I have some ideas on how to do that, this comment is a reminder for me to comment here.

[pattacini]

Hi @traversaro

Do you have any plan for this activity?

[traversaro]

Not that they I want to work in the immediate future, but I had an idea for this kind of use cases (in which a device needs to do something, but we would like this "something" to be synchronized with something else).

Basically, a lot of YARP devices do things, in a way or another. In most cases, this devices inherit from yarp::os::PeriodicThread, that kinds of hardcode the fact that each device has its own thread. A possible alternative (that however will take time to implement) is for this device to implement a different interface, something like yarp::os::Activity, that would expose the usual yarp::os::PeriodicThread methods, but with the main difference that it would be support to delegate the actual invocation of this method to an already existing thread, unless specified otherwise in the options. To do so, I imagine having a yarp::dev::ActivityRunner device whose only goal is to run the Activity that are assigned to it, but in the same thread with the specified order. The trigger on which the ActivityRunner could be some period, or even an external event.

However, this is just a sketch, and definitly not a quick solution to this specific problem. However, if we are interested we can discuss about this in person.

[pattacini]

I believe I got the idea and I like it quite a lot.
There are many cases where this new layer would come definitely in handy.

This problem is not urgent at all and I would even keep it on hold to let it serve as the very first testing scenario for the upcoming new service.

Probably, something that we can also discuss during our monthly SW meetups.