Building Reliable Robotics for the Real World

I am a System Software Engineer at Laza Medical, where I build robotic and AI systems for healthcare. My work centers on medical robotics, with a focus on automating echocardiography imaging and improving the reliability of real-world clinical workflows.
I'm particularly interested in problems at the intersection of robotics and uncertainty, where systems must perform reliably despite imperfect data and environments.
When I'm not working on robotics, I'm usually outdoors or sketching on my iPad.
Runs a candidate node beside a production node on the same live inputs, compares their outputs, and reports where they disagree. Only production drives the robot.
$ NavFn as production, Smac 2D as candidate
$ Outputs paired on header.stamp
$ Endpoint, Hausdorff, length and deviation metrics
$ Thresholds raise warnings as they drift...

A scratch-built mobile robot: custom CAD, 3D printed parts, embedded control and ROS 2. Aiming for something that can map and navigate a real room.
$ Pi and Arduino talking over serial
$ LiDAR publishing scans
$ Calibrated odometry, odom -> base_link TF
$ Closed-loop velocity control, cmd_vel in real m/s
$ Voice control via Whisper and an LLM intent parser
$ Next: slam_toolbox mapping, then Nav2...

Segfault in EventsExecutor: a Python set was indexed as an array, so 0 became a null pointer.
Mimic joint offset was parsed from the URDF and then never applied.
Flaky test that bet on the GUI starting within a fixed two seconds.
To provide safety guarantees for learning-based control systems, recent work has developed formal verification methods to apply after training ends. However, if the trained policy does not meet the specifications, or there is conservatism in the verification algorithm, establishing these guarantees may not be possible. Instead, this work proposes to perform verification throughout training to ultimately aim for policies whose properties can be evaluated throughout runtime with lightweight, relaxed verification algorithms.
Read Paper
Vet a new ROS 2 node against the one already running: feed both the same inputs, log where their outputs diverge, and keep the candidate namespaced so only production drives the robot.
A rosbag stores two timestamps per message: when the recorder wrote it, and when the sensor captured it. Pick the wrong one and a recorder stall vanishes from your analysis entirely.
Docker builds repeatedly download the same packages, wasting bandwidth and slowing build times. Using apt-cacher-ng as a local caching proxy solves this by downloading packages once and reusing them for all future installations.