This was done in Microsoft Robotics Developer Studio using the SPL (simple programming language).
The sensor were already coded for us. We just had to initialize it correctly to link it to the correct device for the device to be able to use the sensor information.
During the execution of the program, we found out that there were race-conditions among the sensors since it was often the case when > 2 sensor would be inserting their data into their respective variables. But, since there only exist 1 communication channel between the simulated entity and the computer, which resulted in all information being lost and none of the variables being updated. Hence, we used a mutex (token) between the various sensors to ensure that the communication channel was not overloaded
The sensor were already coded for us. We just had to initialize it correctly to link it to the correct device for the device to be able to use the sensor information.
During the execution of the program, we found out that there were race-conditions among the sensors since it was often the case when > 2 sensor would be inserting their data into their respective variables. But, since there only exist 1 communication channel between the simulated entity and the computer, which resulted in all information being lost and none of the variables being updated. Hence, we used a mutex (token) between the various sensors to ensure that the communication channel was not overloaded
Above video shows how overtaking was simulated after taking into account an on-going vehicle. Initially, when the car is overtaking, the on-going was too near for the entire overtaking procedure to be complete. Hence, the car retreated back to its lane to retry the overtaking after a certain duration
Above video shows an up-close on how overtaking was executed
Above video shows the entire overtaking procedure without the concern of an on-going vehicle
Above video shows the most simplistic approach to overtaking which inspired all the above mentioned ways of overtaking