I have been researching more about switching to a python implementation for the central node code instead of a C implementation. The considerations were because of Krish mentioning the use of POST requests with a csrf token for the website and communication with AWS, as well as image stitching and other image preprocessing. I have been researching more about the libraries in python for sockets, requests, and threading to see if they can offer the same performance advantages that a C implementation would have, as well as get familiar with the libraries since I am used to C code for this type of programming. I am also in the middle of setting up the Jetson Nano properly with its OS and Wifi adapter.
Krish’s Status Update for 17/10
According to the schedule, there is not much to be done for the machine learning aspect of the project until we are able to collect data. In the meanwhile, I worked on the website interface of the project. I set up the Django server which communicates both with the central node and the users. As of now, there is no information to transfer, so I used dummy information.
I spent a majority of my time this week researching the CSRF token. CSRF stands for cross site request forgery. It occurs when a malicious website sends an HTTP Post request from an unknowing user’s computer to another website. Since it is a post request, this can change the state in the other website’s server. This could have consequences ranging from posting information on social media on the user’s behalf without the user’s knowledge to something potentially more dangerous. As a result, it is common practice to send the user a cross site request forgery token. Only the user’s browser has access to this token and it is required to make post requests. As a result, any malicious website cannot post on behalf of the user.
In our project, the only entity to make a post request to the server is the central node, which will not interact with other websites. Thus, it may not require a CSRF token. Additionally, if we require a CSRF token, we would need a two-way communication channel between the central node and the server, since the server will have to send the token. Without the token, we could simplify our design so that the only communications are from the central node to the server. At the time of writing this, I am still in the process of researching. In the next few days, we should have made a decision about the CSRF token.
Next week, I will continue to work on the website. Additionally, if we are able to generate data, I can also start working on the machine learning model.
Team Status Update for 10/10
One of the main risks encountered is that due to the pandemic, a lot of ordering services have been slowed down, so parts that are required to begin the work process arrived late(week of 10/3). However, as of this post, all the necessary parts needed to start the first stages of development have been received, so we can begin to properly set up camera nodes to gather preliminary image data for the YOLO algorithm, as well as start TCP server-code on the central node. One change to the design is to use Google Colab instead of AWS for the development process. We are in the middle of updating our Gantt schedule to reflect a new timeline, since Krish is in a different time zone than Pablo and Arjun.
Arjun’s Status Update for 10/10
My first task is to set up preliminary/simple server-side code on an Nvidia Jetson Nano to receive TCP packets. That would involve me writing preliminary server-side code and uploading it to the Nano. I have written preliminary code that sets up a listening socket and echos text back to a client that connects with it. The parts (WiFi adapter and Nano) have arrived this week, and I am in the middle of testing the software on the Nano and getting used to using the Nano. My next goals is to get this code running properly on the Jetson Nano, and look for a replacement Wifi Adapter if any issues arise. I gave a lot of extra time for certain tasks in case anything like this(parts arriving later than expected) occurred, so we are still relatively on schedule.
Krish’s Status Update for 10/10
In the proposal presentation we had mentioned that all the code would be written on AWS. However, I realised that Google Colab is better for development. The reason for this is that Colab gives us free access to a GPU. This allows us to spend a potentially unbounded amount of time developing the model without constraining on our budget. When we are ready to deploy the code, we can then export it to AWS, because that is more robust.
This week, I set up the pipeline to train the ML model for the project. Usually this is done when the dataset is available, so that the data can be preprocessed and tested. Since in this case the data is not yet available, I built the pipeline to the best of my ability without it.
I also spent a good amount of time researching tools for when the data is available. One of the tools required is an annotation tool. This will allow me to draw bounding boxes over the data images and set labels using a GUI. Since I there are 10k images we hope to get, an annotation tool can significantly speed up the labelling process which could be a bottleneck going forward. In my research, I found LabelImg (https://github.com/tzutalin/labelImg) which seems to be the best annotation software because it is compatible with the PASCAL VOC format that is required by YOLO.
With reference to the machine learning, we are on schedule. I can start working on the next big steps once I have access to the data.
References:
Pipeline:
https://medium.com/oracledevs/final-layers-and-loss-functions-of-single-stage-detectors-part-1-4abbfa9aa71c
https://www.curiousily.com/posts/object-detection-on-custom-dataset-with-yolo-v5-using-pytorch-and-python/
Annotations:
https://github.com/tzutalin/labelImg
https://github.com/ujsyehao/COCO-annotations-darknet-format
https://github.com/wkentaro/labelme