Thank you for taking a look at the details here. That is indeed correct. With the Bullet spine, there is a delay of 3 substep durations between the observation dictionary and the internal simulation state.

Details on the three-cycle reset behavior

Upon reset, Spine::simulate cycles the actuation three times, but that is a consequence rather than a cause of how Spine::cycle_actuation is implemented. The internal state of the spine (looking at actuation_output_ and latest_replies_) during these three steps looks like this:

(Because actuation_output_ is a promise, I wrote between brackets values that will actually become available at the next call.)

So far we haven't considered reducing this delay. For instance in the PPO balancer we rather add lag to actions to training environments (although that's a lag not a delay, on actions rather than an observations). The spine was mainly designed for 1 ms substeps (to match the real robot), but in the setting you describe substeps are much longer. So I guess your question is: can we reduce the delay between the simulation state and observation dictionary?

Reducing substeps delay within the Bullet interface

Looking at BulletInterface::cycle again, one straightforward way in which we could reduce this number by one would be to step the simulation before reading sensors:

  read_joint_sensors();  // currently
  read_imu_data(imu_data_, bullet_, robot_, imu_link_index_, params_.dt);
  send_commands(data);
  bullet_.stepSimulation();

However, if the simulation step is $\delta t = 1$ ms, I'm concerned that stepping before would be less realistic than stepping after (as currently done). When a servo receives a CAN packet "here is your action, please report your observations" at time $t$, it will report the observation at time $t$ (corresponds to stepping after), rather than wait for $\delta t$ and report the observation at time $t + \delta t$ (corresponds to stepping before).