Data & Teleoperation Engineer

• Data layer: robot logs, teleoperation recordings, demonstrations, annotations, metadata, dataset curation, data quality, data governance, and training-data pipelines.
• Fleet layer: operational telemetry, remote sessions, robot uptime, failure reports, health metrics, field-event mining, and deployment feedback loops.
• Brain: datasets and evaluation sets for robot learning, imitation learning, reinforcement learning, vision-language-action models, and world models.
• Hands: teleoperated manipulation demonstrations, grasp attempts, dexterity data, force/tactile logs, bimanual task data, and recovery examples.
• Legs: human motion data, retargeted trajectories, balance/locomotion logs, gait events, falls, near-falls, and whole-body motion datasets.
• Eyes: camera, depth, LiDAR, segmentation, tracking, calibration, and annotation data used by perception and embodied AI teams.
• Simulation layer: synthetic data, motion retargeting, sim replay, dataset generation, sim-to-real comparisons, and evaluation scenarios.
• Factory layer: data from robot bring-up, end-of-line tests, QA checks, maintenance events, and production validation.

A data and teleoperation engineer builds the systems, tools, and workflows that let humanoid teams collect, move, clean, inspect, label, replay, and use robot data.

In a humanoid company, the work often includes:

• Building data pipelines that ingest robot logs, sensor streams, teleoperation recordings, task metadata, operator notes, safety events, and model outputs.
• Designing data schemas for time-synchronized robot data: images, depth, audio, joint states, force/torque, tactile data, IMU, commands, actions, policy outputs, battery status, errors, and environment context.
• Maintaining reliable offload from robots to on-premise storage or cloud storage without corrupting data or losing important metadata.
• Building teleoperation tooling for robot pilots, data creators, QA testers, or remote operators.
• Supporting VR/AR, motion capture, gamepad, haptic, web-based, or custom teleoperation interfaces.
• Creating tools that let engineers replay robot sessions, inspect failures, compare model versions, and pull examples for training or evaluation.
• Building dashboards for dataset health: data volume, task coverage, success/failure balance, operator consistency, sensor dropouts, label quality, and field failure trends.
• Working with AI and robot learning teams to understand what data is useful for imitation learning, reinforcement learning, world models, video pretraining, or policy evaluation.
• Working with controls, locomotion, and manipulation teams to process human motion data, retarget trajectories, align action spaces, and flag physically impossible demonstrations.
• Working with perception teams to organize image/video/depth data, calibration metadata, annotations, and edge cases.
• Working with robot operators to improve collection procedures, task scripts, equipment setup, issue reporting, and safety checks.
• Building or improving annotation tools, review tools, triage workflows, and dataset curation processes.
• Ensuring privacy, access control, encryption, auditability, and data retention rules are respected, especially when robots collect data in homes, factories, warehouses, or customer sites.
• Turning messy real-world robot sessions into datasets that engineers can trust.

The job can look very different by company. In one team, this role may be mostly backend/data infrastructure. In another, it may involve teleoperation software, operator tools, robot log replay, ML dataset preparation, or hands-on data collection with robots.

What the work feels like day to day

A normal week might include:

• Debugging why a teleoperation session produced unusable data because camera frames, robot actions, and operator commands were not aligned correctly.
• Building an ingestion job that moves robot logs from local SSDs to a data lake and verifies checksums, metadata, and timestamps.
• Adding a review interface where AI engineers can find all failed attempts for a specific manipulation task.
• Working with a robot pilot team to standardize how demonstrations are performed, named, uploaded, and tagged.
• Investigating why a batch of data has missing proprioception, wrong calibration metadata, or inconsistent task labels.
• Writing a Python script that extracts high-quality grasp attempts from thousands of teleoperation episodes.
• Adding metrics for teleoperation latency, packet loss, frame drops, operator interventions, and task completion time.
• Building a dataset split for model training, validation, and out-of-distribution evaluation.
• Supporting a data collection session where operators use VR/AR equipment or motion capture hardware to guide humanoid motions.
• Creating a replay tool that shows synchronized video, robot state, operator commands, model output, and error events on one timeline.
• Working with security or IT to make remote access and data movement safe enough for customer deployments.
• Meeting with robot learning engineers to decide which failure cases should be collected next.

The best data and teleoperation engineers are not just pipeline builders. They understand that a robot dataset is only valuable if it is physically meaningful, searchable, reproducible, and connected to the robot's real failure modes.

