Firmware Engineer

The world's shipping fleets burn the dirtiest fuel on Earth and coat their hulls with biotoxins to slow biofouling. Fleet Robotics is building the robots that will mitigate both problems.

The Short Version

Fleet Robotics builds autonomous robots that walk on steel structures using electropermanent magnets. We're a small team doing hard technical work at the intersection of autonomy, climate work, marine systems, and novel adhesion technology. We're looking for a firmware engineer who wants to own a complex production codebase that spans multiple domains.

What Our Robot Does

Our robot is a biped that adheres to steel structures (e.g. large marine vessels) using electropermanent magnets (EPMs): solid state magnets that are switched electrically and hold their state without power. A "step" is the atomic unit of locomotion: disengage one foot's EPMs, move, re-engage. Everything in the platform exists to execute that sequence reliably in field conditions.

The firmware spans multiple microcontroller targets communicating over CAN using a custom protocol. It handles motor control, EPM engagement, inertial sensing, and real-time step execution across two magnetically-adhered feet, and interfaces with a companion compute platform running our autonomy stack. The EPM subsystem manages adhesion control and sensing.

There are soft real-time constraints, custom protocols, hardware-specific memory layout requirements, and open problems that matter for safety and performance.

What You Would Own

You will be the primary firmware engineer on the team: managing real-time control firmware, motor coordination, EPM control and sensing, power management, and the boundary between firmware and the high-level autonomy system.

On day one, you will manage gaps in abort behavior, limitations in logging, challenges in stepping sequences, and timing workarounds used to address symptoms rather than root causes. In the medium term, you will own development of our next iteration of the robot as we enter into pilots with customers. In the long term, you will shape the firmware architecture as the robot evolves.

The Stack

• Languages: C/C++ (firmware), Python (tooling and high-level)

• Environment: ARM Cortex microcontrollers, RTOS on the primary controller, bare metal on supporting boards

• Protocols: CAN-based motor control, custom CAN-FD messaging protocol, Protobuf serialization

• Tooling: CMake, Docker-based dev environment, CAN bus sniffer, STM debugger, logic analyzer, oscilloscopes

Who Does Well Here

• You make reasonable decisions under ambiguity and iterate. You don't wait for perfect specs. “We don’t know…” is a starting point, not a blocker.

• Methodical, collaborative troubleshooting is fun for you.

• You want to own a codebase, not execute tickets. When something is broken, you fix it without hesitation.

• You can read unfamiliar firmware and build an accurate mental model quickly.

• Strong instincts about real-time systems: interrupt safety, DMA behavior, timing budgets, CAN bus behavior under load.

• You've shipped hardware products and know the difference between "works in the lab" and "works in the field."

• You bias towards action over theory, testing small chunks of work instead of executing over long development cycles

• You approach new problems systematically by identifying core issues and underlying objectives..

• You thrive in creative problem solving. When the obvious paths are blocked, you reapproach with new and creative solutions.

Backgrounds that could translate well: medical device firmware, automotive embedded systems, industrial automation, actuator hardware. Robotics experience is useful but not required. What matters is whether you think carefully about systems where firmware failure has physical consequences.

What to Expect from a Small Team

We're about fifteen people at the seed stage. Firmware decisions you make ship on the robot. There's no dedicated QA org and no siloed scope - you'll work closely with mechanical, electrical, and software engineers and need enough range to make good calls at those boundaries.

If you want a lot of formal structure early on, this probably isn't the right fit. If you want to build something real with a small team that moves fast, we'd like to talk.