Weely diary
Week 1 – Topic Finalization and Team Formation
We began our journey by brainstorming potential ideas that blend IoT and automation. After
evaluating feasibility, relevance, and innovation, we decided on building a vehicle speed
detection and number plate recognition system. This idea intrigued us because of its real-
world applicability, especially in traffic control and road safety. We discussed responsibilities
and established roles among team members. We also met with our project guide and received
approval to proceed. With enthusiasm, we outlined a high-level view of what we hoped to
achieve in the coming weeks.
Week 2 – Literature Survey and Concept Clarification
This week was dedicated to understanding existing systems and related technologies. We
read academic papers and articles on Automatic Number Plate Recognition (ANPR), IoT in
traffic systems, and speed monitoring methods. We noted the common problems faced in
earlier projects, like sensor inaccuracy and poor OCR performance in low light. These
references helped us define the project’s uniqueness and areas we wanted to improve. It was
clear that integrating IoT with image processing was both a challenge and an opportunity. We
documented our findings and refined our scope of work accordingly.
Week 3 – Objective Definition and Planning
Having acquired theoretical knowledge, we outlined our specific objectives: detect vehicle
speed using sensors, capture number plate images, apply OCR, and store the data in a
database. A detailed weekly schedule was created to distribute workload and set milestones.
We divided the project into submodules: hardware setup, image processing, backend
development, and testing. We also listed the required tools, platforms, and components.
Planning this way gave us a realistic view of the road ahead and prepared us to work
methodically.
Week 4 – Hardware Requirement Finalization
This week we researched the exact hardware we would need. After evaluating costs and
compatibility, we chose Arduino Uno, IR sensors, LCD display, and a USB webcam. We
verified their technical specifications and began arranging for procurement. We also
identified supportive tools like jumper wires, breadboards, and power supplies. Having our
hardware list ready gave us a sense of readiness to transition from theory to practice. We
looked forward to testing our initial setups in the coming weeks.
Week 5 – Arduino Setup and Sensor Testing
Weely diary
We installed the Arduino IDE and began testing basic sketches (programs). IR sensors were
connected, and their ability to detect motion was verified through serial monitor outputs. We
experimented with sensor alignment and tested object detection at different distances. This
hands-on activity helped us understand how sensors function in real environments. We also
built a simple LED indicator system to represent detection visually. These early successes
were motivating and showed that our core detection system could work as expected.
Week 6 – Speed Calculation Formula and Logic
Now that sensors were working, we calculated vehicle speed using the basic physics formula:
Speed = Distance / Time. We fixed a known distance between the two IR sensors and wrote
an Arduino sketch to record timestamps when sensors were triggered. This data was then
used to calculate and display the vehicle's speed on the serial monitor. Initial readings were
promising, although environmental factors occasionally impacted accuracy. We made small
adjustments in code and setup to improve reliability. This marked a major functional
milestone in our system.
Week 7 – LCD Integration for On-Site Display
To make our system more interactive, we integrated a 16x2 LCD screen to display vehicle
speed in real time. We used an I2C module to reduce wiring complexity and improve
readability. Once connected, we wrote code to push the calculated speed directly to the
display. It was a simple yet effective way to visualize data without needing a computer. We
tested the output under various lighting conditions to ensure readability. This enhancement
improved system usability for practical field use.
Week 8 – Camera Setup and Image Capture
The focus now shifted to capturing number plate images. We connected a USB camera to our
computer and used Python’s OpenCV library to capture still images. Each time a vehicle
passed, the camera captured an image and stored it locally. We tested this functionality in
different conditions—daylight, low light, and at different distances. Getting sharp images was
a challenge, so we experimented with camera angle and resolution. This module served as the
input for our OCR system.
Week 9 – Image Preprocessing with OpenCV
To prepare images for character recognition, we applied preprocessing techniques using
OpenCV. This included converting images to grayscale, applying Gaussian blur, and
detecting edges using the Canny algorithm. The goal was to isolate the number plate region
for more accurate OCR results. We performed these steps on multiple sample images and
Weely diary
saved intermediate results for analysis. By the end of the week, our image preprocessing
pipeline was optimized. We now had clear, high-contrast images ready for OCR.
Week 10 – Optical Character Recognition (OCR) Implementation
We integrated Tesseract OCR to extract alphanumeric characters from the preprocessed
number plate images. Initially, the results were inconsistent, so we fine-tuned image
resolution and preprocessing thresholds. We also trained the OCR model on different font
styles to improve accuracy. After some debugging, we successfully extracted license plate
numbers from test images. It was exciting to see raw images turn into usable text. This text
was now ready to be stored and displayed.
Week 11 – Automation of Image and OCR Process
Next, we automated the entire image processing and OCR pipeline. When a vehicle triggered
the second IR sensor, the camera captured an image, which was processed and passed to the
OCR engine without manual intervention. All results were logged in a text file for
verification. This brought us a step closer to real-time functionality. We also worked on error
handling, so the system could manage failed detections gracefully. The process was made
faster by minimizing image resolution and reducing delay.
Week 12 – Designing the Database Structure
We shifted focus to backend development and designed a MySQL database to store vehicle
number, speed, date, and time. Using XAMPP, we configured the Apache and MySQL
servers locally. We created a simple table with appropriate data types for each field. Test
entries were inserted manually to verify connection and structure. We were now ready to
transmit data from our Python and Arduino setup to the database. The integration of hardware
and software became more tangible this week.
Week 13 – Backend Integration with Flask
We built a backend service using Flask to act as a bridge between the IoT device and the
database. It accepted HTTP POST requests containing vehicle data, parsed it, and inserted it
into the database. After several test runs and debugging, we achieved smooth communication
between the Python script and the web server. This helped us move toward real-time data
storage and web display. We also added logs to track request-response status for debugging
purposes.
Weely diary
Week 14 – Full Module Integration
This week, we brought all components together—speed detection, image capture, OCR, and
data storage. As vehicles passed the setup, the system captured images, extracted plate
numbers, calculated speed, and saved all information in the database. This was a major
milestone showing that our end-to-end system worked. Of course, minor bugs appeared when
modules interfered, especially with timing and data overlap. We resolved them by adding
small delays and optimizing image capture speed.
Week 15 – Building the Web Dashboard
We created a simple web dashboard using HTML, CSS, and PHP to display real-time vehicle
data. The dashboard listed the latest entries from the database along with timestamps, speed,
and license plate numbers. We styled it for better readability and tested it on local network
devices. This gave users a practical interface to view the system output remotely. It made our
system feel complete and deployment-ready.
Week 16 – Final Testing and Debugging
We tested the entire system thoroughly using mock vehicles (toys, hands, and cycles). We ran
multiple trials to measure accuracy in speed and OCR. Results were logged and analyzed for
false positives and inconsistencies. We improved OCR by modifying preprocessing
parameters and added retry logic for camera errors. This round of testing proved that our
system was stable and accurate enough for real-world use.
Week 17 – Documentation Kickoff
We began drafting the project report as per university guidelines. This included writing the
introduction, objectives, scope, and methodology. Screenshots of code, circuit diagrams, and
sample outputs were included. We also documented the flow diagrams and architecture in
detail. Organizing all this helped us reflect on how far we had come.
Week 18 – Report Refinement
We continued improving the report with feedback from our guide. Chapters like Related
Work, Implementation Details, and Testing were refined. We added references to tools,
libraries, and academic sources. The writing was polished to reflect both technical depth and
practical insights. Final formatting was also done to meet university requirements.
Weely diary
Week 19 – Final Hardware Review
We double-checked the hardware wiring, connections, and sensor placements. The LCD was
mounted properly, and the Arduino code was optimized for better timing. We improved
physical stability for smoother demonstration. After several dry runs, we were confident in
our setup. We packed the circuit carefully for the upcoming evaluation.
Week 20 – Internal Demo Preparation
We rehearsed our internal project presentation with our guide. Each team member practiced
explaining their module and answering questions. The live demo was refined to avoid delays.
We also backed up all files and created a USB version of the system for portability. The
internal feedback was positive, and a few small improvements were suggested.
Week 21 – Final Presentation Slides
We prepared PowerPoint slides summarizing our journey, system architecture,
implementation, results, and future scope. Screenshots and graphs were used to keep the
content engaging. The goal was to explain technical concepts in simple terms for all types of
evaluators. We rehearsed the entire presentation multiple times. This preparation helped us
build confidence.
Week 22 – External Evaluation
The final presentation was given in front of external examiners. Our demo worked perfectly,
and we received appreciation for combining hardware, software, and networking effectively.
The panel asked insightful questions, and we answered confidently based on our work. It was
satisfying to showcase a system that was both functional and impactful. Their encouraging
feedback boosted our morale.
Week 23 – Final Testing Report
We compiled all test data, accuracy reports, and user logs into a testing document. This
included tables showing OCR success rate, speed accuracy, and system latency. Graphs and
charts were created using Excel for better visualization. We also reflected on limitations like
lighting sensitivity and internet dependency. The document provided transparency and
backed our claims with evidence.
Week 24 – System Optimization
Weely diary
We made minor improvements based on evaluation feedback. Code comments were cleaned,
delays optimized, and database queries fine-tuned. We also compressed image sizes to
improve OCR speed. These final touches improved performance and reduced system lag. It
made the system ready for long-term use and deployment.
Week 25 – Project Archival and Backup
We created a centralized folder with all project files, including code, report, images, and
presentations. Everything was backed up to the cloud and external drives. We also created a
user manual for anyone wishing to replicate the system. This ensured our efforts were
preserved for future learning or expansion. Archiving gave closure to the technical side.
Week 26 – Reflection and Lessons Learned
This week we reflected on the entire journey. From struggling with sensor wiring to decoding
license plates with OCR, it had been a rewarding experience. We learned to work under
deadlines, solve unexpected bugs, and collaborate effectively. More than technical skills, we
developed project management, communication, and documentation abilities. It was clear
that this hands-on project had taught us more than any textbook could.
Week 27 – Final Submission
We submitted our final report, code repository, and hardware photos as per academic
protocol. All necessary forms were filled and submitted on time. Our guide appreciated our
documentation quality and consistent progress. With everything turned in, we took a moment
to appreciate the completion of a semester-long journey. It was a moment of pride.
Week 28 – Post-Submission Relaxation
After submission, we allowed ourselves to relax and celebrate our hard work. We shared our
project experience with juniors and helped them brainstorm their ideas. The feedback and
recognition we received made the effort worth it. It also motivated us to continue exploring
IoT and AI in future projects. The break gave us time to recharge.
Week 29 – Final Review and Gratitude
We ended the project by thanking our guide, faculty, and teammates. This journey wouldn’t
have been possible without everyone's support. We realized the value of teamwork,
Weely diary
persistence, and curiosity. We plan to publish a technical article based on our work. As we
move forward in our careers, this project will remain a milestone we're proud of.