Modern humanoid robotics depends on data loops. A humanoid company cannot rely only on hand-written code, one-off demos, or static datasets. The robot has to improve from real operation, human demonstrations, simulation, evaluation, and repeated failures.

Data and teleoperation engineering matters because humanoids need:

1. High-quality demonstrations
   Imitation learning, robot learning, and many embodied AI workflows depend on demonstrations that show the robot what good task execution looks like. Bad demonstrations teach bad behavior.

2. Failure coverage
   Robots fail in specific, physical ways: missed grasps, dropped objects, occluded cameras, bad contact, foot slips, calibration drift, operator confusion, network latency, and unexpected human actions. Data systems must capture these failures, not just clean successes.

3. Time-synchronized multimodal data
   Humanoid data is not just a table. It can include video, depth, audio, joint states, force, tactile readings, commands, actions, text instructions, task labels, environment metadata, and safety events. If timing is wrong, the data may be useless.

4. Learning from human control
   Teleoperation gives humanoid teams a way to collect human-like task strategies, teach new behaviors, bootstrap policies, validate interfaces, and operate robots before full autonomy is ready.

5. Better evaluation
   AI teams need stable evaluation sets, edge-case libraries, task success metrics, and regression data. Without this, teams can fool themselves with cherry-picked demos.

6. Fleet feedback loops
   As robots move into pilot sites, factories, warehouses, and homes, data from the fleet becomes one of the main ways to find reliability issues and improve the product.

7. Traceability and safety
   If a robot behaves badly, teams need to know what happened, when it happened, which software version ran, what the sensors saw, what command was issued, whether a human intervened, and how the system recovered.

8. Scaling physical AI
   A humanoid company may eventually need thousands or millions of useful episodes, not a few lab recordings. The data loop has to scale without becoming chaotic.

A simple rule: robot data is not valuable because it is large. It is valuable when it is trustworthy, searchable, aligned with real tasks, and useful for improving behavior.

This role fits several backgrounds. The right entry point depends on whether the candidate is stronger in software, data systems, robotics, operations, ML, or hands-on robot work.

Data engineers and backend engineers

You already have useful skills: pipelines, databases, APIs, storage, distributed systems, cloud infrastructure, data quality, monitoring, Python, SQL, Kafka-like systems, batch processing, and production reliability.

You are probably missing: robot data formats, time synchronization, sensor streams, ROS 2, coordinate frames, robot logs, teleoperation workflows, physical task labels, and hardware failure modes.

Best entry angle: robot data platform engineer, robotics data engineer, fleet data engineer, data infrastructure engineer for robotics, telemetry pipeline engineer, or annotation tooling engineer.

Robotics software engineers

You already understand robot middleware, sensors, transforms, logs, simulation, hardware integration, debugging, and real robot failures.

You are probably missing: large-scale data infrastructure, data modeling, storage systems, governance, annotation workflows, dataset versioning, ML data requirements, and cloud/on-premise hybrid deployment.

Best entry angle: teleoperation software engineer, robot log infrastructure engineer, robot data tools engineer, replay tooling engineer, or robotics data platform engineer.

AI and machine learning engineers

You already understand datasets, model training, evaluation, metrics, experiment tracking, data quality, Python, PyTorch/JAX workflows, and inference constraints.

You are probably missing: robot runtime data, physical action spaces, teleoperation collection, sensor timing, robot logs, human demonstration quality, and safety/field constraints.

Best entry angle: robot learning data engineer, dataset curation engineer, model evaluation data engineer, embodied AI data engineer, or AI data operations engineer.

Robot operators, QA testers, and technicians

You already have practical strengths: attention to detail, procedure-following, hardware awareness, issue reporting, hands-on robot setup, safety discipline, and pattern recognition from real robot behavior.

You are probably missing: Python, SQL, data formats, scripting, basic robotics software, dashboards, telemetry, version control, and dataset quality methods.

Best entry angle: data collection operator, robot pilot, data quality analyst, QA data technician, teleoperation support technician, robot operations data analyst, or junior data tooling role after building technical evidence.

Simulation and game-engine engineers

You already understand 3D interfaces, game loops, cameras, controllers, VR/AR, physics engines, scene data, animation, motion capture, and real-time interaction.

You are probably missing: robot middleware, robot kinematics, teleoperation-to-policy data, robot description formats, motion retargeting constraints, and real hardware limits.

