Engineering
& software
projects.

CAD, electronics, and code

My role covered most of the build: mechanical CAD, electronics, Arduino C++ code, component selection, and testing. Everyone on the team shared responsibilities, and I helped get the mechanical and electronic parts working together.

Hardware

An Arduino Uno R4 WiFi processes joystick and switch inputs in the controller; an Arduino Mega handles the rover's motors, servos, and sensor interfaces. NRF24L01 radios connect the two. A capacitive soil-moisture sensor feeds an LCD mounted on the rover.

Changes during the build

We originally wanted soil-moisture readings on the controller. After running into radio communication issues and limited time, we mounted the LCD on the rover and added a controller switch to freeze the reading. We also reused parts and adjusted the mechanical fit to stay within budget.

Outcome

We demonstrated the rover outdoors and produced mechanical drawings, circuit documentation, and a final presentation. The project gave me hands-on experience debugging a robot across CAD, wiring, and firmware.

Team: Darien Aragon, Ismael Anderson, Nico Leon, and Patricia Lau. Faculty advisor: Juan Castillejos.

My role

I directed the CAD revisions and material research, using AI-assisted modeling to develop the geometry in Onshape. I requested changes to the chamber, mounting flange, spark assembly, and instrument connections as the project requirements developed.

Model revisions

The first model established the component layout. Later revisions followed the team's uncooled 316L heat-sink design and added purge, pressure, and thermocouple connections. The chamber wall and mounting flange were thickened for further review.

Pressure and thermal calculations

The preliminary calculations covered chamber hoop stress, inlet stress, and thermal sensitivity. A thicker chamber reduced the calculated pressure stress and increased its heat capacity. Wall temperature and mounting restraint still need to be established.

Development status

The model is preliminary. Pressure and thermal work so far consists of hand-calculation screening; FEA, proof testing, and hot-fire testing are still pending. The calculations need updating for the revised feed pressure.

My role

I set the sourcing priorities and used AI-assisted research to compare valve candidates. I focused on parts that could be ordered directly, with documented pressure ratings, gas compatibility, and the required fittings.

Operating requirements

The updated team brief called for roughly 600 psi feed pressure, 12.5 g/s GOX and 5 g/s methane, with minimum component ratings of 3,000 psi upstream and 1,000 psi downstream of the regulators. The register distinguishes operating pressure, pressure rating, relief setting, and solenoid operating differential.

Valve specifications

I compared normally closed operation, zero-differential operation, response time, Cv, check-valve cracking pressure, relief capacity, and seal materials. Oxygen cleaning and oxygen-service compatibility are separate checks in the register.

Purchase options

The spreadsheet separates direct catalog purchases from parts that need a configured order or manufacturer confirmation. Some manual valves and fittings have catalog candidates. Run solenoids and several other valves still need confirmed specifications.

Outcome

The workbook records requirements, candidate parts, supplier links, and open questions so the team can review the choices before ordering.

Why I made it

I wanted to see how much time elevator trips actually take. Users start a timer when they begin waiting, track the ride, and save the trip to their account.

Saved timers and history

Timer state is saved across devices. The app handles time limits, corrections, paginated history, and removing a trip with an undo option.

Backend

I used Cloudflare Pages for hosting and the API, and D1 for account and trip data. The app uses hashed passwords and cookie sessions. The project includes tests for timer boundaries, account isolation, history, and leaderboard calculations.

Poster

I also made a poster with a QR code linking directly to the app.

Gameplay

I worked on round-based enemies, weapons, pickups, movement, and progression. Players can sprint, crouch, slide, and jump. The sandbox unlocks the weapons and gives unlimited health and ammunition.

Player data

I used Firebase Authentication for sign-in, Firestore for profiles and match records, and Realtime Database for positions, world snapshots, and game events.

Multiplayer

The multiplayer code runs the world simulation in a host player's browser. Host election and migration let another player take over when that host leaves.

Iteration

I revised the health bars, weapon behavior, performance, and Gun Game mode. The image shows the sandbox running in the browser.

PDF reader

I used PDF.js for the reader and added page navigation, zoom, and bookmarks. Reading positions are saved to the account so users can continue on another device.

Cloud storage

I deployed the app on Cloudflare Pages. PDF files are stored in R2, and D1 stores the shelf, bookmarks, and reading state.

PDF uploads

The upload code runs PDF optimization in a Web Worker to keep it off the main interface thread. It uses the original file when optimization does not help, and splits large uploads into parts.