Member of Technical Staff - Firmware

About This Role

You will own the layer between DimOS and the silicon. Today, the boundary between our software stack and the hardware underneath it - kernels, drivers, BSPs, vendor firmware - is spread across the team. This seat consolidates it: you make the hardware trustworthy, so that everything above it can assume timing, buses, and drivers simply behave.

This is a deep infrastructure seat with unusual surface area. One week you're writing a kernel driver for a new actuator; the next you're building a BSP for a new compute module, chasing a clock-domain bug in sensor timestamps, or reverse-engineering a sensor vendor's half-documented firmware protocol so the rest of the team never has to think about it.

What You'll Do

• Design, write, and maintain kernel-level drivers for actuators, motor controllers, and sensors across our robot platforms.
• Build and own board support packages for the compute platforms we ship on (Jetson-class and beyond) - device trees, bootloaders, kernel configs, and power.
• Integrate and wrangle sensor vendor firmware - evaluating it, working around its bugs, negotiating fixes with vendors, and wrapping it in interfaces the rest of DimOS can trust.
• Own bus-level communication (CAN/CAN-FD, EtherCAT, UART/RS-485, SPI, I²C, Ethernet, USB) including timing, synchronization, and failure behavior under load.
• Maintain custom kernel builds: patching, configuring, and upgrading kernels with real-time requirements (PREEMPT_RT-class) as the stack demands.
• Make firmware work CI-able: HIL rigs, replayed bus captures, and mocks so the distributed team can test hardware behavior without hardware in hand.
• Write production PRs into the open-source DimOS repo under the same review bar as every other engineer.

Must-haves

• 5+ years of embedded systems design and development in production environments.
• You have written kernel-level device drivers - for actuators, motor controllers, or comparable real-time peripherals - and shipped them. Not "modified an example driver": designed, debugged, and maintained your own.
• Real-time reasoning: latency budgets, scheduling and priorities, bounded queues, and a clear answer for what happens when a deadline is missed (degrade gracefully, never silently).
• Bus and driver depth across CAN, UART, SPI/I²C, Ethernet, USB - written or substantially debugged, not just used.
• Custom kernel experience: you've configured, patched, and built Linux kernels for embedded targets, and you can reason about what happens between interrupt and userspace.
• You have built your own BSPs - device trees, bootloaders, Yocto or Buildroot pipelines - for boards that shipped.
• Experience working with (and around) sensor vendor firmware: integration, protocol debugging, firmware updates, and vendor escalation.
• Instrument-level debugging: oscilloscope, logic analyzer, JTAG/SWD, kernel logs. You have diagnosis stories from below the API.
• Strong written English and comfort with fully async, distributed collaboration.

Nice to have

• Rust in production (our native layer is increasingly Rust), or embedded Rust curiosity backed by systems C/C++ depth.
• NVIDIA Jetson depth: JetPack/L4T, kernel customization, power modes, thermal tuning.
• PTP/time-sync across multiple compute units; timestamping discipline across clock domains.
• OTA/fleet update systems (Mender, RAUC, SWUpdate), secure boot, provisioning.
• Middleware internals - DDS, Zenoh, LCM, shared-memory transports.
• Board-level literacy: you read schematics, talk to EEs fluently, and can specify a connector unsupervised.
• Open-source contributions - kernel, U-Boot, Zephyr, Yocto layers, or anything we can read.