Best entry angle: teleoperation interface engineer, human motion data engineer, motion retargeting engineer, synthetic data engineer, simulation-to-data pipeline engineer, or VR/AR teleoperation systems engineer.

Perception and computer vision engineers

You already understand cameras, video, depth, labels, segmentation, detection, tracking, calibration, data augmentation, and evaluation metrics.

You are probably missing: robot action data, teleoperation commands, proprioception, robot logs, dataset curation across modalities, and how perception data drives physical actions.

Best entry angle: perception data engineer, annotation tooling engineer, multimodal dataset engineer, edge-case mining engineer, or robot data quality engineer.

Operations and program managers

You already understand workflows, staffing, shift operations, process documentation, metrics, cross-functional coordination, and execution discipline.

You are probably missing: robotics data formats, technical debugging, scripting, data systems, robot safety procedures, and model-training data requirements.

Best entry angle: AI data operations lead, robot data collection coordinator, data strategy associate, robot operations manager, pilot team lead, or data collection program manager.

Think of this role in layers. Do not try to become a robot learning researcher, data platform engineer, teleoperator, and robotics software engineer all at once. Pick a target lane and build evidence.

Core data and software skills

These are useful for most engineering versions of the role.

• Python: data processing, scripts, automation, log parsing, API clients, validation jobs, and ML dataset preparation.
• SQL: dataset inspection, metadata queries, quality checks, operational reporting, and experiment analysis.
• Data modeling: schemas, IDs, timestamps, metadata, session structure, robot versions, task labels, and provenance.
• Backend APIs: REST, gRPC, authentication, authorization, access patterns, and internal tooling.
• Storage systems: object storage, relational databases, time-series databases, data warehouses, and local robot storage.
• Batch and streaming pipelines: ingestion jobs, message queues, workflow orchestration, retries, idempotency, and monitoring.
• Testing and validation: data integrity checks, schema tests, replay tests, quality gates, and reproducible pipelines.
• Linux and networking: logs, services, SSH, bandwidth, latency, packet loss, storage mounts, and edge devices.
• Git and CI: version control, code review, repeatable builds, automated checks, and deployment discipline.

Robotics data foundations

These separate robot data work from normal data engineering.

• Time synchronization across cameras, sensors, robot state, teleoperation commands, and policy outputs.
• ROS 2 topics, bags, messages, parameters, transforms, and launch files.
• MCAP/rosbag-style log recording and replay.
• Coordinate frames, transforms, and calibration metadata.
• Proprioception: joint positions, velocities, torques, efforts, current, temperature, and actuator state.
• Sensor modalities: RGB, depth, LiDAR, audio, IMU, force/torque, tactile, encoders, battery, and diagnostics.
• Robot state machines, task phases, success/failure labels, and operator interventions.
• Hardware constraints that affect data: dropped frames, CPU/GPU load, storage limits, overheating, cable problems, calibration drift, and network instability.
• Safety events, E-stops, watchdogs, fault states, and degraded operation.

Teleoperation skills

These are especially useful for roles tied to robot pilots, data creators, and remote operation.

• Teleoperation latency, jitter, packet loss, and control-loop constraints.
• Operator interfaces: VR/AR, hand controllers, gamepads, haptics, web dashboards, command stations, and custom rigs.
• Human demonstration quality: consistency, task coverage, natural motion, timing, spatial awareness, and recovery behavior.
• Robot bring-up and shutdown procedures.
• Calibration of teleoperation equipment and tracking systems.
• Motion capture and human motion data collection.
• Motion retargeting from human demonstrations to robot body constraints.
• Operator training, SOPs, issue reporting, and safety discipline.
• Remote access and security for robots at customer or pilot sites.

ML data and dataset skills

These matter when the role supports robot learning or embodied AI.

• Dataset splitting: training, validation, test, out-of-distribution, and regression sets.
• Dataset versioning and lineage.
• Labeling and annotation workflows.
• Quality metrics: label agreement, missing data, class balance, task coverage, success/failure coverage, operator bias, and environment diversity.
• Data filtering: removing corrupt, duplicated, unsafe, misaligned, or misleading episodes.
• Episode segmentation: identifying task start, task end, key events, recoveries, and failure points.
• Data sampling for imitation learning, reinforcement learning, video pretraining, and policy evaluation.
• Evaluation dashboards that compare model versions against stable task datasets.
• Failure mining: finding examples that explain why a model or behavior regressed.

Humanoid-specific skills

These become important as the page moves from generic robotics data into humanoid robotics.

