System Integration · Google (via AutoRoboto)
Automated biometric testing for Pixel.
Robotic system for hardware security testing on Pixel devices. I built the trajectory system, led a full ROS1→ROS2 migration now running across 10 robot labs, and refactored the node architecture for tight robot/camera synchronization.
Context
Modern phone biometrics (face unlock, fingerprint) need to be tested against a wide range of physical attack vectors. Doing that by hand is slow, inconsistent, and limited in coverage. AutoRoboto automates this, using a robotic arm to systematically test biometric security across a large attack space.
What I work on
- Trajectory libraries: Designed a two-phase approach to robot motion: broad calibration sweeps to map the test space, followed by targeted motions at high-priority points. The system combines arm motion with lighting and background variation, which widened the range of setups the team can test against, and it mirrors how a human security researcher would systematically explore vulnerabilities.
- ROS1 → ROS2 migration: Led the full upgrade of the system to ROS2 for modern tooling and long-term support, now deployed across 10 robot labs. Tackled threading model changes, REST API integration, motion planner setup, and launch file rewrites.
- Node architecture refactor: Separated motion planning from motion execution to eliminate idle wait time, since phone camera recording was starting before the robot moved. The new architecture ensures tight synchronization across robot and camera.
- Capture-frame precision: Mapped robot position and velocity onto the exact camera capture frame, so every frame a test produces is tied to a known robot state. That is what makes a result diagnosable rather than merely a pass or fail.
- Human motion on the robot: Measured human movement with an IMU and integrated those motions onto the arm, extending coverage beyond what a fixed synthetic trajectory can represent.
- System integration: Integrated the robot, vision pipeline, device under test, and orchestration layer.
Themes I think about
Building test infrastructure forces a different mindset than building product robotics. The robot isn't the deliverable; reliable coverage of an attack space is the deliverable. That changes how I think about determinism, repeatability, and what "good enough" means for trajectory quality.
Most of the work is in the seams between subsystems: the robot, the device under test, the camera capture, and the orchestration layer all run on different clocks, and a test is only as trustworthy as the weakest synchronization point between them. A lot of my time goes into making the system deterministic enough that a failed test means a real finding, not a timing artifact.