About This RoleYou 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, IC, 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.
What we're looking forMust-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/IC, 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.
