Welcome to the last part of my series on how to build an API. In this tutorial I’m going to cover testing your endpoints as an application would be using them. This will provide higher level coverage for our api project and database and is a great way to test the business logic of your endpoints and database.
In this part of the series I am going to build on what we learned in part 1 of the series by creating a Web API. After this tutorial, we will have endpoints that allow us to create and read data from our database.
In this tutorial we are going to be using Node.js to set up a web server. In addition, we’re going to use the Express.js framework to help us quickly layout our routes. We will also be configuring our project to use Typescript. I will also help you set up your project for unit tests using jest.
In this series I am going to be covering how to create a backend from start to finish. I’m going to cover the process in several different sections. For our database we will be using PostgreSQL. I’ll go over all of the steps in detail, including what tools I’m using.
The architecture used in this series is built to be scalable, yet hopefully very simple for beginners. I’ll try my best to explain why I used certain technologies as we go along.
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.