Founding Simulation Engineer (C++)

You will own the simulation core - the physics engine, sensor simulation, and the bridge between C++ physics and the rest of the platform. This is not a feature team role. The simulation core is the product.

Your work includes:

• Deterministic physics + the regression/replay loop - MuJoCo in deterministic mode (single-threaded, version-pinned, -fno-fast-math), plus the bit-exact replay and baseline-comparison loop that makes simulation usable as CI. This loop is the core of the product.
• Shared-memory IPC - out-of-process ring buffer bridging C++ physics to the platform layer
• ROS2 C++ bridge - native ROS2 integration so customers can use standard tooling (rviz2, rosbag, ros2 topic)
• Sensor simulation + noise/degradation models - LiDAR ray-casting (MuJoCo mj_ray today; Intel Embree on the roadmap) and camera are shipped; you'll deepen them and build the sensor-noise and degraded-signal models (LiDAR, camera, GNSS-denied, IMU) that validation work depends on - feeding physics-state-projection annotations for exact ground truth
• Open-source Nonlimi Core - your work ships under Apache 2.0

Over the first year, you'll extend the core - DART for articulated manipulators, USD pipeline integration, and additional physics domains as new verticals come online.

What You'll Do First

The deterministic core already exists - clone the repo and run nonlimi test scenarios/examples/husky_basic.yaml --output-dir ./artifacts to get a pass/fail verdict and a full artifact bundle in about a second. Your job is to own it and take it from prototype to product: harden the deterministic regression/replay loop, and build the sensor-noise and degraded-signal models the first design-partner proof-of-concept needs. Early on, you'll help land the first measured sim-vs-real correlation result - the evidence that the validation actually predicts hardware behavior.

These are hard gates:

• C++ systems engineering, 4-7 years - performance-critical C++ where memory layout, cache behavior, and undefined behavior were first-class concerns
• Physics engine internals - MuJoCo, Bullet3, PhysX, DART, or Gazebo at the integration level - constraint solver configuration, determinism flags, collision shape management
• C++ shared-memory IPC - POSIX SHM, lock-free ring buffers, std::atomic with explicit acquire/release/seq_cst ordering
• Non-determinism debugging - you have found and fixed a case where physics state diverged across runs, across machines, or after a compiler upgrade

Nice to Have

• MuJoCo C API directly (not just mujoco-py or dm_control wrappers)
• ROS2 C++ (rclcpp, DDS transport, composable nodes, lifecycle nodes)
• pybind11 or similar C++/Python binding experience
• Godot 4 or real-time scene graph experience (Unity, Unreal at the renderer level)
• Sim-to-real deployment - taken a policy from simulation to a physical robot

Type: Full-time · Founding team Location: Remote-first, async-first Compensation: Competitive salary + founding-team equity

About Nonlimi

Nonlimi is building a cloud-native simulation platform for testing and validating AI agents for autonomous systems - ground robots, drones, and autonomous vehicles.

We're building the simulation infrastructure that robotics startups can't afford to build themselves. Our technical foundation: an open-source ROS2 bridge (Apache 2.0), reproducible version-pinned physics with MuJoCo, and physics-state projection annotations for exact ground truth.

We are pre-revenue and architecture-complete, with a deterministic simulation-and-validation core already shipped - deterministic physics, a scenario/regression runner, the ROS2 bridge, and an annotation pipeline - now in active design-partner scoping., * Competitive salary + founding-team equity - calibrated to seniority and depth of experience

• Full architectural ownership - Nonlimi Core is yours to design, build, and evolve
• Open-source impact - you're building simulation infrastructure the robotics community will use
• Direct customer access - you'll talk to autonomy startups and robotics labs directly
• Remote-first, async-first - deep work is the default