Puck Pal
Aggies Invent, sponsored by Sandia National Laboratories · Nov 2026
A sensor puck that keeps watching a damaged ceiling after the response robot leaves. $5,000 team prize.
Co-founder and product lead · Jun 2024 – Jan 2026 · Al Khobar, Saudi Arabia
Atlob
Order, split the bill and pay from your phone. A platform for restaurants, cafés and hotels.
3connected apps
15+developers, designers and analysts
MVPcompleted with our dev partner
$500Kinvestor commitment*
* Roughly $100–150K of it was spent building the MVP before the rest of the funding fell through.
Customer app designs in Figma, made by our design team from the requirements I wrote, with my review throughout.
Three apps, one system
Customer appMobile web: menu, ordering, bill split, payment.
Business dashboardDesktop web app for restaurants to run their side.
Admin consoleSuper-admin app for managing the whole platform.
What I did
Wrote the product requirements
Mapped every user flow
Reviewed Figma designs and builds
Ran weekly sprints
Five-year model with the investor's CFO
Market research: 132,000+ businesses, 10+ competitors
I didn't write the code. Our development partner, Hyperlink Infosystem, built it. My job was deciding exactly what they should build and keeping all three apps moving together.
How it ended
MVP finishedAll three apps reached a working MVP.
Restaurants interestedBusiness owners were ready to adopt it.
Funding stoppedThe rest of the investment didn't come through. I stepped back in January 2026 to focus on my degree.
Aggies Invent · Sponsored by Sandia National Laboratories
Puck Pal
Deployable structural change monitoring
- First Place
- $5,000 team prize
- Best Prototype Award
- Built in 48 hours
A compact sensor puck a response robot leaves behind, so responders can keep watching a damaged ceiling after the robot moves on.
Team project at Texas A&M, November 2026. Sandia sponsored the competition. This isn't a Sandia product.
The problem
A robot's sensors leave the room when the robot does. A damaged ceiling can keep moving after the first inspection.
My role
Electronics, embedded firmware, sensor bring-up, telemetry integration, and running the live demo.
Prototype stack
ESP32-C5 · ESP-IDF · Embedded C · MPU-6500 over I²C · HC-SR04 · UART · Python · browser dashboard
Result
First Place and the Best Prototype Award, after demonstrating the working hardware-to-dashboard flow.
Live demo
The real hardware prototype. The puck sits under a tabletop "ceiling." Pressing the lid down shrinks the overhead distance and trips a possible ceiling lowering alert. Shaking the setup shows up as movement.
What I built
ESP32-C5 firmwareEmbedded C on ESP-IDF, written and flashed by me
I²C accelerometerBrought up the MPU-6500 and verified it at the register level
Ultrasonic rangingHC-SR04 distance from GPIO trigger/echo timing
Telemetry contractTimestamped serial lines the team's dashboard could parse
End-to-end demoPhysical movement in, responder alert out, live for the judges
The dashboard and Python bridge started as a teammate's package. I connected the board to them and iterated on their behavior with the team. The concept, enclosure and pitch were team work.
How it's wired
What we actually built: a wired USB-serial pipeline. Click a block for details.
The data contract
DATA,66249,0.1449,-0.0085,1.0624,,,,317.1
- DATA line tag
- 66249 device time, ms
- ax, ay, az acceleration in g (gravity included, so z ≈ 1)
- gx, gy, gz left empty on purpose: gyro wasn't needed
- 317.1 distance, mm
One reading per line, fixed field order, explicit units. Readable in a serial monitor and simple for Python to parse.
Debugging under the clock
Board not where we expected
The flash failed on COM9. The board had enumerated on COM11, a WCH USB-serial bridge. Retargeting the port fixed it.
Two programs, one serial port
The VS Code serial monitor and the Python bridge can't both own the port. The monitor had to be closed before launching the bridge.
Reference that wouldn't lock
"Set reference" kept rejecting readings as unsteady. We relaxed the criteria to tolerate normal sensor jitter while still rejecting real movement.
Laggy interface
Early on, the dashboard felt slow to react. We iterated until it responded promptly during the live demo.
The dashboard
Screenshots are from the dashboard's simulation edition, rebuilt after the competition once the circuit was no longer available. It's the same interface running on generated data. The award-winning demo above used the real sensors.
Next iteration: the proposed field puckConcept only, not built
Proposed hardware
- 4× DFRobot SEN0366 lasers two facing up, two facing sideways
- ADXL355 low-noise 3-axis accelerometer
- ESP32-C5 with integrated wireless
- Li-ion battery rechargeable
- Polycarbonate top over a weighted stainless-steel base
Robot deployment
- 1Robot carries several pucks
- 2Drops one at a chosen spot
- 3Puck settles
- 4Confirms stable placement and valid readings
- 5Keeps monitoring as the robot moves on
Getting it field-ready
- Replace the USB link with a tested local wireless network, then measure packet delivery, latency and recovery through real obstructions.
- Validate laser ranging against dust, smoke, angle and target reflectivity.
- Assess the battery, enclosure, ingress and impact performance. Rugged isn't the same as safety-certified.
What I took away
- Prove the hardware first. Verifying the sensor with WHO_AM_I gave every later step a known-good starting point.
- Interfaces are where things break. Many of the bugs lived between layers: ports, file paths and units.
- Build for the person reading it. The responder view shows less so it says more.
- Be clear about what was demonstrated. We won with a working prototype and a clearly labeled concept.
Founder · Fall 2025 · Texas A&M
AggieAsk
Ask questions in lecture without raising your hand. Professors see what the whole room is confused about, in real time.
Supported by Texas A&M's Assistant Dean of AIwho invited me to pitch it at his club, Aggie Innovators
The problem
In big lectures, students hold back questions because they don't want to interrupt or look lost. Professors can't tell which part of the lecture lost the room.
The idea
A live, anonymous question board for each lecture. The class upvotes what matters most, and the professor answers the top questions while they're still relevant.
Post anonymously
Upvote questions
Question categories
Mark answered
Pin and prioritize
Course dashboard
How it came together
- The problemNoticed in my own lectures: people sit on their questions
- PrototypeEarly screens prototyped with v0.dev
- FeedbackStudents, faculty and incubator meetings with professors
- The pitchInvited by the Assistant Dean of AI to pitch at Aggie Innovators, about 60 attendees
- MVPStudent app and professor dashboard built
My partThe idea, every feature and screen flow, the early prototype, and all the outreach and pitching.
Built byA software engineer who built the MVP from my product spec.
Thinking aheadLooked into what classroom use would need: student privacy (FERPA), accessibility and possible research approval, with the Center for Teaching Excellence.
Awards and leadership
CryoCube
Invent for the Planet 2026 · Team of 6 · 48 hours
Solar-powered cold storage to cut food spoilage, with a camera that flags produce going bad.
My part: the idea of using computer vision to spot spoiled tomatoes, which became the core of our demo. Teammates built the model.
Aggie Internship Club
Events officer · 1,000+ members
Career events that connect students with recruiters and engineers.
- Built the presentation for a career panel with speakers from Meta, which drew 100+ students
My part: event planning and materials.