WORK TIMELINE · THREE CAREER ERAS · 2019–2026
Building robot systems that are
deployable and continuously improvable
Systems engineering for reliable delivery; data and evaluation loops for sustained model and system improvement
MIAO DONGXU · ROBOTICS SYSTEMS TECHNICAL LEAD · HANDS-ON · RESUME
2019–2025.03Autonomous drivingProduction delivery → team building → engineering at scale
2025.03–2025 H2Robotics systems deliverySystem integration → task optimization → data and evaluation
2026 → NOWModel adaptation and real robotsFine-tuning → controlled execution → machine-verifiable acceptance
Open with the primary positioning: robotics systems technical lead and hands-on technical leadership. Use the following pages selectively based on the discussion.
THE MAP · FOUR SCOPE EXPANSIONS
Roles changed. Responsibility expanded.
The method stayed consistent.
Start with a delivery problem, establish evidence, turn the solution into a reusable system, then scale it through people and mechanisms
ORIGIN · 2019–2021 · DEEPMOTIONMy first production program: more than a year leading on-site delivery for an SAIC parking collaborationAlgorithm design, field debugging, a minimal data loop, on-device performance, and customer acceptance taught me that model quality is only the starting point
2021–2023 H1Unify repeated systems workShared code, runtime framework, release, replay, and ownership
2023 H2–2025 H1Scale quality and performanceShift-left tests, automatic routing, and whole-system resource budgets
2025Move into robotics deliveryIntegration, task performance, data, evaluation, and real robots
2026 → NOWClose the embodied AI looppi0.5, G2, RoboClaws execution, and RoboHarness acceptance
This page is the navigation map. Jump to the most relevant example instead of presenting every page linearly.
From zero to one: a small team built a shared perception engineering foundation
I built a team of up to nine engineers to turn board integration, platform migration, release, performance, and debugging into shared systems rather than repeated expert work
WHY
Common work depended on a few key people
Multiple vehicle programs and compute platforms repeatedly rebuilt context, making delivery and debugging difficult to scale.
MY SCOPE · TEAM OF UP TO 9
One foundation, complete module ownership
ONE REPO → SHARED RUNTIME → MIL / SIL / HIL → OWNER ROUTING
- Led the stack from industrial PCs to NVIDIA Orin-X, Orin-N, and Thor-U
- Unified release, replay, quality, performance tooling, documentation, and review
- Designed ownership so modules and mechanisms continued after my transfer
1 → NOne codebase across platforms and vehicle programs
1–2 daysTypical time for a new engineer's first useful change
95%Static analysis coverage
Direct management peaked at nine engineers. Broader engineering mechanisms supported a much larger organization; do not describe that reach as direct management.
From one to many: quality and performance became continuously running mechanisms
High-frequency integration, large-scale collaboration, and shared CPU / GPU / memory could no longer depend on release-time inspection or individual firefighting
SHIFT LEFTExpose expensive failures earlierChange → SIL / DIL → runtime checks before release branches
AUTO ROUTEEncode expert judgmentStack analysis → module identification → owner routing → new rules
GOVERN RESOURCESOptimize system budgetsFrame rate, latency, CPU, GPU, memory, scheduling, and model tiers
−98%Average release crash rate per million kilometers
≈1 day → <1hAverage time to localize and route an issue to its owner
<1/5 computeAbout 80% of functional modules on a lower-tier platform
Localization and routing is not full resolution time. The 80% figure counts functional modules; it does not imply equivalent experience or model specifications.
Within 2–3 weeks, I moved into whole-robot delivery
I entered through systems integration, performance, and testing, then expanded into end-to-end responsibility for one complete task
RESPONSIBILITYShared system integration across three workstation types + end-to-end ownership of one taskHorizontal responsibility for integration and resource visibility; vertical responsibility for task quality, release cadence, and delivery
01 · DECOMPOSE90+ focused testsLocalization, mapping, navigation, and seven capability groups
02 · STABILIZECPU P90 <60%From sustained saturation to repeatable system testing
03 · OPERATE300+ runs per typeAutomated reports and handoff to the testing organization
END-TO-END RESULTAverage cycle time for the task I owned: 3.5 minutes → under 2 minutesThis result applies to the one complete task I directly owned, not all three workstation types
This example demonstrates cross-domain ramp-up and bounded end-to-end ownership. Shared integration responsibility does not mean final ownership of every algorithm module.
Connect data production, model evaluation, and real-robot deployment
I owned data production, batch evaluation, deployment, and failure attribution; model colleagues owned architecture and training; shared evidence drove the next iteration
01 · DATASimulation and videoAuto-labeling, multi-model review, and exception handling
02 · TRAINModel teamArchitecture, training, and version output
03 · EVALUATEBatch executionMetrics, trajectories, visual results, and failures
04 · ATTRIBUTEChoose the next moveImprove data, model, environment, or infrastructure
05 · DEPLOYReal robotSensors → cloud/onboard inference → robot control
2×Per-instance data-production throughput
100+ scaleCloud instances for batch data and evaluation
DATA + EVALEvidence used for the next engineering decision
SCENES AND DATAOmniGibson · Habitat · BEHAVIOR-1K · InteriorGS · in-house scenes · Digital TwinPublic sources expanded coverage; in-house scenes and Digital Twin brought validation closer to deployment conditions
The ownership boundary matters: model training belonged to model colleagues during this phase. I owned deployment, data production, batch evaluation, and the evidence loop used to converge jointly.
Turn one evaluation into a continuously running test system
A VLM acts as the test operator, the VLN model executes, an evaluator decides, and an Oracle recovers the environment; unknown failures fall back to humans
01 · OBSERVEUnderstand the sceneRobot view and visible targets
02 · GENERATECreate a taskA feasible go-to instruction
03 · EXECUTERun VLNRecord state and trajectory
04 · DECIDEEvaluate evidenceSuccess, failure, or review
05 · RECOVERMove or resetRestore conditions for the next round
BEFOREHumans controlled the loopObserve, choose targets, move robots, and collect results
NOWVLM takes part of the operator roleInternally deployed with selected scenarios validated
BOUNDARYUnknown failures remain visibleUnresolved exceptions enter a human queue rather than being counted as automation success
This is not a claim of fully autonomous testing at arbitrary scale. It demonstrates a controlled loop in selected scenarios with explicit recovery and human fallback boundaries.
Model adaptation, controlled execution, and machine-verifiable acceptance
Task adaptation creates capability, controlled execution connects it to robots, and acceptance produces traceable evidence
01 · MODEL ADAPTATION
Bring upstream models into our tasks
DATA → FINE-TUNE → INFERENCE → SENSOR / CONTROL → G2
- Two concrete pi0.5 tasks
- Data, fine-tuning, inference, scene adaptation, and G2 execution
02 · ROBOCLAWS
Map open goals to controlled capabilities
GOAL → AGENT → SKILL → MCP → ROBOT
- Agent plans and selects skills
- Stable, observable, debuggable robot interfaces
03 · ROBOHARNESS
Let development agents prove completion
CONTRACT → METRIC + VISUAL → BASELINE → PROOF PACK
- Success and failure boundaries defined first
- Automatic evidence with pass, fail, or human review
2 taskspi0.5 adaptation through G2 execution
>90%Action success on a bounded manipulation task set
1st placeDepartment AI Hackathon · RoboHarness
PUBLIC-SAFE IMPLEMENTATIONS
These three proofs use different scopes. The manipulation success rate is not an agent end-to-end success rate, and the G2 result proves a connected task chain rather than stable general performance.
THE ANSWER · HANDS-ON TECHNICAL LEADERSHIP
Systems engineering enables reliable delivery
Data and evaluation drive continuous improvement
01 · DEFINEBoundaries and acceptanceSystem scope, resource budgets, and task success
02 · OBSERVEEvidence and visibilityMetrics, replay, simulation, and real-robot results
03 · CLOSE LOOPMake solutions repeatableTesting, routing, recovery, and evaluation
04 · SCALEPeople and mechanismsOwners, teams, platforms, and evidence-bound agents
PRIMARY DIRECTIONRobotics Systems Technical Lead · Hands-on Technical LeadSystems engineering and reliable delivery as the foundation; data and evaluation, model post-training, and real-robot adaptation as technical depth
DISCUSS · SYSTEMS / DATA + EVAL / MODEL ADAPTATION / TEAM BUILDING
Close on the target responsibility, then ask which part is closest to the team's current challenges and return directly to that page.