Author: ankitac

Team Status Report 4/27/24

Team Status Report 4/27/24

Potential Risks and Mitigation Strategies At this point, really the only issues we could potentially encounter are if the fixed version of the PCBs don’t actually work as intended and if the overall latency for the integrated system is higher than we had planned for 

Ankita’s Status Report 4/27/24

Ankita’s Status Report 4/27/24

Work Done This week, I spent most of the time conducting initial tests (for latency and accuracy of the object detection model, which I did by evaluating the performance of the model on 3 different videos of the intersection and ~100 frames) and working on 

Team Status Report for 4/20/24

Team Status Report for 4/20/24

Potential Risks and Mitigation Strategies

The concurrent videos we took at the intersection this week involve a lot of hand-shake, so hardcoded lane boundaries are not an option. Currently, code that detects the lane boundaries using Canny edge detection is not working, so we ordered tripods for a steady camera angle and will be retaking those videos next week.

There is no way to systematically generate pedestrians in the simulation, however we don’t think this is a big issue since for the demo we will be manually spawning pedestrians according to what the camera would see.

Our simulation also has cars that spawn with very predictable routes, so the algorithm may be calculated as more efficient than it would be in real life. We plan on adding more randomness to the simulation before the final demo.

Our traffic light PCB needs to be re-ordered due to an issue with some of the pins. The risk mitigation in this case would be to use a breadboarded circuit.

Changes to System Design

The Q-learning model takes in the length of the light interval instead of the current state it should be at. The reasoning for this was explained more thoroughly in Kaitlyn’s status report, but it was mostly due to ease of implementation as well as greater safety guarantees.

Overall Takeaways and Progress

  • Optimization algorithm working with very good improvement in comparison to fixed-time interval implementation
  • Integration between RPi and Arduino should be good to go once PCB is ready
  • PCB needs to be reordered
  • Object detection code needs to be improved / new videos need to be taken
  • Simulation has been fixed and runs indefinitely, allowing us to train the ML model
  • ML model has been trained and works with almost 50% reduction in wait time!

 

Ankita’s Status Report for 4/20/24

Ankita’s Status Report for 4/20/24

