Solar-Powered Traffic Monitoring Solution
Thesis Report
Webpage Version
Thesis Report
Webpage Version
Cars, and motor vehicles in general, are a daily part of life for everyone in Cyprus. Managing the flow of traffic in the country’s road network is a complex task that involves understanding drivers, anticipating how information is spread, designing infrastructure that intuitively guides behavior rather than relying solely on compliance with rules, and ensuring that traffic is distributed efficiently across the network to avoid bottlenecks and congestion, all while considering how drivers naturally seek out the shortest or fastest routes for themselves, without considering the impact that has on the road network as a whole.
Thus, to design, maintain, and upgrade the road network effectively, it is essential that you have knowledge of what happens on it, how many vehicles use it, when, and where. To that effect, the objective of this project was to develop a solar-powered self-sufficient device that can count the number of vehicles (cars, trucks, buses, and motorcycles) that pass through the street in front of it. To make that data accessible in real time, the collected data is uploaded periodically to an online database where it can then be accessed and analyzed. Validation using real-world video footage from the proposed installation location demonstrated a detection and classification accuracy of 96.6%, while the final system operated at approximately 5.6W.
The project involved both experimentation, implementation, and coding. Coding was the most time-consuming part of the project partly because the first 2 software architectures I considered using produced unsatisfactory results, either because of low accuracy, or because of poor performance. After I had settled on a final version of the code, I had to implement the rest of the features such as the data upload function, and finally I had to test and finetune the software using a sample video I had captured.
The motivation for this project was the need for a system that can be easily scaled and installed in multiple locations with very little modifications allowing for data collection from several points of the University’s campus or a broader road network. Having access to such information can help with identifying periods of high demand, detecting recurring bottlenecks, and supporting decisions related to road layout, parking access, pedestrian safety, and future infrastructure improvements.
My project’s aim is to develop a device that will count the number of vehicles passing through the road in front of it and determining the direction they are traveling towards. The data collected by the device will be periodically uploaded to an online database and the device will be powered exclusively from solar power, using a solar + battery setup.
Below is a detailed list of all the features my project plan includes, and whether or not they have been achieved.
Operation in bad weather was not validated. That said, the method I chose should work in rainy conditions.
The use of a GPRS module was not delivered. During development, this part of the original plan was replaced with Wi-Fi data upload in order to simplify the system. WiFi also has the additional benefits of being less power hungry than a cellular connection and coming built-in to the Raspberry Pi I chose to use.
The first step in my project was to research what vehicle counting solutions are commercially available. Most ready-made solutions were only available with a quote because such solutions are usually sought after by companies/organizations, not individual consumers. That made my search for price ranges more complex, but I did manage to find alternatives or make guesses based on website information. Based on my research the leading vehicle tracking options available commercially are:
• Inductive loop embedded under the pavement
• Radar sensor mounted on the side of the road
• Pressure tubes laid across the road
• Camera-based solution using machine vision
In addition to those, I have also considered the following two options:
• Laser beam pointing to a photodiode
• Laser distance sensor
From the start of the project, I had in mind that I wanted to work with a camera-based solution, but I wanted to examine the alternatives before moving forward. I decided that the areas I would evaluate each option in were:
• Ability to operate in bad weather
• Ability to operate at night
• Ability to determine vehicle direction
• Ability to ignore pedestrians
• Interference with the road traffic
• Implementation difficulty
• Affordability
Below is a table showing the results of my evaluation of each of these methods .
As shown in the table above, a camera-based solution meets all the requirements presented, assuming the installation location has street lighting, which is the case with my proposed location. Additionally, the camera-based approach has the unique advantage of being able to track several vehicles going in different directions at the same time, which is something none of the other five options can do with a single sensor. Furthermore, this approach does not rely on drivers following proper driving rules to work effectively, for example, driving on the correct side of the road.
The choice of location for installing the device was critical. The five main criteria for a good location for a camera-based counting solution were:
• Access to a road with lots of traffic
• An elevated location to mount the camera
• An unobstructed view of the road
• Access to the campus WiFi network
• Street lighting so that the camera can operate at night
With those criteria in mind the location I chose is the main bus stop of the university campus, located at 36S WD 37245 89306.
My choice of going with a camera-based vehicle tracking solution meant that I would be needing significantly more computational power compared to any of the other methods that were discussed in the Literature review. The two prevailing options were either an SBC (single board computer) platform like a Raspberry Pi, or an x86 mini PC. The decision came down primarily to power draw. ARM-based CPUs typically offer lower power consumption than x86 CPUs in embedded edge-computing applications, making the device easier to power and cool.
The choice between a Raspberry Pi platform and an SBC from another brand (many of which provide different feature sets and better value for money) came down to known software compatibility and personal familiarity with the platform. The Raspberry Pi Foundation provides its own software and customized version of Debian Linux that comes with all drivers and firmware pre-configured.
Lastly, I briefly considered using the Raspberry Pi AI Camera module, which includes an integrated NPU capable of running machine vision tasks directly on the camera module. However, I decided not to use it because it would increase the cost of the system and add development complexity. In particular, it would require managing the interaction between the Raspberry Pi and the camera’s onboard processing, rather than running the full software pipeline on a single device.
In conclusion, I chose to use a Raspberry Pi 5 4GB for the project.
Apart from the previously mentioned idea of using the Raspberry Pi AI Camera module, the other two options were either using one of the standard Raspberry Pi Camera modules that connect to the Pi through a ribbon cable, or a standard USB webcam. To keep the project within budget I chose to use a USB webcam I already owned. In practice, this choice did not significantly affect the project, as the camera was perfectly sufficient for the task. One possible improvement would be to use a camera with a wider field-of-view, allowing the passing vehicles to stay inside the frame for longer.
To cool the Raspberry Pi 5, I used the official Raspberry Pi Active Cooler, which is designed specifically for this model. During testing, the CPU temperature remained within acceptable limits and stayed well below the maximum operating temperature of 80°C. However, thermal performance may be different in a real deployment, especially if the device is placed inside an enclosure with limited airflow. In that case, a better cooling solution may be required.
The choice of software is equally important to the choice of hardware. The obvious choice for operating system, which is also the main reason that I decided to go with a Raspberry Pi as my computer, is the 64bit version of the Raspberry Pi OS, that is provided by the Raspberry Pi Foundation. It is a customized version of Debian Linux which is known for being lightweight and stable.
For machine vision I chose to use the YOLOv8 Nano model. Although newer versions of the YOLO family exist, this one was selected because it was already known to perform sufficiently well for the purposes of this project. In hindsight a comparison with newer lightweight models would have been useful, as it may have improved accuracy or reduced power consumption.
For the online database, I chose MySQL because I was already familiar with it from a university course. I had previous experience setting up a MySQL server and uploading data to it from within a Python script, which made it a practical choice for this project.
The software is written in Python, which is widely used for machine vision applications and is well supported on the Raspberry Pi platform. Python also provides access to the necessary libraries for camera handling, machine vision, numerical processing, and database communication.
All software components used in this project are available under open-source licenses. This was an important consideration, both for personal reasons and because it allows the university to continue, modify, and expand the work without depending on proprietary software licenses.
As stated in my project plan, my initial goal for the project was capturing and processing 1 frame every 1000ms. The idea behind that was that from the captured image, the machine vision model would be able to determine the orientation the vehicle is facing and thus count it as moving either to the left or the right. As far as I could find, that capability is not available on the YOLOv8 model I chose to use so I abandoned this methodology very early in the development of the software
The second version of the software used a more complex method to count the vehicles. It was a combination of motion detection, object detection, and centroid-based tracking. First, a background subtractor was used to detect areas of movement in the frame, so that the machine vision model did not need to analyse the whole image. The software then selected the largest moving regions and passed only those regions to the machine vision model to determine if they were in fact vehicles. For every detected vehicle, the software calculated the centre point of its bounding box and compared it with the centre points of vehicles that were already being tracked. If a new detection was close enough to an existing tracked object, it was treated as the same vehicle and its position history was updated. If it appeared near the edge of the frame and did not match any existing object, a new tracking ID was created. The direction of travel was then estimated by comparing the vehicle’s first and latest positions relative to two predefined reference points, POINT_A and POINT_B. Once a vehicle had been tracked for enough frames and its direction was clear, it was added to the appropriate counter and marked as counted to avoid double-counting.
This version’s main issue was that reflections from the doors of passing vehicles sometimes illuminated the asphalt strongly enough to be detected by the background subtraction mechanism. This created many false motion regions, which caused many unnecessary regions of the frame to be passed to the machine vision model for inference. As a result, the software’s performance was reduced to an unacceptable level, even when running on my computer. Apart from that, there were also too many false positives counted, many of which could probably be eliminated with further tuning and refinement, but I decided to adopt a different architecture.
Figure 3 below shows the software running on a sample video recorded with help from my friends. The top-left corner shows the output of the background subtraction mechanism, where the vehicle’s silhouette is sharp and clearly visible.
Figure 4 below shows the software running on the same video a few seconds later. In the topleft corner, the output of the background subtraction mechanism is almost fully illuminated by the passing vehicle, with sunlight reflections also visible on the asphalt. The green line shows the tracked path of the vehicle. Compared with the path shown in Figure 1, this trajectory is less stable and consists of fewer, longer line segments. This indicates that the vehicle was sampled fewer times, which is a symptom of the significantly reduced frame rate discussed above.
The current version of the software works by having the camera capture an image of the street, which is then cropped according to the configuration so that unnecessary or problematic parts of the scene are removed before processing. The resulting frame is passed to the YOLOv8 Nano machine vision model, which detects vehicles and returns the coordinates of their bounding boxes. These detections are then compared with the predicted positions of vehicles that were already being tracked in the previous frame. A Kalman filter is used to predict where each previously detected vehicle should appear in the current frame, and a Greedy IoU algorithm is used to match these predictions with the new detections. This allows the software to keep the same identity for each vehicle as it moves through the frame. Once a vehicle has been tracked for enough frames, its movement is compared against the configured line between POINT_A and POINT_B, allowing the program to determine which direction it is travelling in. After the vehicle has been counted, it is flagged as such to avoid double counting. At regular intervals, the program can upload the number of vehicles counted in each direction, together with a UTC timestamp, to the remote MySQL database.
My code is available on my website: https://www.mch170.com/projects/traffic_monitoring
Figure 5 below shows a snapshot of the software running on a video recorded from the proposed installation location. As shown, two vehicles travelling in opposite directions are being tracked at the same time, a capability that, as mentioned previously, none of the other vehicle counting methods possess.
Figure 6 below shows a snapshot of the software running in a nighttime scenario at the same location. Although the reduced lighting conditions make tracking more difficult, the software was still able to track the vehicle correctly and did not produce any errors during this short test.
Configuring the software to run properly in a different location is relatively simple. There are four main parameters that need to be set:
• POINT_A: the in-frame coordinates of one end of the road section being measured.
• POINT_B: the in-frame coordinates of other end of the road section being measured.
• MASK_RECT: the in-frame coordinates of a rectangular area that should be masked before processing.
• CROP_RECT: the number of pixels cropped from each side of the frame, in the order top, bottom, left, right.
Note that points A and B should be at either end of the road section being measured. Contrary to the comments in Figure 7, they do not have to be right and left in that order, the comments were added so that I would stay consistent. The yellow line connecting A and B should ideally align with the dividing line of the road, but precision is not required in this case.
With the function of the program verified, the next step was to optimize it. The initial power consumption of the device was measured at 8W with the program running using the sample video and the USB webcam connected. At this stage, the software performance was 8.9FPS.
The first step was to perform an AI-assisted code review and optimization pass. The resulting changes were then manually checked to verify that all software functions still worked as intended. This provided a minor performance improvement but did not produce a measurable reduction in power consumption.
The second step was to disable all hardware components of the Raspberry Pi that were not necessary for the operation of the device. The changes are as follows:
• Disabled Bluetooth
• Disabled PCIe slot
• Disabled audio
• Disabled HDMI ports
• Downclocked GPU -50%
• Set CPU governor to conservative
These changes in addition to adding a headless mode where the camera/video preview is not rendered on screen reduced the power consumption to 7W and increased performance to 9.5FPS.
The most impactful change was reducing the amount of input data given to the machine vision model. Because of the camera’s location, the camera captures part of the parking lot inside the frame. Apart from causing multiple detections, that causes a problem because vehicles moving inside the parking lot are detected, tracked, and counted as if they were moving on the road.
To solve this, I initially masked that part of the image with a black rectangle before passing the frame to the machine vision model for inference [Figure 11]. That solved the issue but meant that approximately the top 25% of the frame given to the model was useless data that still had to be processed, wasting time and energy. Instead of masking that part of the frame, I added an option to remove it entirely, which reduced the input data given to the machine vision model by 25%, which in turn increased performance from 9.5FPS to 12.2FPS.
Since the software could track vehicles with acceptable accuracy at around 8 FPS, I chose to sacrifice part of the performance gain in order to reduce power consumption further. The CPU was underclocked from 2400MHz to 2000MHz, and the SoC was undervolted using the Raspberry Pi -2 preset, equivalent to -50mV.
The final result was the software now running at around 10FPS with an average power consumption of 5.6W.
To evaluate the performance of the software, a video was recorded from the proposed installation location on 21 November 2025 between 10:15 and 10:35. The original recording was edited to remove long periods during which no vehicles passed through the monitored section of the road. The final test video used for validation had a duration of approximately 17 minutes.
The ground-truth vehicle count was obtained manually by reviewing the video. During the test sequence, 175 vehicles passed through the monitored section of the road, with 119 travelling to the right and 56 travelling to the left.
The software counted a total of 181 vehicles: 120 travelling to the right and 61 travelling to the left. This corresponds to an over-count of 6 vehicles compared with the manual count. The relative total count error was therefore:
This gives a total count agreement of approximately:
100% - 3.4% = 96.6%
Given that the collected data are intended for traffic monitoring rather than safety-critical control, this level of counting accuracy was considered acceptable for the purposes of this project. In addition to the counting results, the final optimized system processed video at approximately 10 FPS on the Raspberry Pi 5 while consuming an average power of 5.6 W.
Vehicles exiting the parking area at the left edge of the frame were excluded from the ground-truth count. Due to the placement of the camera in the test video, these vehicles appeared too close to the edge of the frame and were not visible for long enough to be reliably tracked. They were therefore treated as outside the effective monitoring zone rather than as missed detections.
The error rate differed noticeably between the two directions, which was not expected. One possible explanation has to do with camera perspective. Vehicles travelling to the left are in the lane closer to the camera, so their apparent motion across the image is faster and they remain inside the frame for a shorter period of time. As a result, the software has fewer frames in which to detect, track, and classify these vehicles, making this direction more prone to counting errors.
The objective of the power subsystem was to design the minimum practical solar and battery system capable of powering the device continuously, including during winter conditions. The system was sized for a daily energy requirement of approximately 140 Wh and for four days of autonomous operation.
With the aforementioned average power consumption of 5.6 W, the daily energy consumption is 134.4 Wh, which was rounded up to 140 Wh. Conversion losses from the various components were not modelled individually. Instead, they were accounted for by rounding the energy demand upward and by applying a sizing margin to the final solar panel and battery selection.
Two different methods were used to estimate the required solar and battery capacities. The first method used real energy-generation data from a residential photovoltaic installation, while the second method used the PVGIS off-grid simulation tool for validation.
The first method used energy-generation data collected during 2025 from a south-facing residential solar installation with a panel tilt angle of 25°. For each season, the total generated energy was divided by the number of days in that season and then by the installed solar capacity. This gave the average daily specific yield in kWh/kWp/day.
The required solar capacity was then estimated by dividing the device’s daily energy demand by the daily specific yield for each season. The results are shown in Table 2.
For this project, the device’s energy demand is approximately constant throughout the year. Therefore, it is more useful to optimize the solar panel angle for winter generation rather than for maximum annual generation. For that reason, a steeper tilt angle, such as 45°, is more appropriate than the 25° angle used in the reference residential installation.
To validate the results of the previous section, I used the Photovoltaic Geographical Information System (PVGIS) to model an off-grid setup with the following characteristics:
• 100 W of installed solar capacity
• 600 Wh battery capacity
• Discharge cutoff limit 1%
• 140 Wh consumption per day 21 MCH170
• 45° slope angle
Below are the output graphs from the PVGIS model.
As shown in the Figures 13-15 above, even in January, which according to the model is the worst month for solar generation, the battery was full about 80% of the days. Moreover, the battery very rarely fell below 80% state of charge. These results show that a 100 W solar panel mounted at a 45° slope angle paired with a 12 V 50 Ah lead-acid battery will be sufficient to achieve the proposed self-sufficiency targets.
Figure 16 below is a picture of the proposed setup for powering the device:
This setup is meant to be as simple as possible. Charging stops automatically when the battery reaches 13.5V which is well within the safe limit for a lead-acid battery. The device has priority over charging the battery by default. The main limitation of this simple setup is that it does not include a low voltage disconnect to prevent excessive battery discharge. Although occasional deep discharge would not immediately destroy the battery, repeated over-discharge would accelerate battery degradation.
Considering that my project deals with real time data collection, one of my key priorities was protecting the individual privacy of the people using the street by keeping the data I collected as aggregated and anonymized as possible and deleting anything sensitive as soon as possible and making sure nothing sensitive is ever stored in non-volatile memory, even temporarily.
Once the camera captures a frame, that frame is immediately given to the YOLOv8 machine vision algorithm for inference. After the vehicle coordinates are extracted from the image, the image is then deleted by dereferencing it. All processing of the captured image is done locally on-device and the image itself never leaves the device and is never saved to non-volatile storage.
Assigned vehicle IDs are given out serially, not based on vehicle model, type, or color, and all collected data pertaining to an individual vehicle is deleted shortly after that vehicle leaves the frame. The only information stored about a particular vehicle is its direction which is aggregated and the timeframe of when it crossed the frame.
Several areas remain for future improvement. Some features I would suggest for any future student to implement are:
• A separate table on the online database where system diagnostics would be uploaded like CPU temperature, battery voltage, battery charging current, PV output voltage, etc. This would help with diagnosing potential issues with the device such as overheating.
• Including other sensors on the device like temperature, humidity, air quality, etc. That data could be uploaded to a separate table of the database to be used for other projects that require environmental data from different locations.
• Keeping an offline copy of all the collected data and uploading it as soon as internet connection is restored in case of an internet outage or if connection is lost to the database for any reason.
• Exploring newer versions of YOLO models which way provide better accuracy and require less computational power.
• More detection classes can be added very quickly. There could also be variables for counting bicycles.
• Centering the camera on the parking lot’s exit could allow for counting the cars exiting the parking lot to be kept as separate variables allowing for data collection on when students/faculty leave from the campus in the afternoon.
• Apart from counting the number of vehicles passing through the street, with some extra calibration, a rough speed estimation could be made for each vehicle.
I believe that these additions will increase the value of the device and allow for even more useful data to be collected to give an even better understanding of the traffic situation on the road.
Overall, I am very satisfied with the results of my work, and I am proud to say that I achieved the core objective of the project I was given. This project helped me deepen my knowledge of how machine vision models work and how they can be used for practical applications. Furthermore, writing this thesis report helped me improve my technical writing skills and my ability to break down a large idea into segments and explain them one by one. My project proved that a simple, low-cost, camera-based solution to vehicle tracking is possible and provides results with acceptable accuracy, considering of course that the data collected is not of critical importance. I would have wanted to deploy a full version of my device, including the solar power components, however I did not have enough time to do so. I am also interested to see if any of the suggestions I have made in the future work section can be implemented and how useful the collected data will end up being. My biggest mistakes in this project are that I moved too slowly at the start of the project due to the absence of time pressure, and that I should have experimented more with newer versions of the machine vision model I chose, which could have made my results even more accurate and possibly more power efficient.