Closed prashanthr05 closed 3 years ago
Mmh at first sight, I'd recommend to develop a wrapper device that could attach to any device exposing IWear
. This means that it could attach to individual devices like Xsens suit or the F/T shoes, but it would also work if attached to the IWearRemapper
that unifies multiple producers.
I think of this logger as the dumper counterpart of the IWearWrapper
, where the wrapper instead of dumping the data, it streams it over the network (using thrift serialization).
I would suggest just copy-and-pasting the code of IWearWrapper
and substitute the thrift data structure with the yarp telemetry system. I would also keep the two things independent.
I had tried to add a dic-iit/matio-cpp-based logging at a consumer level (a client device that attaches to a iWearRemapper, for example HumanStateProvider in robotology/human-dynamics-estimation). However functional, this implementation has the limitations of not having a periodic save and also uses a dynamic memory allocation by resizing the vectors all the time. So this might not be suitable for a long-term logging. Further, there is also the delay introduced from passing the information from the producer to the consumer.
I don't think I understood entirely in what this would differ to the option above, but I'm a bit rusty with the wearable architecture.
A possible model for such devices is the telemetryDeviceDumper in https://github.com/robotology/yarp-telemetry/tree/master/src/telemetryDeviceDumper . That devices operates on standard YARP interfaces, but we could copy it and create a similar device that dumps from Wearables interfaces.
Thanks, I think we can have a good starting point combining telemetryDeviceDumper
and iWearRemapper
.
CC @claudia-lat
Is your feature request related to a problem? Please describe.
Currently we are using the wearable implementation in the robotology/human-dynamics-estimation pipeline to access the human-worn sensors data like IMU, FT shoes measurements, etc by providing relevant implementations for the
iWear
interface. The desired problem in hand is to be able to log these sensor data available through theiWear
interface into a file (mat file), so that it could improve debugging/testing through offline processing.Describe the solution you'd like The
iWearWrapper
provides a possibility to pack multiple sensor measurements and pass it through a port. Apart from passing this wrapped data through a port using the thrift data structure, it would also be beneficial if we can optionally log these data to a file at theiWearWrapper
level. We could possibly add a flag that will allow us to optionally log this data.An useful dependency for this purpose could be yarp-telemetry which allows periodic saving and also uses a memory-efficient circular buffer based implementation. However, the limitation is that we can only save the data as channels of vectors (cannot store data as a struct), but this is only a semantic problem.
Describe alternatives you've considered I had tried to add a dic-iit/matio-cpp-based logging at a consumer level (a client device that attaches to a iWearRemapper, for example HumanStateProvider in robotology/human-dynamics-estimation). However functional, this implementation has the limitations of not having a periodic save and also uses a dynamic memory allocation by resizing the vectors all the time. So this might not be suitable for a long-term logging. Further, there is also the delay introduced from passing the information from the producer to the consumer.
It would be helpful to have this logging at a higher level as a generic implementation, which can be extended for any suitable implementations using the
iWearWrapper
interface.I had a discussion with @Yeshasvitvs regarding the logging and we came to an understanding that
iWearWrapper
level logging could be a possibly feasible solution. cc @lrapetti @traversaro @S-Dafarra @diegoferigo Let me know about your opinion.Also please correct me if my understanding of the underlying software architecture seems incorrect.