...
When testing our application try to imagine yourself in the following situation:
You are programming a small flying quadrocopter to follow navigation commands. It is presented at the figure below as the black bended clipper. It needs to go for few meters in the X direction and then int needs to turn left.
The quadrocopter carries a laser scanner which measures the distance between the quadcopter and the ground and the wall. The quad applies controlls to its motors which make it go or turn.
There is a position sensor on the side which scans the area searching for the quad and then reports its position to the controlling computer. The controlling computer receives the position and publishes waypoints which the quad tries to follow. All that information is passed along between the different components on the local network.
So, when you start the quadrocopter you expect that it will follow the dots in the map. You let it fly and it reaches the turning point very quickly, but it doesn't turn. Disappointed, you stop the quad and look at the data on your robo-monitor (our application).
The moment you start the application all the data is replayed from the start of the experiment.
All of these components are prone to failure: The laser scans can report wrong information, or just don't report any information.
The quad mechanics or electronics can be mis-wired which may lead to applying wrong controls to the motors. The position sensor suffer from
the same types of errors like the laser scanner and the ground computer may be buggy, may have virus, or may just use a wrong algorithm.
So, when you start the quadrocopter you expect that it will follow the dots in the map. You let it fly and it reaches the turning point very quickly,
but it doesn't turn. Disappointed, you stop the quad and look at the data on your robo-monitor (our application).
The moment you start the application all the data is replayed from the start of the experiment.
Your task is to find what is wrong with the quadcopter and why it did not turn.
...