• Whole-body motion data and contact events.
• Human-to-humanoid motion retargeting.
• Dexterous manipulation demonstrations.
• Bimanual coordination data.
• Walking, balance, slips, falls, and recovery logs.
• Multi-camera first-person and third-person task recordings.
• Hand-eye coordination data.
• Force/tactile data for grasping and contact-rich tasks.
• Human-in-the-loop operation and safety boundaries.
• Data collection in homes, warehouses, factories, labs, and customer environments.

Security, privacy, and governance

These are not optional once robots leave the lab.

• Access control and role-based permissions.
• Encryption at rest and in transit.
• Audit logs for data access and remote robot access.
• Data retention policies.
• Privacy review for video/audio/home/customer-site data.
• Redaction, anonymization, and restricted datasets.
• Secure upload/offload from robots and operator stations.
• Compliance with customer-site rules and company policies.

Do not present this list as a required syllabus. Different companies use different internal stacks. These are the common clusters candidates should recognize.

Robot data recording and replay

• rosbag2: recording and playback of data from ROS 2 systems.
• MCAP: a common open-source container format for timestamped multimodal robotics logs.
• Foxglove: visualization, upload, organization, and inspection of multimodal robotics log data.
• RViz: visualization of ROS data such as transforms, point clouds, robot models, and sensor streams.
• Custom robot loggers: many humanoid companies use internal log formats or wrappers around open formats.

Robotics middleware and runtime

• ROS 2: useful for learning robot messages, topics, services, actions, bags, transforms, and launch workflows.
• DDS: communication layer used under ROS 2.
• LCM / ZeroMQ / custom pub-sub systems: sometimes used in robotics stacks.
• Robot description formats: URDF, xacro, MJCF, USD, and company-specific formats.

Data engineering and infrastructure

• Python: data processing, automation, validation, dashboards, and ML dataset scripts.
• SQL: metadata, operational analytics, dataset queries, and quality checks.
• PostgreSQL / MySQL: relational data stores for metadata and internal tools.
• Redis / ElasticSearch / OpenSearch: indexing, search, queues, and operational tooling.
• Parquet / Arrow / HDF5 / Zarr: data formats often used for structured or large scientific/ML datasets.
• S3 / GCS / Azure Blob / on-premise object storage: storage for logs, videos, datasets, model artifacts, and robot recordings.
• Kafka / Redpanda / Pub/Sub / Kinesis: streaming data systems where real-time ingestion is needed.
• Airflow / Dagster / Prefect: workflow orchestration for batch pipelines.
• Spark / Ray / Dask: distributed data processing where dataset scale requires it.
• Docker / Kubernetes: packaging and deployment of backend services, data jobs, and internal tools.
• Terraform / Ansible / Helm: infrastructure and configuration management.

Teleoperation and human motion tooling

• VR/AR headsets and controllers.
• Motion capture systems.
• Haptic devices and force-feedback interfaces.
• Gamepads, joysticks, exoskeleton-style controllers, gloves, and custom operator rigs.
• Web-based operator dashboards.
• Unity / Unreal Engine for 3D teleoperation interfaces, training environments, and motion visualization.
• Human motion formats such as BVH, FBX, USD, and custom skeleton formats.
• Retargeting libraries and kinematics/dynamics tools.

Annotation and data quality

• Label Studio: open-source labeling and annotation workflows for images, video, text, audio, and time series.
• CVAT: image/video annotation tooling.
• Internal labeling tools for robot-specific events, task phases, and operator actions.
• Data quality dashboards in Grafana, Superset, Metabase, Streamlit, Dash, or internal web apps.
• Review queues for failure mining, edge-case review, and episode scoring.

Robot learning data workflows

• PyTorch or JAX data loaders.
• RLDS-style datasets and robot learning dataset formats.
• Open X-Embodiment-style cross-robot datasets.
• DROID-style real-world robot manipulation datasets.
• Experiment tracking with Weights & Biases, MLflow, or internal systems.
• Dataset versioning and model evaluation dashboards.

Monitoring and operations

• Prometheus, Grafana, OpenTelemetry, Datadog, or custom fleet monitoring.
• Jira, Linear, or issue-tracking systems for robot failures.
• Incident and triage tools.
• Remote access tooling with audit controls.
• Asset management for robots, operator stations, headsets, cameras, calibration targets, and lab equipment.

