Data logged by the YarpRobotLoggerDevice corrupted after 767

[Giulio Romualdi]

While developing ami-iit/robot-log-visualizer#74, I noticed that the data collected after #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:

#include <chrono>
#include <thread>
#include <BipedalLocomotion/YarpUtilities/VectorsCollectionServer.h>
#include <BipedalLocomotion/ParametersHandler/StdImplementation.h>
#include <yarp/os/Network.h>

using namespace std::chrono_literals;

int main()
{
    yarp::os::Network yarp;
    yarp.init();

    auto parametersHandler = std::make_shared<BipedalLocomotion::ParametersHandler::StdImplementation>();
    parametersHandler->setParameter("remote", "/test");

    BipedalLocomotion::YarpUtilities::VectorsCollectionServer server;
    server.initialize(parametersHandler);

    for (int i = 0; i < 500; i++)
    {
        server.populateMetadata("test" + std::to_string(i),
                                {"a", "b", "c", "d", "e", "f", "g", "h", "i", "l"});
    }
    server.finalizeMetadata();

    for (int j = 0; j < 4000; j++)
    {
        std::cout << "Sending data: " << j <<  std::endl;
        server.prepareData();
        server.clearData();
        for (int i = 0; i < 500; i++)
        {
            double t = i + j;
            server.populateData("test" + std::to_string(i),
                                std::vector<double>{t, t, t, t, t, t, t, t, t, t});
        }
        server.sendData();

        std::this_thread::sleep_for(1ms);
    }
    yarp.fini();
    return 0;
}

Then I opened a port in the terminal and tried to connect to /test/measurements:o (the port opened by VectorsCollectionServer). I noticed that as soon as the number of data signals increases, several values become constant. As already pointed out by @S-Dafarra in #767 (comment), 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 robotology/yarp#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 #790.

[Giulio Romualdi]

Closed with #790