Difference in single-joint and multiple-joints commands transmission

[pattacini]

Apparently the following two code snippets should accomplish the same job, but they actually do not.

ivel->velocityMove(0,20.0);
ivel->velocityMove(2,20.0);
for (int j=3; j<6; j++)
    ivel->velocityMove(j,30.0);

VectorOf<int> joints(3);
Vector vel(3);

joints[0]=0;
joints[1]=2;
vel=20.0;
ivel->velocityMove(joints.size(),joints.getFirst(),vel.data());

joints[0]=3;
joints[1]=4;
joints[2]=5;
vel=30.0;
ivel->velocityMove(joints.size(),joints.getFirst(),vel.data());

While the commands sent by the first snippet are always received and executed by the robot, one of the two commands of the second snippet is always skipped.

[pattacini]

By design, certain commands (e.g. setPosition(), velocityMove(), setRefTorques() ...) travel on streaming channels, meaning that the driver sends the data but does not receive any high-level reply from the robot.

However, the behavior differs if we call single-joint or multiple-joints methods.

For single-joint calls (e.g. velocityMove(j,val)) the writeStrict communication property is enabled by default, thus the driver first waits for the completion of any pending transmission and then proceeds with the new transmission. This means that we are sure that we shoot all our bullets but there is no guarantee that the receiver runs fast enough to process them. As result, there might be some packets loss if the number of single-joint calls is too high with respect to the rate of the receiver.

On the other hand, for multiple-joints calls (e.g. velocityMove(nj,joints,vals)) the writeStrict attribute is off by default; therefore, two subsequent transmissions that are too close in time might cause one to be lost already at the transmitter side.

While opening the driver the user can enforce the same behavior irrespective of the method types (e.g. writeStrict always on) by configuring the driver with the following options:

Property option;
option.put("device","remote_controlboard");
option.put("remote","/icub/head");
option.put("local","/client");
option.put("writeStrict","on");

[lornat75]

The recently implemented IVelocityControl2 interface allows controlling group of joints in a sigle call so that tight loops should not be needed.

[lornat75]

IPositionControl commands are all implemented with replies, subsequent commands should be all executed even in tight loop. This is because these messages are supposed to be sent at slower rate.

The newly implemented IPositionDirect on the other hand allows sending commands that are not interpolated, these messages behave like commands in IVelocityControl so subsequent calls may be dropped.

[alecive]

Thanks @pattacini , yours was a great clarification.