Skip to main content

Basics

This page provides an overview of how Project Aria Machine Perception Services (MPS) output files are formatted. MPS provides derived data generated from Aria raw data (VRS files).

MPS File Structure​

MPS outputs use the following structure, in this example recording1.vrs was used to generate MPS.

    └── Example folder
        ├── mps_recording1_vrs
        │   ├── slam
        │   │   ├── closed_loop_trajectory.csv
        │   │   ├── online_calibration.jsonl
        │   │   ├── open_loop_trajectory.csv
        │   │   ├── semidense_observations.csv.gz
        │   │   ├── semidense_points.csv.gz
        │   │   └── summary.json
        │   ├── vrs_health_check.json
        └── recording1.vrs
  • mps_[name of VRS file]_vrs
    • Sibling directory where all the intermediate data and MPS output is saved
  • vrs_health_check.json
    • Output of the health check performed on your computer before data is uploaded
    • Contains information about data drops in all the sensor streams
  • slam folder
    • Contains outputs after running SLAM (Trajectory and Semi-Dense Point Cloud data)

Common terminologies​

graph_uid​

graph_uid is a unique identifier for the world coordinate frame. For all the 3D geometric instances like pose and points in the world frames (having _world in the suffix), when they have the same graph_uid, they are in the same coordinate frame.

tracking_timestamp_us​

tracking_timestamp_us's values are shaped by whether it is real world or synthetic data.

For real world data, tracking_timestamp_us provides the Device timestamps from your Aria glasses.

In simulation datasets, this will be the timestamp in the simulator.

  • This clock has arbitrary starting points, which are not synchronized between recording sessions or devices.
  • This clock is strictly monotonic, has stable clock speed, and is accurate in duration
    • If you want to compute the time duration between two timestamps (especially when touching dynamics, e.g. integrating acceleration to velocity over time), you should use this timestamp.

utc_timestamp_ns​

utc_timestamp_ns is the timestamp from Aria real-time clock (RTC). This time is synchronized to the cell phone time via the Aria Mobile Companion app to get UTC time at the beginning of the recording which is a rough estimate of the external standard clock.

  • This clock is not available in the simulation datasets.
  • This clock provides rough synchronization between sessions and devices.
  • This clock is not guaranteed to be monotonic, or have stable clock speed, due to synchronization with NTP. So do not compute duration between two UTC timestamps.

Operator summary​

The operator summary includes individual operator’s status and whether the operation was successful. There are three possible status flags:

  • SUCCESS: the operator successfully finished, without known issues.
  • WARNING: The operator finished, but internally it detected problem(s) that may affect results quality. The operator still outputs the results, but we don’t have confidence in the quality of the results, so consume the results with caution.
  • ERROR: the operator did not finish, finished with major error, or the quality of the results are too bad to be consumed. Results may or may not be generated, and any results should not be consumed.

The summary also provides information about processes as well as any warning or error messages available

Summary JSON output example:


    "SLAM": {
        "status": "SUCCESS",
        "info": [
            "Recording total time: 1104.00s; Trajectory total length: 155.42m",
            "Total Vision Translational Correction (mm): p50: 0.048; p99: 0.451",
            "Rotational Correction (deg): p50: 0.001; p99: 0.007"
        ],
        "warnings": [],
        "errors": []
    },
...