Open GiulioRomualdi opened 3 months ago
Does the same thing happen also for other data? I wonder if the condition in https://github.com/ami-iit/bipedal-locomotion-framework/blob/4e85d4d3c965b84f8a6ffa61a2678eceb9702f37/devices/YarpRobotLoggerDevice/src/YarpRobotLoggerDevice.cpp#L1483 was returning false
maybe?
we were wondering if there is an issue in the saving of the data using the inner thread of robometry
The hunch might be correct. Checking the periodic save code in https://github.com/robotology/robometry/blob/bb2ea36c90141b9a6ac2be903619786734f95a52/src/librobometry/src/BufferManager.cpp#L230-L249, it seems that it locks the mutex m_mutex_cv
, but this mutex is not locked when pushing back to the channel https://github.com/robotology/robometry/blob/bb2ea36c90141b9a6ac2be903619786734f95a52/src/librobometry/include/robometry/BufferManager.h#L421-L453.
This might mean that while saving the buffer (done in https://github.com/robotology/robometry/blob/bb2ea36c90141b9a6ac2be903619786734f95a52/src/librobometry/src/BufferManager.cpp#L158-L202), it is still possible to push to the channels that have not been saved yet 🤔
We noticed that some datasets we collected back in time are corrupted because the length of the joint position differs from the one of the joint velocity. This shouldn't happen since the pushing in the buffer manager and retrieving the data are done in the same thread of the logger.
Looking at the timestamps of the data we noticed that the data related to the joint position is longer than the one of the joint velocity.
Notice that for this specific dataset, the data were saved by the inner thread of the buffer manager and not closing the application. Since this behavior does not happen in the case of the logger being closed (i.e., the buffer manager is destroyed) we were wondering if there is an issue in the saving of the data using the inner thread of robometry
cc @traversaro @S-Dafarra @LoreMoretti @isorrentino
Associated to: https://github.com/ami-iit/bipedal-locomotion-framework/issues/877