## About ego-vehicle reset delay

https://github.com/huawei-noah/SMARTS/issues/1407#issuecomment-1111605607

Then the problem is the following even if we get the traffic_history_provider to move to a different time:

>> ## assuming first agent mission start time is 0
>> start_time = 10
>> traffic_history_provider = smarts.get_provider_by_type(TrafficHistoryProvider)
>> traffic_history_provider.start_time = start_time
>> smarts_obs = smarts.reset(scenario) # <-- issue occurs here and does not return immediately
>> thp_time = start_time + smarts.elapsed_sim_time
>> expected_time = start_time + smarts.fixed_timestep_sec
>> assert thp_time <= expected time
~AssertionError 10.5 <= 10.1```

The ego-vehicle-reset problem still exists after the update https://github.com/huawei-noah/SMARTS/pull/1412.

Why can’t smarts return the ego-vehicle immediately? What is happening during the time?

I also observe that the delay times are different for different ego-vehicles (for about 0.2s ~ 1.xx s). Can we eliminate this delay time? The time delay is harmful since traffic-history-based vehicles are still running.

[Gamenot]

@YuechengLiu There is a workaround at current which will replace the vehicle at the correct time for any vehicle where elapsed_sim_time>=fixed_timestep_sec. Then the following will be true:

smarts.reset(scenario, max(0, history_start_time-smarts.fixed_timestep_sec))
assert math.isclose(smarts.elapsed_sim_time, history_start_time) # smarts.elapsed_sim_time == history_start_time

This is because SMARTS.reset(..) calls into SMARTS.step(..) which ticks over to the next time at the start of the step, does simulation, and then replaces the vehicle.

[YuechengLiu]

@Gamenot The PR works. There are no time delay greater than 2 steps in my experiments now.