Finishing up the car collision project, we will be testing it on a remote control car. Throughout the history of the project, it has taken many turns for the better as we personally find out that many options that we wished we could use were not viable options. One of these is using stereo vision to understand distance to objects in front of the vehicle. We quickly found out this wasn’t a viable option it was very resource intensive to run on the designated device which meant that the rate at which we get updated data is too slow for our application. Our device is going to ideally sit inside of our car shell (if it fits) and going to be able to simple to operate and display some form of a its status using LED indicators.
After calibrating and validating the results of a rectified stereo pair, I found that the Raspberry Pi’s performance isn’t capable of running the script effectively. Running the rectification script on a very small image along with the StereoBM function was taking around 3 seconds to process each frame. This obviously wasn’t ideal since we couldn’t use a computer to do the calculation as it had to portable, so I decided to switch over to using an Arduino with an ultrasonic sensor.
In order to get a more accurate depth map, I had to get the matrices for our cameras by calibrating both cameras using a chessboard. Since the relative setup of the cameras will always be constant, the calibration matrices can be saved and used for future parts of the project.
To get distances to objects, there are one of two options, either use sizes of known objects such as car widths or license plates or use a disparity mapping. I decided to start working on the disparity approach which gives a new image of far and near objects, without an exact distance.
The relative position of the cameras for the car collision project is absolutely essential in order to make sure we aren’t changing the parameters of our setup. In order to keep this factor constant before setup the depth map in our software, I wanted to make sure I had something to hold our cameras together. I was going to create my own holder but saw there was a plethora of available models out online specifically for the c270 camera. I decided to print them all out and give a run down about each one.
Since performance is critical to the application of our project, I thought it’d be important to log our current sampling frame rate by writing on top of the window.
I decided to start off developing the algorithmic part of the car collision project. After a few weeks of debating whether to use C++ or Python, I decided to use Python since there are around 10 weeks left to get this project up and running. I also decided to use OpenCV as it has many of the functions we need to perform and also its highly optimised. Although through my research into OpenCV shows that there is no built in way to get a Depth Map that returns exact distances for each pixel, I decided we can worry about that later after we get the Depth Map working. In a worst case scenario, we can map depth map values to distances or find an alternative. I just wanted to get our feet wet with the project.
After playing around with tinkerOS I decided to give the Raspberry Pi 3b a try and see if I liked it any better. For some reason I did and have decided to use it as the board for the rest of the project.
So mark the start of the car collision prevention project, I decided to start off by installing tinker OS, which is a Debian-based operating system, on the tinker board.
The final set of parts for the crash prevention project have arrived. These parts deal more with the mechanical side of things and we’ll use them near the last phase of our project where we have to trigger a brake leaver to stop the car.