You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>usingnamespacestd::chrono_literals;intmain()
{
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();
return0;
}
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.
The text was updated successfully, but these errors were encountered:
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: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 #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.The text was updated successfully, but these errors were encountered: