During a race after approximately 1m30s, the car seems to stop being driven by the simulator as the steering is locked and it does not continue to accelerate.
We found that this is because when computing the simulated schedule of all the task per resource (ECU) it takes x amount of time to do so. This amount of time is dependent on the hyperperiod. So, when the computed schedule runs out, a new schedule plan must be computed via the extract_schedule function. However, this takes another non-negligible x amount of time. During this time while the schedule is being re-computed the simulator cannot (and does not) communicate with TORCS hence to the user it seems as if the car was stop being driven.
We (@BaeInpyo and I) could solve this issue by increasing the hyperperiod to a large value. However, that produces another problem. Now, at the beginning of the race, precious seconds (even minutes) are lost as the simulator tries to compute the first schedule.
A better solution will allow the scheduler be re-computed without affecting the state of the race. We tried to speed up the extract_scheduler function by creating a thread per resource as it computes the new schedule (reference commit: https://github.com/BaeInpyo/CPSim_linux/commit/5beec5f9922ce3ea096280a704d2fffcd07ecbef ). However, this optimization is not enough to completely solve the problem.
We propose another solution to this problem but it requires a small modification of TORCS. The overall idea is the following: the simulator can communicate with TORCS indicating when the new schedule needs to be recomputed. TORCS will receive this information and temporarily pause the current race until the simulator indicates TORCS that the new schedule has been computed. We achieved this via shared memory.
During a race after approximately 1m30s, the car seems to stop being driven by the simulator as the steering is locked and it does not continue to accelerate.
We found that this is because when computing the simulated schedule of all the task per resource (ECU) it takes
xamount of time to do so. This amount of time is dependent on the hyperperiod. So, when the computed schedule runs out, a new schedule plan must be computed via theextract_schedulefunction. However, this takes another non-negligiblexamount of time. During this time while the schedule is being re-computed the simulator cannot (and does not) communicate with TORCS hence to the user it seems as if the car was stop being driven.We (@BaeInpyo and I) could solve this issue by increasing the hyperperiod to a large value. However, that produces another problem. Now, at the beginning of the race, precious seconds (even minutes) are lost as the simulator tries to compute the first schedule.
A better solution will allow the scheduler be re-computed without affecting the state of the race. We tried to speed up the
extract_schedulerfunction by creating a thread per resource as it computes the new schedule (reference commit: https://github.com/BaeInpyo/CPSim_linux/commit/5beec5f9922ce3ea096280a704d2fffcd07ecbef ). However, this optimization is not enough to completely solve the problem.We propose another solution to this problem but it requires a small modification of TORCS. The overall idea is the following: the simulator can communicate with TORCS indicating when the new schedule needs to be recomputed. TORCS will receive this information and temporarily pause the current race until the simulator indicates TORCS that the new schedule has been computed. We achieved this via shared memory.
Reference commits
This commits and other improvements will later be published for a pull request.