01 / Saddleback College Robotics
Rover autonomy and operator software
Rust · C/C++ · ROS 2 · STM32 · CAN · React/TypeScript · Foxglove · Gazebo · Isaac Sim
On the Saddleback Mars Rover Team, I learned to work across the software running on a robot and the tools used to operate it. I co-led ROS 2 autonomy through two competition seasons, connecting Nav2 behavior trees to navigation informed by stereo cameras, LiDAR, GPS, and IMU data.
An asynchronous Rust driver connected the ROS 2 system to STM32 controls. ODrive motor controllers communicated over CAN, while React/TypeScript and Foxglove interfaces gave operators access to vehicle state. I worked on the interfaces carrying sensor data and control messages between the rover and its operator tools.
I tested the vehicle software through software- and hardware-in-the-loop testing, then checked its behavior during field trials. The ground station provided telemetry and a Jetson video feed over the radio link. Recorded rosbag data let me revisit sensor and control behavior after a run and check whether a software change addressed the problem. Gazebo and Isaac Sim supported repeatable simulation tests when the vehicle was unavailable. I coordinated changes through GitHub reviews so the team could check how an update affected other subsystems. This work gave me experience testing software against hardware, investigating vehicle behavior from recorded data, and improving the system between field runs.
02 / Ibrium Studios
Robotic controls and production delivery
ARM Cortex-M · CAN · Altium · Logic-analyzer debugging · AWS · Operating procedures
At Ibrium Studios, I carried a multi-axis robotic control system from producers’ requirements through custom electronics and firmware to crew handoff for a Disney production. I designed multilayer PCBs in Altium, implemented ARM Cortex-M node firmware, and connected the nodes to a central controller over CAN. Feedback, fault detection, and safe-stop behavior were part of the system.
When motion became intermittently late, I used a logic analyzer to trace the timing across the control path. The cause was a control-loop deadline overrun. I moved scheduling to a fixed-rate timer interrupt and revalidated the motion sequence. Resolving the issue required understanding both the firmware and the physical system.
The work continued through operating procedures and crew training under a fixed deadline. For Depot, I built a shared asset-state model covering ownership, stage, and activity. Active-session conflict detection helped teams avoid interfering with work in progress. Deletion was limited to assets established as unowned or redundant, and AWS shutdown was guarded by activity checks. I remained responsible until the crews could operate the system. I would bring that same involvement to vehicle integration and deployment support.
03 / O3 Worldwide
Shipyard planning software
Rust · Python/FastAPI · PostgreSQL · React/TypeScript · OPC-UA · OR-Tools · Docker
Working with shipyard planners at O3, I developed an operational application with a React/TypeScript interface, Rust and Python services, and PostgreSQL. Planners’ installation knowledge became an ontology of parts, equipment, personnel, and task dependencies connected to OR-Tools scheduling.
Late deliveries and unavailable equipment required changes to the underlying dependency model. I extended the logic and checked the revised behavior through historical replay. OPC-UA adapters connected operational inputs; access controls and event history made changes traceable. The software was developed for potential deployment by U.S. shipbuilders.
This taught me to separate the operation-specific model from the supporting services and interface. It also made user feedback central to architecture. Alongside earlier hospital workflow development and support at MedBWS, it gives me experience carrying applications beyond implementation into use. At MedBWS, I built and supported pharmaceutical workflows across hospitals, with secure APIs, access controls, and audit logging. That work required attention to who could change data and how application activity could be reviewed.
Technical background
Languages and tools
Software development
C++, Rust, Go, Python, TypeScript, React, FastAPI, PostgreSQL
Robotics and testing
ROS 2, Nav2, ARM Cortex-M, STM32, CAN, Gazebo, Isaac Sim, SITL/HITL, rosbag, MATLAB/Simulink
Services and development tools
Linux, AWS, Docker, Git, Nix, WebSocket, Protocol Buffers
My projects include scheduling algorithms, operational data models, asynchronous device interfaces, and repeatable tests. The examples above describe where I used them and how I investigated failures.
Assessments
Assessment results
CodeSignal Industry Coding Assessment
600/600 · August 2026
AFQT Predictor Test
99th percentile · April 2026
Why Anduril
Why I want to work at Anduril
Anduril is where I want to build my career. Learning from mentors at Anduril has strengthened that ambition and shaped the kind of engineer I want to become. I believe in the mission of strengthening American and allied defense, and I want to contribute to it through work I can take responsibility for. I’m looking for the opportunity to keep learning from people I respect while earning their trust through what I build.
I’m based in Irvine and available for full-time onsite work in Costa Mesa and travel. I want to contribute useful software while growing toward ownership of larger vehicle and mission capabilities.
Software Engineer — Undersea Dominance ↗