Robotics and
mission software.

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. A Docker test harness with Gazebo and Isaac Sim supported repeatable navigation tests without requiring vehicle hardware. 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.

Ibrium Studios

Robotic controls and production delivery

ARM Cortex-M · CAN · Altium · Logic-analyzer debugging · AWS · Operating procedures

At Ibrium Studios, I delivered a multi-axis robotic control system for a Disney production, starting with producers’ requirements and carrying it through PCB design, board bring-up, firmware integration, and deployment. I designed multilayer boards in Altium and implemented ARM Cortex-M firmware, connecting the nodes to a central controller over CAN. The system included feedback, fault detection, and safe-stop behavior. These controls made failure handling part of the implementation, alongside the checks needed before production use.

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. I checked the corrected behavior against the motion sequence before production handoff. Timing traces provided evidence for the diagnosis and a way to verify the fix.

Before handoff, I verified motion sequences for production use and prepared operating procedures and crew training. Delivery meant getting the hardware and software working together under a fixed deadline and making the system usable by the production team. 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.

O3 Worldwide

Shipyard planning software

Rust · Python/FastAPI · PostgreSQL · React/TypeScript · OPC-UA · OR-Tools · Docker

Working with shipyard planners at O3, I designed cloud-based coordination across multiple shipyards. A shared ontology connected schedules, orders, parts, and production progress so teams could coordinate interdependent work and trace updates across sites. I built the application with a React/TypeScript interface, Rust and Python services, and PostgreSQL, connecting the operational model 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, with local deployment, role-based access, and tamper-evident audit records. My broader O3 work includes engineering and planning for the O3-led, $15 billion-plus Orlando Sanford International Airport development opportunity. I also support pilot and technician training, aircraft manufacturing, and digital-engineering work spanning blended-wing-body aircraft, unmanned aerial and surface vehicles, and advanced boats and small ships.

I separated the operational model from the supporting services and interface to support expansion across sites. Shared services and a common data model let the architecture accommodate coordination between shipyards while keeping operational changes distinct from interface changes. My earlier work at MedBWS also involved supporting software after deployment. I built pharmaceutical identification and disposal workflows in HIPAA-compliant hospital environments, with secure APIs and audit logging to control access and make application activity traceable.

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