What I was thinking is that calling several prepare in the main loop may slow down the overall code and result in corrupted data (perhaps @traversaro may have some ideas on that). Discussing with @S-Dafarra, we may add a producer-consumer logic in VectorsCollectionServer. For the time being, I slightly modified the code to mitigate this effect by calling prepare only once per loop https://github.com/ami-iit/bipedal-locomotion-framework/pull/790.
While developing https://github.com/ami-iit/robot-log-visualizer/pull/74, I noticed that the data collected after https://github.com/ami-iit/bipedal-locomotion-framework/pull/767 got corrupted (cc @isorrentino @fils99).
Indeed, as you can see in the following picture, the measurement of torso roll becomes constant after 57 seconds.
To better debug the code, I wrote this simple example where I used the
VectorsCollectionServer
to stream the data:Then I opened a port in the terminal and tried to connect to
/test/measurements:o
(the port opened byVectorsCollectionServer
). I noticed that as soon as the number of data signals increases, several values become constant. As already pointed out by @S-Dafarra in https://github.com/ami-iit/bipedal-locomotion-framework/pull/767#discussion_r1403556267, we are currently calling BufferedPort::prepare several times.If the amount of streamed data is high, it may happen that the next prepare is called while the port is still writing, as explained in https://github.com/robotology/yarp/issues/1174.
What I was thinking is that calling several prepare in the main loop may slow down the overall code and result in corrupted data (perhaps @traversaro may have some ideas on that). Discussing with @S-Dafarra, we may add a producer-consumer logic in
VectorsCollectionServer
. For the time being, I slightly modified the code to mitigate this effect by calling prepare only once per loop https://github.com/ami-iit/bipedal-locomotion-framework/pull/790.