Work Done I ordered the new IP camera/portable batteries and they came in this week, so after getting the demo ready for pre-recorded videos at the intersection I will test the object detection model on the live video feed (after looking at tutorials/examples online that 

Team Status Report for 4/6/24

Team Status Report for 4/6/24

Potential Risks and Mitigation Strategies Some risks we currently have are that the additional code we need to add to the object detection model to only identify cars that are waiting at one side of the intersection may add additional delays to our system — 

Ankita’s Status Report for 4/6/24

Ankita’s Status Report for 4/6/24

Work Done

I did manage to get a faster object detection model (found in this Git repo) – it’s a YOLOv3 model (so a bit less accurate than the YOLOv4, but it works for our purposes and is less computationally intensive.) This model is also able to detect pedestrians, so the algorithms for these components of our project have been finalized. This model appears to take less than a second to process each frame, but I’ll need to test it on the RPi to make sure that the timing remains consistent. Kaitlyn and I set up the SUMO simulation on the RPi this week and it works pretty seamlessly (i.e. no noticeable latency issues or lagging when simulation parameters are changed.)

Unfortunately, contrary to what the vendor informed me, I found out after asking some questions about how to set it up that the camera we bought does not support RTSP and that in fact there likely aren’t any battery-powered IP cameras on the market that do support RTSP (perhaps due to the fact that, in order to save power, they typically only record the live feed when motion is detected or when the user prompts them to through the apps that control them). I will order a wired IP camera next week along with a portable battery (based on video tutorials I’ve found online, I know of several options that definitely do support RTSP), but at this point I’m not sure it makes sense to demo the finalized object detection model on anything other than prerecorded footage, so the purpose of doing this would just be to show that we can use a live IP camera feed for the object detection model.

Schedule

There is still some stuff I need to do to fix the object detection code; currently, every single vehicle that is detected is included in our count of vehicles on that side of the intersection. I found some interesting lane detection algorithm resources in this article (using Canny edge detection and Hough transforms) but because those are very lighting-dependent I’m not sure that they will be the most accurate. If they don’t give me the results I want, I’ll just hardcode lane boundaries according to the video dimensions. There is also the issue of cars crossing the intersection and blocking the camera’s view of the cars that are waiting (which is the number we actually want); in this case, if the bounding box around the car goes beyond a certain dimension, I will maintain the previous vehicle count until the large bounding box is no longer present. Similarly, I will only count pedestrians that are within specific coordinates that correspond to each side of the intersection’s sidewalk.

Next week, we will need to take concurrent video of all 4 sides of the intersection in order to retrieve the object counts that would be used by the optimization algorithm (we will actually be using simulated object counts for this optimization, because the results of the optimization algorithm – light state changes – will not be reflected in real life conditions. As a result, the assumptions that our algorithm makes, i.e. that cars will go when there is a green light, will not hold, and our algorithm would not optimize at all. However, we want to demo the object detection in a way that shows that, if we were able to reflect the light state changes in real life, the two systems could be integrated without issues.) The finalized object detection code would be demonstrated on these 4 videos simultaneously, with accuracy tests being conducted on vehicle and pedestrian counts for all 4 sides of the intersection.

Testing Plan

The parts of my subsystem that I need to test are latency (how long does the object detection model take per frame – needs to be < 5 seconds – (optimization algorithm time)) and accuracy (how accurate are the detected vehicle and pedestrian counts – should be 90% and 80%, respectively.)

I will test latency by adding a timer that starts at the beginning of frame processing and ends at the end of it. I will test accuracy by compiling ~100 frames (after the intersection videos are taken) and comparing the number of detected vehicles and cars to the actual number of vehicles and cars (determined by eye).

Deliverables

By Monday, 4/15, I will:

  • Get the object detection running on the RPi
  • Retrieve accurate object counts for the demo video I’ve been working with (using lane detection algorithms or hardcoded values)
  • Order the wired IP camera and portable battery and, if they arrive, try to access the live video feed
  • Take the concurrent videos of all 4 sides of the intersection (preferably with some assistance)
  • Help Kaitlyn and Zina integrate the RPi and the Arduino so that the traffic light PCB reflects the state changes determined by the optimization algorithm

 

Updated Schedule for Interim Demo 4/3/24

Updated Schedule for Interim Demo 4/3/24

Here is our updated Schedule as of 4/2/2024. We have cut into our slack time, with our current testing plans now falling on the week after Carnival (starting April 15) (around the time when we’ll be working on our final presentation.) Each subsystem is close to being 

Ankita’s Status Report for 3/30/24

Ankita’s Status Report for 3/30/24

Work Done Due to the amount of time needed to tag positive and negative images for the Haar classifier (last week it took 4+ hours to tag ~60 images, and to train a better classifier I would probably want 200-300) I thought it would be 

Ankita’s Status Report for 3/23/24

Ankita’s Status Report for 3/23/24

Work Done

I finished tagging the positive and negative images needed to train the vehicle classifier from traffic camera footage as well as the footage Zina retrieved for me from the Fifth and Craig intersection. Unfortunately the commands I would use to train the classifier have since been deprecated, so I ended up using Anaconda to set up a virtual environment and installed an older version of OpenCV through that so I could run the commands. I was ultimately able to train a classifier, but it has pretty terrible accuracy so I think I need to revisit how I’m collecting the data. Most of the tutorials I found online have been using way more samples than what I’ve amassed (on the order of hundreds rather than just 60, which is what we currently have), so I think we need to go back to the drawing board in terms of data collection. Either that, or we should go with a more accurate model (YOLOv4). Also, tagging the images takes a lot of time (for the positive images, bounding box coordinates of each object in the frame need to be specified) so I may need longer to do this than initially anticipated.

I tried to access the IP camera video feed from the Raspberry Pi using RTSP, but after some difficulties I found out that Reolink’s battery-powered cameras don’t actually support RTSP streaming (source.) This means that we won’t be able to access the stream outside of Reolink’s app, so I looked into alternative wireless cameras that do support RTSP streaming and found these options: Amcrest and MubView. If these don’t work, we will probably resort to using prerecorded footage.

Schedule

I need more time to get the car detection model trained. For the pedestrian detection model, I will use a pretrained classifier (even if the accuracy is not necessarily up to our metrics) because all we need to know is if there are pedestrians at the intersection.

We also need to wait for the new camera to come in so that adds some delays to our integration as well.

Deliverables

By the end of next week, I will:

  • Train a (hopefully) better vehicle classifier after amassing more positive/negative samples and tagging them
  • Order the new camera ASAP

 

Ankita’s Status Report for 3/16/24

Ankita’s Status Report for 3/16/24

Work Done I started tagging the positive and negative images needed to train the vehicle classifier from traffic camera footage — I’m still waiting on some footage from the Fifth and Craig intersection from Zina to add more images to the training dataset and then