A good portfolio for this role should show that you can turn messy robot activity into usable data. A hiring team should see evidence of data quality, replay, metadata design, and practical debugging.

Project 1: Robot log ingestion and replay pipeline

Build: a small robotics data pipeline that records a simulated robot session, stores the log with metadata, validates it, and lets a user replay or inspect the session.

Use ROS 2 with a simulated robot or a simple sensor setup. Record camera or simulated sensor data, robot state, commands, task status, and diagnostics. Store metadata in a small database and logs in local object storage or a simple file structure.

What it proves:

• You understand robot log structure.
• You can preserve metadata, timestamps, and provenance.
• You can build a practical pipeline rather than a one-off script.
• You understand replay and reproducibility.

Evidence to include:

• GitHub repo with clear README.
• Architecture diagram.
• Example recorded session.
• Metadata schema.
• Data validation checks.
• Replay instructions.
• A short explanation of what can go wrong and how your pipeline detects it.

Project 2: Teleoperation session review tool

Build: a web or desktop tool that displays a teleoperation session timeline with synchronized video, robot state, operator commands, and task events.

You can use simulated data if you do not have robot hardware. The key is to show the review workflow: task start, task end, command timeline, success/failure labels, dropped frames, interventions, and notes.

What it proves:

• You understand the needs of robot operators and AI teams.
• You can make multimodal data inspectable.
• You can design a useful internal tool.
• You understand synchronization and event labeling.

Evidence to include:

• Screenshots or demo video.
• Data format description.
• Example task session.
• Timeline UI.
• Notes on latency, missing data, and label quality.

Project 3: Dataset quality dashboard for robot learning

Build: a dashboard that tracks dataset quality across robot task episodes.

Use a public robot dataset, a simulated dataset, or your own small collected dataset. Track metrics such as number of episodes, task types, success/failure rate, episode length, missing sensor fields, label completeness, operator/source, environment diversity, and train/validation split.

What it proves:

• You understand that dataset quality matters more than raw data volume.
• You can turn robot data into actionable metrics.
• You can support ML teams with data visibility.
• You can explain what data should be collected next.

Evidence to include:

• Dashboard screenshots.
• Metrics definitions.
• Example queries.
• Dataset split logic.
• Written analysis of the dataset's weaknesses.

Project 4: Human motion to robot trajectory retargeting demo

Build: a simple pipeline that takes human motion data and maps it onto a robot model in simulation.

This does not need to be a perfect humanoid controller. The goal is to show that you understand skeleton mapping, joint limits, coordinate transforms, smoothing, feasibility checks, and visualization.

What it proves:

• You understand human motion data.
• You can reason about robot constraints.
• You can connect motion data to simulation.
• You understand why not all human motion is directly usable by a robot.

Evidence to include:

• Input motion source.
• Robot model used.
• Retargeting method.
• Joint limit checks.
• Before/after visualization.
• Notes on what remains physically unrealistic.

Project 5: Failure mining from robot episodes

Build: a tool that searches robot episodes for specific failure patterns, such as dropped sensor streams, high teleoperation latency, failed grasps, repeated retries, missing transforms, or safety stops.

Use simulated logs or public datasets if needed. The important part is the workflow: define failure patterns, find examples, create review queues, and export clips or metadata for engineers.

What it proves:

• You understand robot debugging from data.
• You can turn raw logs into engineering feedback.
• You can build useful tools for AI, software, field, and operations teams.
• You understand that failures are training data when captured properly.

Evidence to include:

• Failure pattern definitions.
• Example detected failures.
• Review queue or report.
• Exported clips or session links.
• Explanation of false positives and false negatives.

Project 6: Data collection SOP and operator QA package

Build: a practical data collection package for a simple robot or simulated teleoperation task.

Include task instructions, operator checklist, safety notes, naming conventions, data upload procedure, issue-report template, quality scoring rubric, and a small sample dataset.

What it proves:

• You understand the human side of robot data collection.
• You can standardize messy operational workflows.
• You can make data collection repeatable.
• You can bridge operators and engineers.

Evidence to include:

• SOP document.
• Checklist.
• Quality scoring rubric.
• Example issue reports.
• Example dataset folder structure.
• Notes on how you would train new operators.

Data and teleoperation roles rarely use one exact title. Use these titles and keywords when building the jobs taxonomy.

Direct engineering titles

