# Member of Technical Staff - Firmware at Dimensional > Onsite · United States · Staff · Software engineering · open. Source: https://alderhq.app/jobs/ashby%3Adimensional%3A75f280fe-45a1-4461-a162-9eb758013ca4 (read 2026-11-13). ## Facts (observed) - Company: [Dimensional](https://alderhq.app/companies/dimensional) - Location text: San Francisco - Where it can be done from (inferred): Onsite · United States (evidence: "Location: San Francisco") - Posted: 2026-08-14 (91 days ago) - First seen by alder: 2026-11-04 · last verified: 2026-11-08 - Reposted: 0 times · edited: 0 times - Apply on the employer's site: https://jobs.ashbyhq.com/dimensional/75f280fe-45a1-4461-a162-9eb758013ca4 - Skills listed (inferred): Rust, C++ ## Pay and sponsorship - Posted pay: not posted - Market band for similar posted roles (SF Bay Area, n 1161): p25 $205k, median $240k, p75 $284k ## Description (the employer's text) ### About Dimensional Dimensional is building the foundation for physical intelligence in general-purpose robotics. We develop a unified framework that enables robots to perceive, reason, learn, and act across diverse real-world environments and embodiments. Dimensional’s mission is to make physical intelligence programmable, scalable, and accessible -- accelerating the development of generalist robots that can adapt, learn, and perform reliably in the real world. Our platform sits between robot hardware and AI models, providing a modular, composable architecture for training and deploying robotic intelligence at scale. By abstracting hardware differences and standardizing core capabilities—such as perception, spatial understanding, decision-making, and control—Dimensional allows developers and partners to build, transfer, and operate robotic skills efficiently across platforms. ### 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. ### What we're looking for ### 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. --- Data: alder (https://alderhq.app). Cite https://alderhq.app/jobs/ashby%3Adimensional%3A75f280fe-45a1-4461-a162-9eb758013ca4 and the date you read it. Observed facts come from the employer's own listing; location reach, level, family and skills are inferences.