Yarp: Error in position returned by yarp::dev::IEncoders::getEncoders

[triccyx]

Describe the bug
Somtimes yarp::dev::IEncoders::getEncoders fails to retrive the correct position. In this case the
old position is kept for 100-200msec.

To Reproduce
Use a sampling rate of 10msec at least

```c++
yarp::dev::IEncoders *iencs;
int nj=0;

yarp::os::Property deviceOptions;
deviceOptions.put("device", "remote_controlboard");
std::string remoteControlBoard = "/"+robotStr_+"/all_joints";
deviceOptions.put("remote", remoteControlBoard);
deviceOptions.put("local", "/" + robotStr_ + "/controlboard");

if(!robot.open(deviceOptions))
{
  ...
    return;
}
if(!robot.view(iencs))
{
   ...
    return;
}
if(!iencs->getAxes(&nj))
{
   ...
    return;
}            

while(positionLoggerActive_)
{
    bool error{false};
    std::vector<double> position(nj, 0.0);
    if(!iencs->getEncoders(position.data()))
    {
       ...
        error=true;
    }  

    for(std::string current:loggingJoints)
    {
        ...
    } 
    std::this_thread::sleep_for(std::chrono::milliseconds(10));
}

```

Expected behavior
The correct behaviour is that the method doesn't keep old values but update them.

Screenshots

0066-L_KN_P.log

Configuration (please complete the following information):

• OS:Ubuntu 16.04
• yarp version:3.01
  
  
  
  • compiler:gcc 5.4.0
  
  

Additional context

[pattacini]

Hi @triccyx

getEncoders does polling and should return false only when an internal timeout expires (as you've been observing). In this context, it's very likely that the server side of the motor control (i.e. the service running on robot) is not delivering fresh data at the expected rate.

Moreover, because of the polling, do not expect getEncoders to refresh data if they ain't any before the timeout expires.

[triccyx]

If I understand well the problem could be on the robot server side? I forget to say that all is working on the robot (yarpserver,logger).
The wrong data period is about 100-250msec.

[pattacini]

On the robot server side or on the communication channel itself (e.g. the bandwidth is limited, noisy channel, intermittent link...).

You might check the functionality through a simple yarp read ... /robot/all_joints/state:o.

[barbalberto]

We already did this test (with stateExt port, which is the one used by the client) and results still show some missing package, even if the yarp read shows fewer missing packages w.r.t. the client.

This issue needs an in-depth investigation to determine if the problem occurs in the server port, in the client port or in the client device.