• Data & Teleoperation Engineer
• Robotics Data Engineer
• Robot Data Engineer
• Robotics Data Platform Engineer
• Data Platform Engineer, Robotics
• Teleoperation Software Engineer
• Teleoperation Systems Engineer
• Robot Data Infrastructure Engineer
• Fleet Data Engineer, Robotics
• Robot Log Infrastructure Engineer
• Robot Learning Data Engineer
• Human Motion Data Engineer
• Motion Data Engineer, Robotics
• Motion Retargeting Engineer
• Dataset Curation Engineer, Robotics
• Annotation Tooling Engineer, Robotics
• AI Data Infrastructure Engineer, Robotics

Operations and data collection titles

• Robot Pilot
• Humanoid Robot Pilot
• Teleoperator
• Robot Operator
• Data Collection Operator, Robotics
• Robot Data Collector
• Data Creator, Robotics
• AI Data Operations Lead
• Data Collection Lead
• Data Quality Analyst, Robotics
• Data Quality Partner Lead
• Robot Operations Data Analyst
• Teleoperation Hardware Technician
• Teleoperation Support Technician
• Robot Data Collection Coordinator
• Data Strategy Associate, Robotics

Adjacent titles

• Robotics Software Engineer, Data
• Backend Software Engineer, Robotics Data
• Software Engineer, Human Motion Data
• ML Data Engineer, Robotics
• Robotics Data Scientist
• Fleet Operations Analyst
• Robot Reliability Data Analyst
• Field Data Engineer, Robotics
• Simulation Data Engineer
• Synthetic Data Engineer, Robotics
• Perception Data Engineer
• Video Data Engineer, Robotics

Search keywords

Use these as job-board filters:

• robotics data
• robot data
• teleoperation
• teleop
• humanoid pilot
• robot pilot
• data collection robotics
• robot operator
• data platform robotics
• robot telemetry
• robot logs
• MCAP
• rosbag
• Foxglove
• robot dataset
• data quality robotics
• annotation tooling robotics
• human motion data
• motion capture robotics
• motion retargeting
• imitation learning data
• robot learning data
• fleet data robotics
• AI data operations robotics
• VR teleoperation
• AR teleoperation
• teleoperation hardware

Job openings change quickly. Treat this as a live company map, not a permanent list. These are strong examples to seed the Companies and Jobs sections.

Figure

Figure is one of the clearest current examples for this role family. Its jobs page has a dedicated data collection category with roles such as AI data operations, data quality, data strategy, teleoperation hardware support, data creators, and humanoid robot pilots. Figure also has AI data infrastructure roles focused on offloading, storing, manipulating, and providing access to robot data.

Why it matters for this role: Figure shows the full spread of the data loop: robot pilot work, human motion/data creation, teleoperation equipment, data quality, data operations, robot-data infrastructure, and AI training support.

Useful internal links to create:

• /careers/companies/figure
• /careers/jobs?company=figure&role_family=data-teleoperation
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/robot-operations-fleet-operator
• /careers/role-atlas/field-robotics-engineer

Apptronik

Apptronik has strong signals for both technical data infrastructure and human motion data. Its data platform roles reference telemetry, sensor data, training data, batch and streaming workflows, APIs, cloud/hybrid infrastructure, governance, and ML/robotics use cases. Its human motion data roles reference motion capture, teleoperation, synthetic generation, motion retargeting, physically viable trajectories, and reinforcement learning support.

Why it matters for this role: Apptronik is a good example of data and teleoperation as engineering infrastructure, not just annotation or operator work. The data supports Apollo development, reinforcement learning, motion control, fleet analytics, and production operation.

Useful internal links to create:

• /careers/companies/apptronik
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/locomotion-engineer
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/controls-engineer

Tesla Optimus

Tesla has current Optimus-related data signals including data collection operator roles, data labeling roles connected to Optimus data collectors, and AI backend/teleoperation platform work connected to Autopilot, Robotaxi, and Optimus.

Why it matters for this role: Tesla is useful for showing that humanoid data work spans physical data collection, labeling, backend infrastructure, teleoperation platforms, and AI training loops.

Useful internal links to create:

• /careers/companies/tesla-optimus
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/perception-engineer
• /careers/role-atlas/robot-operations-fleet-operator

1X Technologies

1X's careers page includes AI, simulation, fleet operations, product/data, robot service, robot operations management, and cloud/infrastructure roles depending on the hiring cycle.

Why it matters for this role: 1X is a useful example for candidates interested in home humanoid robots, world models, fleet operations, simulation, data product work, robot services, and data loops from real robots.

