Robot Platform Software Engineer

**Taipei, Taiwan and San Francisco, USA (on-site — hiring in both locations) | Full-time** **You'll be the reason Anvil's robots keep running when nobody's watching — and the person who can explain why, in plain language, to both leadership and the customer standing next to a frozen arm.** Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. We own and operate our own manufacturing in Taipei — no contract manufacturer in the loop — and in our first 12 months we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, Linux Devboxes, and teleop kits) to customers in 60+ countries: NVIDIA's GEAR lab, Qualcomm, Toyota, Google, Physical Intelligence, Cobot, Path Robotics, and the university labs whose papers define robot learning. Devkits are the wedge, not the business. That volume has earned us a custom force-sensing actuator partnership with major actuator OEMs, and the install base becomes both the distribution channel for our next- generation robots and a platform that software partners build on. Every step of that strategy rests on one unglamorous fact: the robots already in the field have to keep working. Every one of those 200+ robots runs on a platform layer nobody notices until it breaks: process orchestration, logging, health, and lifecycle, spanning hardware, ROS2 middleware, and the application layer above it. **The situation you're walking into:** - Anvil ships real robots to real customers, and each one depends on a runtime platform that currently has no single owner — reliability work happens, but it's not anyone's full-time job. - The same engineers who should be heads-down on ML, controls, and manufacturing keep getting pulled into platform fires: a broken bring-up jig, a factory test that won't run, a demo config that needs to work by tomorrow. - Most "it doesn't work" reports actually live at the boundary between hardware, ROS2 middleware, and application code — and the root cause is rarely in the layer where the symptom shows up. - This role is deeply communicative in two directions that have nothing to do with writing code: keeping Anvil's leadership informed on what's happening in robot learning and what it means for product and customers, in plain language; and working directly with deployment customers to understand their constraints and get them to a working outcome. Both audiences are non-technical relative to you, and making them smarter is part of the job, not a distraction from it. **What you'll own:** - Reliability and root cause: keeping robots running 24/7, and fixing hardware, ROS2, and infrastructure issues at the actual root cause, not with a patch that just moves the symptom. - Clean, stable hardware interfaces — APIs between sensors/actuators and the application layers above them— so upstream teams don't have to think about the hardware boundary. - Observability and cloud: the logging, metrics, debugging tooling, and data pipelines that move information between robots and the cloud. - Internal enablement: unblocking ML, controls, and manufacturing quickly — factory testing workflows, experimental URDF or hardware branches, photoshoot/demo configurations, hardware bring-up and PCIe validation, and generally "closing the loop" on last-mile hardware+software problems. **What the first 100 days look like:** - By day 30: ramped on the runtime platform architecture, the ROS2/hardware stack, and current known issues. Has personally closed at least one internal-team unblock (factory testing, bring-up, or a demo config) and shadowed a customer debugging session end to end. - By day 60: has shipped a first real reliability fix or platform improvement that measurably reduces recurring internal escalations. Is the first line of response for at least one class of hardware/software boundary issue. - By day 100: internal teams (ML, controls, manufacturing) are not waiting on platform support for routi…