Bike Guardian

Loyal to one card. Loud to every threat.

Comment

Inspiration

With transportation theft being so prevalent on our campus, the theme of Safety and Security aligned perfectly with a concern we already had as students.

The Problem

Picture this — you wake up, head outside, and your bike is gone. No warning, no trace, nothing. At UCSD, this is not hypothetical. Bike theft notifications hit campus iMessage at least once every week, and it hits close to home — my own roommate had his bike stolen this past winter quarter, with a lock on it.

The problem is not that students are careless. It is that the tools they have are passive and outdated. A standard lock cannot alert you, cannot notify you, and by the time you find out your bike is gone — it already is. On a campus this large, a bike is not a luxury. It is how you get to class on time. Losing it means losing your day. This is exactly the kind of problem that the Spring 2026 Quarterly Projects theme of safety and security was made for — and it is the problem we set out to solve.

The Solution

The Smart Bike Lock was built to solve exactly what traditional locks cannot. Access is controlled through an RFID sensor that responds only to one authorized card — no keys, nothing to pick. The moment someone tampers with it, the alarm triggers and an alert goes straight to your phone in real time. Whether you are in lecture or across campus, you always know. You always have a chance to respond. This is not just a lock. It is a security system built for students.

What it does

The way it operates is quite simple. Let me start with the locking mechanism. Every RFID card — and any card with a microchip, including our UCSD student ID cards — carries a Unique Identifier, or UID. This is a string of numbers burned into the card that never changes. To assign the lock to our student IDs, we first had to find out what those numbers were. We built a simple card reader using the RFID module that scanned the card and printed the UID directly into a serial monitor, giving us the exact values we needed.

Once we had those numbers, we programmed them into the lock. Now when a card is scanned, the RFID module reads its UID and compares it against the stored value. If it matches, the servo rotates and the lock opens. If it does not, nothing happens. No key, no combination — the only thing that opens this lock is the one card it was assigned to.

For the security side, we used an MPU-6050 accelerometer which continuously monitors the lock for motion. At startup it establishes a baseline of its resting position, and the moment it detects any deviation — whether from tinkering, shaking, or tampering — it registers the disturbance. If that motion is sustained, the alarm triggers.

At that point the ESP32 takes over. Rather than relying on an app or internet connection, the ESP32 hosts a complete HTML page directly from the board itself. When you connect to its WiFi network and open a browser, that page loads instantly and begins polling the device every second — updating your screen with the current motion status, alarm state, and a live event log in real time. You can even reset the alarm remotely straight from the page. No internet, no downloads, just a live security dashboard served entirely from a microcontroller the size of your palm.

How we built it

For the software side, we designed the enclosure using Onshape for CAD and wrote all of our code in C++ through the Arduino IDE.

On the hardware side, the build consists of a PN532 NFC RFID module for card scanning, an Arduino Uno R3 to handle the locking mechanism, an ESP32 to run the WiFi dashboard, an MPU-6050 accelerometer for motion detection, a buzzer module for the alarm, a 9g micro servo motor to physically operate the lock, and 9 volt batteries to power the system independently without needing to be plugged in.

Challenges we ran into

The most challenging parts of this project hit us on both ends.

For the RFID reader, we ran into constant scanning issues early on — most likely due to cheap Amazon modules that would work for an hour and then stop responding entirely. One sensor became unusable after we desoldered its pins trying to fit it into the enclosure, and while the desoldering itself was not the problem, the module simply did not survive. Luckily, a generous friend from the ECE tutoring center gifted us a PN532 NFC RFID module which was a huge upgrade — reliable, and capable of reading cards even through a layer of plastic. Soldering it in was nerve wracking knowing it was our last sensor, but we got it done. Along the way a few wires snapped during prototyping, which we fixed by soldering them onto adjacent pins on the same breadboard branch.

The motion sensor gave us the hardest time. The MPU-6050 kept interpreting changes in orientation as active motion — so if the lock was mounted at a different angle than where it was calibrated, the alarm would just keep going even while perfectly still. On top of that, the alarm would continue firing even after resetting it through the browser. Getting the calibration logic right and making the reset actually work cleanly took the most debugging time out of anything in this project. The WiFi also occasionally would not show up on our phones at all even when the board was fully powered on. And designing a locking mechanism around a single servo was its own challenge — we had to make sure the lock could not just be forced open by manually rotating the rod.

Accomplishments we are most proud of

Despite the setbacks, what we are most proud of is that it actually achieves every goal we set out for. From RFID modules dying on us to the WiFi refusing to show up, every obstacle we hit pushed us to think critically and find solutions we had never considered before. None of it came easy, but we worked through every single one — and the final product stands as proof of that.

What we learned

One of the biggest things we learned is how sensitive accelerometers really are. The MPU-6050 treats rotation as movement — meaning even tilting the lock without moving it from its spot is enough to trigger a reading. Understanding that changed how we approached the calibration entirely.

On the RFID side, we learned the hard way that cheap modules are not built to last. Ours would work for an hour and die. A quality module like the PN532 is in a completely different league. If there is one thing we would tell anyone starting a similar project — invest in the right hardware from the start.

What's next for Bike Guardian

There is a lot we would like to expand on given more time and resources.

Working under a $25 budget meant we had to make compromises that affected the final product. One thing we would really like to improve is the WiFi system — right now the ESP32 broadcasts its own local network, which means you need to be physically close to the lock for it to work, and it tends to get drowned out by stronger networks nearby. In the future we would want to connect it to the internet so that alerts could be pushed directly to your phone from anywhere on campus.

We would also like to make the locking mechanism much sturdier. The current design works but is fragile — someone determined could force it open. This came down to running out of filament and printer availability at UCSD, so we had to keep it simple. Going forward we would want to redesign it with a proper interlocking mechanism that can hold up against physical force.

We would also like to shrink the enclosure down significantly. The current box gets the job done but it is bigger than it needs to be, and a smaller form factor would make it much more practical on an actual bike. Lastly we would like to fine tune the motion sensitivity so the alarm better tells the difference between real tampering and small innocent movements like wind or someone walking past.

Despite the setbacks and limitations we faced along the way, we feel this project demonstrates its purpose well. Bike theft is a real problem that affects real students here at UCSD, and what we built is a genuine step toward solving it. The idea is there, the innovation is there, and the system works. With better components, a larger budget, and more time, we believe this could be developed into something truly beneficial for every student on this campus — a smart, affordable security solution built by students, for students.

Built With

Share this project:

Updates