Useful internal links to create:

• /careers/companies/1x-technologies
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/simulation-engineer
• /careers/role-atlas/robot-operations-fleet-operator
• /careers/role-atlas/robotics-product-manager

Sanctuary AI

Sanctuary AI positions its work around physical AI, robotic hands, AI, robotics, sensing, controls, simulation, hardware, and real-world deployment. Its careers page also highlights the operator/research crossover through a General Purpose Robot Pilot quote about developing teleoperation techniques and piloting a physical robot.

Why it matters for this role: Sanctuary is a good example of teleoperation, physical AI experimentation, robot pilots, dexterous manipulation, and deployment experience being close to the core product loop.

Useful internal links to create:

• /careers/companies/sanctuary-ai
• /careers/role-atlas/manipulation-engineer
• /careers/role-atlas/robotics-ai-engineer
• /careers/role-atlas/robot-operations-fleet-operator

Agility Robotics

Agility Robotics is a useful company to include for fleet and field data context. Digit is deployed for industrial automation, and the company emphasizes robots that ship, deploy, and work in real environments.

Why it matters for this role: Agility is relevant for candidates interested in production robot telemetry, field reliability, operations feedback, warehouse/logistics deployments, and the data loop that comes from deployed humanoid-class robots.

Useful internal links to create:

• /careers/companies/agility-robotics
• /careers/role-atlas/field-robotics-engineer
• /careers/role-atlas/robot-operations-fleet-operator
• /careers/role-atlas/robot-test-validation-engineer

Boston Dynamics

Boston Dynamics is a useful adjacent company for real robot data, testing, operator applications, automation, and robotics software systems.

Why it matters for this role: Candidates can learn from Boston Dynamics-style needs around real robot testing, log review, operator tooling, autonomy validation, and advanced mobile manipulation systems.

Useful internal links to create:

• /careers/companies/boston-dynamics
• /careers/role-atlas/robotics-software-engineer
• /careers/role-atlas/robot-test-validation-engineer
• /careers/role-atlas/field-robotics-engineer

A candidate becomes credible for data and teleoperation roles when they can show that they understand both data systems and the physical reality behind robot data.

Strong positive signals

• Can explain how robot data moves from the robot to storage, review tools, datasets, and model training.
• Understands timestamps, synchronization, dropped frames, missing data, and replay.
• Has built a data pipeline with validation checks, metadata, and reproducibility.
• Can work with multimodal data: video, robot state, actions, diagnostics, labels, and events.
• Understands that data quality is not only label accuracy; it also includes task coverage, physical realism, operator consistency, and failure coverage.
• Can explain how teleoperation latency or bad calibration can ruin a dataset.
• Has used or built tools for log inspection, dashboards, annotation, or review queues.
• Can talk clearly about privacy, access control, and data retention for real-world robot data.
• Understands the difference between a successful demo and a useful training episode.
• Can work with operators, AI engineers, robotics software engineers, and field teams without losing context.

Weak signals

• Talks about robot data as if it were normal web analytics.
• Only understands tables and dashboards, not video, time series, robot state, or action data.
• Cannot explain how data is synchronized or replayed.
• Ignores metadata, calibration, software version, robot version, and task context.
• Over-focuses on data volume and ignores data quality.
• Has no plan for corrupt, partial, duplicated, mislabeled, or unsafe data.
• Treats teleoperation as just “remote control” rather than a data collection and safety-critical system.
• Has no understanding of operator workflows.
• Cannot explain how ML teams would consume the dataset.
• Cannot explain how field failures become engineering feedback.

Interview questions to prepare for

• Walk me through a robot data pipeline from collection to model training.
• How would you design a schema for a teleoperation session?
• What metadata should be stored with every robot episode?
• How would you detect that camera frames and robot actions are misaligned?
• How would you design a review tool for failed manipulation attempts?
• How would you measure the quality of teleoperation demonstrations?
• What data would you collect from a humanoid robot during a customer deployment?
• How would you handle corrupted or incomplete robot logs?
• How would you protect video data collected in a customer's facility or home?
• How would you help an AI team find more examples of a specific failure mode?
• How would you decide whether a dataset is ready for training?
• What is the difference between data for debugging and data for imitation learning?
• How would you reduce operator-to-operator variation in demonstrations?
• How would you monitor teleoperation latency and packet loss?
• How would you build a train/validation/test split for robot task episodes?

