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. 

1.3 Planned and Delivered Outcomes

Below is a detailed list of all the features my project plan includes, and whether or not they have been achieved. 

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 .

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.

4.3 Cooling

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. 

5.3 Second iteration

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.

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: 

8.1 Residential solar installation data 

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. 

8.2 PVGIS data 

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.

8.3 Proposed setup 

Figure 16 below is a picture of the proposed setup for powering the device: 

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.