Skip to content

Adding Experiences

To test our system we need some experiences.

Prerequisites

Before creating experiences, you need to configure ReSim to access your experience data. See the Experience Data Sources guide for instructions on setting up access to:

Experience Locations

Each experience can have multiple locations. In many cases, a single location is sufficient, but it can be helpful to reference common assets, or store MCAPs recorded from different sources in different locations.

ReSim supports the following location prefixes:

Source Prefix Example
AWS S3 s3:// s3://my-bucket/experiences/exp_001/
Google Cloud Storage gs:// gs://my-bucket/experiences/exp_001/
Foxglove foxglove:// foxglove://rec_abc123def456
Local None /experiences/my-scenario/

For cloud storage locations (S3, GCS), each location should have a unique prefix containing the input files. Anything contained in that prefix will be treated as the same experience and downloaded into your tasks. We recommend using a prefix structure that represents your ReSim projects:

📂 .
├── 📂 project_a
│  └── 📂 experiences
│     └── 📂 experience_56ccce99
│        └── ⚙️ test_file
│
└── 📂 project_b
   └── 📂 experiences
      └── 📂 experience_679bef80
         └── ⚙️ test_file

How experience files are accessed

For cloud-based experiences (S3, GCS, Foxglove), files are copied into /tmp/resim/inputs/ when the experience build runs. If you use multiple locations, all files are copied directly into the inputs directory. Take care to ensure there are no file or directory name clashes at the root of the locations.

Avoiding file clashes with multiple locations

If your experience has two locations with the same directory structure:

s3://your-bucket/experience1      s3://your-bucket/experience2
└── mcaps                         └── mcaps
    └── log.mcap                      └── log.mcap

The mcaps/log.mcap file will clash - one will overwrite the other in /tmp/resim/inputs/.

Solution: Change the path or filename to ensure uniqueness. For example, use distinct directory names:

s3://your-bucket/experience1      s3://your-bucket/config
└── mcaps                         └── params.yaml
    └── log.mcap

This results in:

/tmp/resim/inputs/
├── mcaps/
│   └── log.mcap
└── params.yaml

Experience caching is enabled by default, so we only copy files that have been added or changed since the last run.

For local experiences, files remain at their original location and you access them using the path from /tmp/resim/test_config.json. See Local Experiences for details.

Experience Timeouts

Each experience has a timeout. This is the maximum amount of time that a build can run for a given experience. If the build does not finish running before the timeout is reached, it will be sent a SIGTERM and then a SIGKILL after a grace period.

The default timeout is 1 hour, but you can specify a different timeout when creating an experience.

Creating an experience

You can create new experiences like so:

resim experiences create \
    --project "my-project" \
    --name "Experience_56ccce99" \
    --description "In this experience, we test that our robot can navigate to the goal without colliding with any other agents." \
    --locations "s3://my-experiences-bucket/project_hal9000/experiences/experience_56ccce99/" \
    --systems "perception" "localization" \
    --tags "navigation" "collision-avoidance"

This command should return a message containing the UUID of the created experience, and it should now be browsable through the ReSim app.

The --systems flag enables you to specify any systems that this experience is compatible with. You can specify multiple systems by providing multiple system names or IDs.

The --tags flag allows you to apply tags to the experience for better organization and filtering. You can specify multiple tags by providing multiple tag names or IDs.

Optional flags are:

    --timeout "1h10m" # the maximum expected duration of the container \
    --environment-variable "SYSTEM_CONFIGURATION=Foo" # many allowed \
    --environment-variable "AN=other" \
    --profile "left-arm" # a docker compose profile to select the subset of compose services to run \

Examples with different sources

AWS S3:

resim experiences create \
    --project "my-project" \
    --name "S3 Experience" \
    --locations "s3://my-bucket/experiences/exp_001/"

Google Cloud Storage:

resim experiences create \
    --project "my-project" \
    --name "GCS Experience" \
    --locations "gs://my-gcs-bucket/experiences/exp_001/"

Foxglove:

resim experiences create \
    --project "my-project" \
    --name "Foxglove Experience" \
    --locations "foxglove://rec_abc123def456"

Local:

resim experiences create \
    --project "my-project" \
    --name "Local Experience" \
    --locations "/experiences/my-scenario/"

Updating an experience

You can update various aspects of an experience, including its systems and tags:

resim experiences update \
    --project "my-project" \
    --experience "Experience_56ccce99" \
    --name "Updated Experience Name" \
    --description "Updated description" \
    --location "s3://my-experiences-bucket/project_hal9000/experiences/updated_experience/" \
    --timeout "2h" \
    --systems "perception" "planning" \
    --tags "updated-tag" "new-functionality"

When updating systems or tags, the provided lists will replace the existing systems and tags associated with the experience.

You can also add or remove individual systems from an experience:

resim experiences add-system \
    --project "my-project" \
    --system "<system name>" \
    --experience "Experience_56ccce99"

resim experiences remove-system \
    --project "my-project" \
    --system "<system name>" \
    --experience "Experience_56ccce99"

Similarly you can add and remove individual tags:

resim experiences tag \
    --project "my-project" \
    --tag "<tag string>" \
    --experience "Experience_56ccce99"

resim experiences untag \
    --project "my-project" \
    --tag "<tag string>" \
    --experience "Experience_56ccce99"