API to get update timing

[ShuffleWire]

Hello,

Maybe the feature is already available, if so tell me.

I'm using sensors (GPS) that give info not every time step (usually every 1s). However, at each timestep I get the value of the last update, and I've no way of telling if it's the old value or if I'm simply standing still. So I have to implement another timer with the same period that warn me when my value are new. It's very inconvenient, and add synchronisation issue.

Use case : I have a simple GPS receiver that, IRL give me a message every 1sec. The rest of the time, I have no value, and my process know is should 'fill the gap", instead of relying on a steady value.

Would it be possible to know when the data is new ? Without breaking existing behaviour (return last value), I would simply add a new API targeting devices (bool wb_is_updated(WbDevice)), which say True at the timestep during which the value have been updated, and False otherwise.

What do you think ?

Cheers

[CoolSpy3]

I'm not aware of a way to do that with the current API, but it sounds like it would be a useful feature. I'd rather introduce this as an API to get the last timestep when the device was updated (which may be more useful for some users than a boolean). (Something like wb_device_get_last_update.) It looks like that should be possible by tying into WbSensor::lastUpdate. Users could then check whether the value is up to date by doing wb_device_get_last_update(...) - wb_device_last_update_timestep(...) < timeStep. I'm busy with some other stuff, so I can't tackle this now, but I'll keep it in mind for when I get some free time. Alternatively, if you want to implement it, feel free to open a PR.

[omichel]

I believe there is no need for a new API function, as the current API has everything you need to address this problem. In particular, you can use the following functions:

• gps_enable(gps, sampling_period)
• robot_step(duration)

The algorithm you need is very simple:

  int current_time = 0;
  const int time_step = 10;                         // perform simulation steps of 10 ms
  const int gps_sampling_period = 1000;             // make a GPS measurement every second
  const DeviceTag gps = robot_get_device("my gps");
  wb_gps_enable(gps, gps_sampling_period);
  for(;;) {
    wb_robot_step(time_step);
    if (current_time % gps_sampling_period == 0) {  // is the current time is a multiple of the GPS sampling period?
      const double *values = wb_gps_get_values(gps);
      printf("New GPS measurement: %d %d %d\n", values[0], values[1], values[2]);
    }
    current_time += time_step;
  }

Note

The first measurement may be NaN NaN NaN as the GPS device may not initialized at time step 0.

You may also want to use robot_get_time() to get the actual current_time from Webots instead of computing it in the controller.

[ShuffleWire]

@omichel That could work in my use case, (and might do like that) but IMO (but could be wrong) would not work in the general case if your sampling period is not a multiple of the timestep, and then you have to implement some more advanced logic to make it work.

@CoolSpy3 Yes getting the last update time could be better

Feel free to close if you feel it's not useful enough, but I still believe it could provide a more convenient way of simulating real "intermittent" hardware.

[CoolSpy3]

I think in that case, you could still do current_time % gps_sampling_period < time_step. One (niche) case that I think might be a problem is if people are writing plugins or modularized code where the sampling period/main loop timestep is unknown or when the gps is not enabled at timestep 0 (which I could maybe see being a problem if a controller is hot-swapped while the sim is running¹ [or if the controller uses some wonky startup code]). (Although, I am not sure how common any of those use cases are.)

There are ways that controllers could get more-fancy to work around those cases, but in general, I think that an explicit method to get the update time would probably more readable in controller projects. Although, now that I think about it not all devices have sensors (ex. Display), so some thought would have to be given to how such an API would be implemented.

¹ Fun fact, if the controller is the one to enable the GPS, your solution of keeping track of current_time instead of calling robot_get_time actually works around this :P