Cross walk detection

[manuelgitgomes]

Discover and implement a way to detect the crosswalk. See particle filter for detection - @Almeida-a Record video of the car passing on the crosswalk, create package for crosswalk detection - @manuelgitgomes

[Almeida-a]

The new/issue154 will be the development branch for this issue.

[Almeida-a]

I created a test (test.py) environment in the previous commit. TODO:

• [x] Record time which takes to process one frame and print the fps (1/seconds) in the terminal
• [ ] Transform test into an annotation, allowing to write @stateless_test above the algorithm functions, in order to easily test them

[Almeida-a]

Work progress:

• Std-out displays information about the performance of the algorithm (only for stateless algorithms, with stateless_test)
• Laid out some groundwork for developing stateful algorithms (such as filter based ones)

[Almeida-a]

This simple approach seems to extract well the characteristics of the track within the gazebo environment.

This image depicts the probability [0, 1] of the presence of white pixels in each frame.

Needless to say, the spike indicates the car was seeing, at the respective frames, a crossroad. This indicates us that, in a gazebo environment:

• A frame without a crossroad, and only with the basic road lines, will have a probability of 5+-1% of white pixels.
• A frame with a crossroad will have, naturally, higher probabilities of the same, up to 16%.

Next task is to map these probabilities to the distance of the car to the crossroad.

[manuelgitgomes]

Me and @Almeida-a started implementing this algorithm in ROS. When doing so, an issue arose as the ml_driving script was being used as a decision making script. To avoid multiple responsibility, a new package was created called prometheus_decision, in which a script receives the steering angle from the cnn, the signal detected and if a detection of a crosswalk is detected. Then, a decision is taken and sent to the robot. Commits will come soon.

[Almeida-a]

A new problem arose: the car should ideally stop when the front wheels are within the area of the first strip of the crosswalk which is closest to the car. This is an issue because it will always coincide within the downward slope region of the bright pixels algorithm's graph -- -- meaning that the robot's reaction to the crosswalk will not be proportional to how much 'white' it sees, contrary to this basic algorithm's goal.

Therefore, a change in approach is due.

Two approaches were brought up to address this matter:

• Introduce a timeout duration based on which the robot will choose to stop after getting ~100% in the brightness algorithm (~15% of bright pixels). The timeout value can be tuned and converge to an unique value as long as the robot's velocity remains fairly consistent
• Implement a stateful algorithm - after the robot approaches close enough to 100% in the brightness index value, it will 'jump' to a new state where it will decide when to stop, but this time the decision is based on the brightness algorithm as well.

[TatianaResend]

Since the panel is not centered on the right side the car is stopping almost in the correct place, but on the left side it is stopping way behind. Therefore, it is necessary to correct the position of the panel and retest where the car stops.

[TatianaResend]

Changing the height of lcd1 and lc2 from 1m to 1.0856m so that the base of the lcd's are 0.87m from the ground.

[TatianaResend]

The car is stopping in the right place on both sides.

[manuelgitgomes]

Thanks @TatianaResend! This, however, has not been tested in real life. What do you think, should we reopen it?