Bipedal-locomotion-framework: GeneticSensorClient is not immediately ready after the creation

[GiulioRomualdi]

f I create a GeneticSensorClient with RobotInterface::constructGenericSensorClient and then I immediately populate the sensor bridge with setDriversList I got the following error:

[YarpSensorBridge::Impl::attachGenericOrAnalogSensor] right_foot_rear Mismatch in the expected number of channels in the sensor stream.
[YarpSensorBridge::Impl::attachGenericOrAnalogSensor] right_foot_rear Expected channels: 6. Number of channels: 0 <-------- I added this print to debug the problem
[YarpSensorBridge::Impl::attachAllGenericOrAnalogSensors]  Could not attach all desired Cartesian Wrench Interface.
[YarpSensorBridge::setDriversList] Failed to attach to one or more device drivers.

https://github.com/dic-iit/bipedal-locomotion-framework/blob/37269a7f936d9a40d306c2c36a4e8d90c76bb191/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridgeImpl.h#L344-L353

This happens because the polydriver seems to be not ready.

Adding this line before calling setDeriverList fixes the problem, however this is a workaround and it must be temporary

std::this_thread::sleep_for (std::chrono::seconds(1));

cc @traversaro @prashanthr05 @S-Dafarra

[traversaro]

The getNrOfChannels unfortunately just return the size of the latest message received: https://github.com/robotology/whole-body-estimators/blob/master/devices/genericSensorClient/GenericSensorClient.cpp#L187 . If you want to avoid that, you can either wait for getStatus to be true (aren't we do something similar for the controlboard?) or modify the generic sensor client to wait for the first message to be received before returning from open.

[GiulioRomualdi]

WHich do you think is the cleanest (and hopefully best) solution?

[S-Dafarra]

Relevant issue https://github.com/dic-iit/bipedal-locomotion-framework/issues/125

[traversaro]

WHich do you think is the cleanest (and hopefully best) solution?

For YARP network wrapper clients it is common practice to return from the open even if the first message has not been received, I think it is reasonable to have our own logic to try to read the data before existing from the configuration phase, as done in https://github.com/dic-iit/bipedal-locomotion-framework/pull/118/files .