Delay input/output

[ShuffleWire]

Is your feature request related to a problem? Please describe.
When working with real actuators / sensors, some of them take some times to take the order in consideration, or make a measurement and feed back the value. (due to the measurement scheme, the way the actuator work...)

Describe the solution you'd like
I wish I could have a parameter for actuators and sensors that allows to specify the delay of commands / measurement.

Describe alternatives you've considered
Currently, I'm implementing an history (actually a circular buffer), on the controller side, which handle it. But I've a lot a them, and it's not that handy to manage them. However it work as it.

[Thomas-Feldmeier]

timeStep documentation

Most devices (sensors/actuators) already have a time delay. E.g. Camera: wb_camera_enable(WbDeviceTag tag, 64) docu means that the camera will generate a picture with a 64 ms time delay.

note that the time in webots is not continuous, but in descrete time steps, given by WorldInfo basicTimeStep. docu. The default value is 32 (32ms, 1000/32 = 31.25 times per second (Hz)). A sensor/actuator cannot read data or change the world at another time than these timeSteps. That is why it is not possible to get a camera image with a time delay less then basicTimeStep. But you can use a multiple of that value, e.g. use wb_camera_enable(..., 1024) for an image after each second. If your camera is faster than 32ms, you could reduce basicTimeStep to match the speed of the camera.

a sensor sees the world from the end of the the last timestep (or the delay parameter in wb_camera_enable). all actuator commands are executed at the end of the actual timestep.

[ShuffleWire]

I do agree, but my real sensor provide a continuous stream of data, but the data arrive with a delay (for example 200ms). it's like a FIFO. I already working with a time step of 20ms (which is on what is based the whole project), and sensors provide data also at this rate. But they are not providing data only each 200ms, which what your solution would lead to.

[Thomas-Feldmeier]

lidar->enable(10*robot->getBasicTimeStep())

now if your worldInfoTimeStep is 20ms, your lidar will return new data only after 200ms. data arrive with a delay of 200ms.
e.g. reset world, manually time step 1-9 times, lidar returns nothing. time step 10-19, lidar returns what it has been seen on time step 0. at time step 20, it will return what it had been seen on time step 10.

if you mount the lidar on top of an rotating robot, and you turn on > View > Optional Rendering > Lidar Point cloud, you see the delay of the lidar (the lidar point cloud matches only the world, if you rotate the robot back to the point where the data was shot)

[Thomas-Feldmeier]

a continuous stream is not possible this way. a sensor has no data buffer except for one data set. so a lidar can't buffer 10 pictures, only 1.

[Thomas-Feldmeier]

theoretically you could make a chain of sensor->actuator->sensor->actuator.
e.g. camera 1 -> connect to display 2 -> seen by camera 3 -> connect to display 4 ...

[ShuffleWire]

a continuous stream is not possible this way. a sensor has no data buffer except for one data set. so a lidar can't buffer 10 pictures, only 1.
that exactly the idea behind this feature request :)

now if your worldInfoTimeStep is 20ms, your lidar will return new data only after 200ms. data arrive with a delay of 200ms. e.g. reset world, manually time step 1-9 times, lidar returns nothing. time step 10-19, lidar returns what it has been seen on time step 0. at time step 20, it will return what it had been seen on time step 10.
this is not what I wish, because you have holes in the data.

theoretically you could make a chain of sensor->actuator->sensor->actuator. e.g. camera 1 -> connect to display 2 -> seen by camera 3 -> connect to display 4 ...
that not convenient, nor easy to setup if you need multiple buffer, and what if it's not camera but bumper, speed sensor ?

to be clear, I can easily implement it on the controller side using a circular buffer, that not a bug deal, but have a simple field to toggle in the webots node would be a sick "nice to have" :)