• Treating data collection as low-skill work. Good robot data depends on procedure, safety, timing, calibration, task design, and quality control.
• Only talking about big data. Humanoid robotics needs useful data, not just large data.
• Ignoring physical context. A robot episode without robot version, software version, calibration, task setup, operator notes, and environment metadata may be hard to use.
• Skipping replay. If engineers cannot replay or inspect a session, they cannot reliably debug or learn from it.
• Confusing operator roles with engineering roles. Robot pilots and data creators can be strong entry paths, but engineering roles require stronger software/data skills.
• Ignoring privacy and security. Robots can record sensitive environments. Access, retention, and auditability matter.
• Overclaiming autonomy. Be precise about what was autonomous, teleoperated, scripted, assisted, or manually labeled.
• Building dashboards without decisions. A good dashboard helps teams decide what data to collect, clean, label, train on, or investigate.
• Not documenting data assumptions. Future users need to know what the dataset contains, excludes, and cannot prove.
• Forgetting the operator experience. If teleoperation tools are painful, inconsistent, unsafe, or unreliable, the dataset suffers.

This section is optional on Role Atlas pages, but useful for readers who are ready to act.

First 30 days: understand robot data

• Learn ROS 2 basics: topics, messages, bags, transforms, and replay.
• Record and replay a small robot or simulation session.
• Learn MCAP/rosbag concepts.
• Practise Python data processing and SQL basics.
• Learn what metadata matters for robot sessions.
• Study one public robot learning dataset and document its structure.

Output: a small recorded robot/simulation dataset with metadata, replay instructions, and a README explaining each field.

Days 31–60: build a usable data pipeline

• Build an ingestion script that validates sessions and stores metadata.
• Add quality checks for missing streams, corrupt files, timestamp gaps, and incomplete labels.
• Build a simple dashboard or report for dataset coverage.
• Add a review workflow for success/failure labels.
• Write a basic schema for teleoperation sessions.

Output: a robot data pipeline that can ingest multiple episodes, flag bad data, and produce a dataset quality report.

Days 61–90: make it look hireable

• Build a replay/review UI or notebook that synchronizes video, robot state, commands, and events.
• Add failure mining for one specific issue.
• Create train/validation/test splits with clear logic.
• Add documentation for privacy, data retention, and assumptions.
• Record a short walkthrough video.
• Map your project to real job descriptions.

Output: a portfolio project that looks like a small version of real robot data infrastructure or teleoperation review work.

Is this a software role or an operations role?

It can be either, depending on the title. Data & Teleoperation Engineer usually implies software, data systems, teleoperation tooling, robotics data pipelines, or infrastructure. Titles such as Robot Pilot, Data Creator, or Data Collection Operator are more hands-on and operations-heavy. Both belong in the same career family, but they should be labeled differently in job cards.

Is this a good entry point into humanoid robotics?

Yes, especially for people who are detail-oriented, hands-on, and willing to work close to real robots. Operator and data collection roles can be entry points. Engineering roles usually require stronger Python, data systems, robotics software, or backend skills.

Do I need machine learning experience?

Not always. ML knowledge helps because the data often feeds robot learning systems, but many roles focus on data infrastructure, teleoperation tools, logging, replay, quality checks, dashboards, and operations. For senior roles supporting embodied AI, ML dataset and evaluation experience becomes more important.

Do I need ROS 2?

ROS 2 is useful because it teaches robot data concepts such as topics, messages, bags, transforms, and replay. Some humanoid companies use internal systems, but ROS 2 knowledge transfers well.

Is teleoperation just remote-controlling a robot?

No. In humanoid robotics, teleoperation can be a data collection system, a safety fallback, an operator interface, a task teaching method, and a bridge between human skill and robot learning. Latency, calibration, ergonomics, task design, data quality, and safety all matter.

What portfolio project is best for this role?

A robot log ingestion and replay pipeline is the best first project. Add metadata, validation checks, a small review interface, and a quality report. That shows you understand the real job better than a generic dashboard.

Can a data analyst move into this role?

Yes, but the gap is robotics data. Learn Python, SQL, basic robotics logs, time-series data, video data, ROS 2 bags, metadata design, and quality checks. A normal BI dashboard is not enough by itself.

Can a robot operator move into this role?

Yes. The strongest path is to add technical evidence: Python scripts, log review, data quality reports, dashboards, SOP improvements, issue taxonomy, and basic ROS 2 or robot data skills. Operators who understand both the robot and the data loop can become very valuable.