GithubHelp home page GithubHelp logo

huggingface / lerobot Goto Github PK

View Code? Open in Web Editor NEW
3.1K 35.0 213.0 128.61 MB

๐Ÿค— LeRobot: State-of-the-art Machine Learning for Real-World Robotics in Pytorch

License: Apache License 2.0

Python 98.87% Makefile 0.65% Dockerfile 0.48%

lerobot's Introduction

LeRobot, Hugging Face Robotics Library

Tests Coverage Python versions License Status Version Examples Contributor Covenant Discord

State-of-the-art Machine Learning for real-world robotics


๐Ÿค— LeRobot aims to provide models, datasets, and tools for real-world robotics in PyTorch. The goal is to lower the barrier to entry to robotics so that everyone can contribute and benefit from sharing datasets and pretrained models.

๐Ÿค— LeRobot contains state-of-the-art approaches that have been shown to transfer to the real-world with a focus on imitation learning and reinforcement learning.

๐Ÿค— LeRobot already provides a set of pretrained models, datasets with human collected demonstrations, and simulation environments to get started without assembling a robot. In the coming weeks, the plan is to add more and more support for real-world robotics on the most affordable and capable robots out there.

๐Ÿค— LeRobot hosts pretrained models and datasets on this Hugging Face community page: huggingface.co/lerobot

Examples of pretrained models on simulation environments

ACT policy on ALOHA env TDMPC policy on SimXArm env Diffusion policy on PushT env
ACT policy on ALOHA env TDMPC policy on SimXArm env Diffusion policy on PushT env

Acknowledgment

  • Thanks to Tony Zaho, Zipeng Fu and colleagues for open sourcing ACT policy, ALOHA environments and datasets. Ours are adapted from ALOHA and Mobile ALOHA.
  • Thanks to Cheng Chi, Zhenjia Xu and colleagues for open sourcing Diffusion policy, Pusht environment and datasets, as well as UMI datasets. Ours are adapted from Diffusion Policy and UMI Gripper.
  • Thanks to Nicklas Hansen, Yunhai Feng and colleagues for open sourcing TDMPC policy, Simxarm environments and datasets. Ours are adapted from TDMPC and FOWM.
  • Thanks to Antonio Loquercio and Ashish Kumar for their early support.

Installation

Download our source code:

git clone https://github.com/huggingface/lerobot.git && cd lerobot

Create a virtual environment with Python 3.10 and activate it, e.g. with miniconda:

conda create -y -n lerobot python=3.10 && conda activate lerobot

Install ๐Ÿค— LeRobot:

pip install .

For simulations, ๐Ÿค— LeRobot comes with gymnasium environments that can be installed as extras:

For instance, to install ๐Ÿค— LeRobot with aloha and pusht, use:

pip install ".[aloha, pusht]"

To use Weights and Biases for experiment tracking, log in with

wandb login

Walkthrough

.
โ”œโ”€โ”€ examples             # contains demonstration examples, start here to learn about LeRobot
โ”œโ”€โ”€ lerobot
|   โ”œโ”€โ”€ configs          # contains hydra yaml files with all options that you can override in the command line
|   |   โ”œโ”€โ”€ default.yaml   # selected by default, it loads pusht environment and diffusion policy
|   |   โ”œโ”€โ”€ env            # various sim environments and their datasets: aloha.yaml, pusht.yaml, xarm.yaml
|   |   โ””โ”€โ”€ policy         # various policies: act.yaml, diffusion.yaml, tdmpc.yaml
|   โ”œโ”€โ”€ common           # contains classes and utilities
|   |   โ”œโ”€โ”€ datasets       # various datasets of human demonstrations: aloha, pusht, xarm
|   |   โ”œโ”€โ”€ envs           # various sim environments: aloha, pusht, xarm
|   |   โ”œโ”€โ”€ policies       # various policies: act, diffusion, tdmpc
|   |   โ””โ”€โ”€ utils          # various utilities
|   โ””โ”€โ”€ scripts          # contains functions to execute via command line
|       โ”œโ”€โ”€ eval.py                 # load policy and evaluate it on an environment
|       โ”œโ”€โ”€ train.py                # train a policy via imitation learning and/or reinforcement learning
|       โ”œโ”€โ”€ push_dataset_to_hub.py  # convert your dataset into LeRobot dataset format and upload it to the Hugging Face hub
|       โ””โ”€โ”€ visualize_dataset.py    # load a dataset and render its demonstrations
โ”œโ”€โ”€ outputs               # contains results of scripts execution: logs, videos, model checkpoints
โ””โ”€โ”€ tests                 # contains pytest utilities for continuous integration

Visualize datasets

Check out example 1 that illustrates how to use our dataset class which automatically download data from the Hugging Face hub.

You can also locally visualize episodes from a dataset by executing our script from the command line:

python lerobot/scripts/visualize_dataset.py \
    --repo-id lerobot/pusht \
    --episode-index 0

It will open rerun.io and display the camera streams, robot states and actions, like this:

battery-720p.mov

Our script can also visualize datasets stored on a distant server. See python lerobot/scripts/visualize_dataset.py --help for more instructions.

Evaluate a pretrained policy

Check out example 2 that illustrates how to download a pretrained policy from Hugging Face hub, and run an evaluation on its corresponding environment.

We also provide a more capable script to parallelize the evaluation over multiple environments during the same rollout. Here is an example with a pretrained model hosted on lerobot/diffusion_pusht:

python lerobot/scripts/eval.py \
    -p lerobot/diffusion_pusht \
    eval.n_episodes=10 \
    eval.batch_size=10

Note: After training your own policy, you can re-evaluate the checkpoints with:

python lerobot/scripts/eval.py \
    -p PATH/TO/TRAIN/OUTPUT/FOLDER

See python lerobot/scripts/eval.py --help for more instructions.

Train your own policy

Check out example 3 that illustrates how to start training a model.

In general, you can use our training script to easily train any policy. To use wandb for logging training and evaluation curves, make sure you ran wandb login. Here is an example of training the ACT policy on trajectories collected by humans on the Aloha simulation environment for the insertion task:

python lerobot/scripts/train.py \
    policy=act \
    env=aloha \
    env.task=AlohaInsertion-v0 \
    dataset_repo_id=lerobot/aloha_sim_insertion_human

The experiment directory is automatically generated and will show up in yellow in your terminal. It looks like outputs/train/2024-05-05/20-21-12_aloha_act_default. You can manually specify an experiment directory by adding this argument to the train.py python command:

    hydra.run.dir=your/new/experiment/dir

A link to the wandb logs for the run will also show up in yellow in your terminal. Here is an example of logs from wandb:

You can deactivate wandb by adding these arguments to the train.py python command:

    wandb.disable_artifact=true \
    wandb.enable=false

Note: For efficiency, during training every checkpoint is evaluated on a low number of episodes. After training, you may want to re-evaluate your best checkpoints on more episodes or change the evaluation settings. See python lerobot/scripts/eval.py --help for more instructions.

Contribute

If you would like to contribute to ๐Ÿค— LeRobot, please check out our contribution guide.

Add a new dataset

To add a dataset to the hub, you need to login using a write-access token, which can be generated from the Hugging Face settings:

huggingface-cli login --token ${HUGGINGFACE_TOKEN} --add-to-git-credential

Then move your dataset folder in data directory (e.g. data/aloha_ping_pong), and push your dataset to the hub with:

python lerobot/scripts/push_dataset_to_hub.py \
--data-dir data \
--dataset-id aloha_ping_ping \
--raw-format aloha_hdf5 \
--community-id lerobot

See python lerobot/scripts/push_dataset_to_hub.py --help for more instructions.

If your dataset format is not supported, implement your own in lerobot/common/datasets/push_dataset_to_hub/${raw_format}_format.py by copying examples like pusht_zarr, umi_zarr, aloha_hdf5, or xarm_pkl.

Add a pretrained policy

Once you have trained a policy you may upload it to the Hugging Face hub using a hub id that looks like ${hf_user}/${repo_name} (e.g. lerobot/diffusion_pusht).

You first need to find the checkpoint located inside your experiment directory (e.g. outputs/train/2024-05-05/20-21-12_aloha_act_default/checkpoints/002500). It should contain:

  • config.json: A serialized version of the policy configuration (following the policy's dataclass config).
  • model.safetensors: A set of torch.nn.Module parameters, saved in Hugging Face Safetensors format.
  • config.yaml: A consolidated Hydra training configuration containing the policy, environment, and dataset configs. The policy configuration should match config.json exactly. The environment config is useful for anyone who wants to evaluate your policy. The dataset config just serves as a paper trail for reproducibility.

To upload these to the hub, run the following:

huggingface-cli upload ${hf_user}/${repo_name} path/to/checkpoint/dir

See eval.py for an example of how other people may use your policy.

Improve your code with profiling

An example of a code snippet to profile the evaluation of a policy:

from torch.profiler import profile, record_function, ProfilerActivity

def trace_handler(prof):
    prof.export_chrome_trace(f"tmp/trace_schedule_{prof.step_num}.json")

with profile(
    activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
    schedule=torch.profiler.schedule(
        wait=2,
        warmup=2,
        active=3,
    ),
    on_trace_ready=trace_handler
) as prof:
    with record_function("eval_policy"):
        for i in range(num_episodes):
            prof.step()
            # insert code to profile, potentially whole body of eval_policy function

Citation

If you want, you can cite this work with:

@misc{cadene2024lerobot,
    author = {Cadene, Remi and Alibert, Simon and Soare, Alexander and Gallouedec, Quentin and Zouitine, Adil and Wolf, Thomas},
    title = {LeRobot: State-of-the-art Machine Learning for Real-World Robotics in Pytorch},
    howpublished = "\url{https://github.com/huggingface/lerobot}",
    year = {2024}
}

lerobot's People

Contributors

adilzouitine avatar alexander-soare avatar aliberts avatar ashisghosh avatar cadene avatar eltociear avatar kashif avatar kashyapakshay avatar qgallouedec avatar vmoens avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lerobot's Issues

Data loading is slow due to grabbing frames from huggingface dataset

I ran an experiment where I benchmarked times for running a dataloader on xarm_lift_medium_replay with batch size 256 and 0 workers.

8 batches takes ~ 15s. Here's the breakdown:

  • dataset.__getitem__: 14.707566491064426
  • load_previous_and_future_frames: 13.887129129978348
  • hf_dataset.select_columns(key)[data_ids][key]: 9.562710228981814

Reproducing aloha/act results

Even when evaluating a model trained on original aloha act codebase, the policy is shaky. We need to investigate.

eval_episode_0.4.mp4

Reproduce diffusion policy results on Pusht

FYI, I am able to run a pretrained model from the notebook of diffusion policy. I didnt calculate the success rate, but I think it is higher than what I have been able to achieve by training from scratch with LeRobot :/

See this PR: https://github.com/Cadene/lerobot/pull/13/files

Also I tried different size of network, with and without prioritized sampler, but success rate is not converging to ~70%. I am training on 1 gpu only for 12 hours. I am not sure I am using the correct hyperparameters. The config yaml I am using is still not super clean and need to be sanitized ^^

Image

Do we want to use `transformers`?

I'd really go against establishing transformers as a dependency of lerobot and importing their whole library just to use the PretrainedConfig (or even other components). I think in this case it's very overkill and wouldn't necessarily fit our needs right now. The class is ~1000 lines of code - which we can copy into our lib anyway - and looks way more mature and feature-rich than what โ€” IMO โ€” we need and have with the rest of our code base.

Copying code is even part of Transformers' philosophy โ€” which we do copy.

Originally posted by @aliberts in #101 (comment)

Handle torchvision deprecation warning

/home/alexander/anaconda3/envs/lerobot/lib/python3.10/site-packages/torchvision/models/_utils.py:208: UserWarning: The parameter 'pretrained' is deprecated since 0.13 and may be removed in the future, please use 'weights' instead.
  warnings.warn(
/home/alexander/anaconda3/envs/lerobot/lib/python3.10/site-packages/torchvision/models/_utils.py:223: UserWarning: Arguments other than a weight enum or `None` for 'weights' are deprecated since 0.13 and may be removed in the future. The current behavior is equivalent to passing `weights=ResNet18_Weights.IMAGENET1K_V1`. You can also use `weights=ResNet18_Weights.DEFAULT` to get the most up-to-date weights.
  warnings.warn(msg)

Wrong normalization of the images

We compute stats on raw data. For instance:

stats["observation", "image", "top", "max"].max()
tensor(255.)

However, in lerobot/common/datasets/factory.py we apply a first transform to modify the pixel range of images from [0,255] to [0,1]:

transforms = [Prod(in_keys=img_keys, prod=1 / 255)]

then we apply our stats which expect images to be in the range [0,255].

This bug only affects tdmpc which uses image keys during its normalization:

        in_keys = [("observation", "state"), ("action")]

        if cfg.policy.name == "tdmpc":
            # TODO(rcadene): we add img_keys to the keys to normalize for tdmpc only, since diffusion and act policies normalize the image inside the model for now
            in_keys += img_keys
            # TODO(racdene): since we use next observations in tdmpc, we also add them to the normalization. We are wasting a bit of compute on this for now.
            in_keys += [("next", *key) for key in img_keys]
            in_keys.append(("next", "observation", "state"))

cc @alexander-soare @aliberts @qgallouedec

Diffusion policy can't be applied to other tasks๏ผŸ

System Info

lerobot

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

python lerobot/scripts/train.py policy=diffusion env=aloha env.task=AlohaInsertion-v0 dataset_repo_id=lerobot/aloha_sim_insertion_human

Expected behavior

KeyError: 'observation.image'. I want to apply the diffusion policy to other tasks except 'pusht', but I found that the key in diffusion config '[observation.image]' doesn't match the file name (some is observation.images.top) of the video datasets. So how can I make it available for other tasks?

The LeRobot TODO hyperlink in CONTRIBUTING.md is not working

System Info

The "LeRobot TODO" hyperlink in the contribution guide (lerobot/CONTRIBUTING.md) redirects to a 404 page.
The hyperlink currently redirects to: https://github.com/orgs/huggingface/projects/46

Reproduction

  1. Click the "LeRobot TODO" hyperlink in the contribution guide (lerobot/CONTRIBUTING.md)

Expected behavior

The hyperlink should ideally redirect to a page with a list of to-do tasks.

Installation - [Errno 28] No space left on device (disk space error)

I'm posting this here in case anyone finds him/herself in that situation.

During the install process, due to the large size of some dependencies (namely torch/cuda) and depending on the partitioning of your system, you may encounter a disk space error:

[Errno 28] No space left on device

One workaround for this is to change your tmp/ directory to a location where you have enough disk space, e.g.

mkdir ~/tmp
export TMPDIR='~/tmp'

Saving checkpoint with a dataset from the hub failed when WandB is activated

System Info

lerobot main

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

run python lerobot/scripts/train.py policy=act env=aloha env.task=AlohaInsertion-v0 training.save_freq=10000 dataset_repo_id=lerobot/aloha_sim_insertion_h uman

error:

INFO 2024-05-08 16:05:43 ts/train.py:357 Checkpoint policy after step 10000
Error executing job with overrides: ['policy=act', 'env=aloha', 'env.task=AlohaInsertion-v0', 'training.save_freq=10000', 'dataset_repo_id=lerobot/aloha_sim_insertion_human']
Traceback (most recent call last):
  File "/home/thomwolf/Documents/Github/lerobot/lerobot/scripts/train.py", line 109, in train_cli
    train(
  File "/home/thomwolf/Documents/Github/lerobot/lerobot/scripts/train.py", line 398, in train
    evaluate_and_checkpoint_if_needed(step + 1)
  File "/home/thomwolf/Documents/Github/lerobot/lerobot/scripts/train.py", line 360, in evaluate_and_checkpoint_if_needed
    logger.save_model(
  File "/home/thomwolf/miniconda3/envs/lerobot/lib/python3.10/site-packages/lerobot/common/logger.py", line 86, in save_model
    artifact = self._wandb.Artifact(
  File "/home/thomwolf/miniconda3/envs/lerobot/lib/python3.10/site-packages/wandb/sdk/artifacts/artifact.py", line 132, in __init__
    raise ValueError(
ValueError: Artifact name may only contain alphanumeric characters, dashes, underscores, and dots. Invalid name: policy_act-dataset_lerobot/aloha_sim_insertion_human-env_aloha-seed_1000-1000-010000

Set the environment variable HYDRA_FULL_ERROR=1 for a complete stack trace.

Expected behavior

No failing.

Need to remove the / in datasets name

Default ACT config causes model init failure

from lerobot.common.policies.act.configuration_act import ActionChunkingTransformerConfig
from lerobot.common.policies.act.modeling_act import ActionChunkingTransformerPolicy

configuration = ActionChunkingTransformerConfig()
model = ActionChunkingTransformerPolicy(configuration)
Traceback (most recent call last):
  File "/Users/quentingallouedec/lerobot/p.py", line 6, in <module>
    model = ActionChunkingTransformerPolicy(configuration)
  File "/Users/quentingallouedec/lerobot/lerobot/common/policies/act/modeling_act.py", line 75, in __init__
    self.normalize_inputs = Normalize(cfg.input_shapes, cfg.normalize_input_modes, dataset_stats)
  File "/Users/quentingallouedec/lerobot/lerobot/common/policies/normalize.py", line 101, in __init__
    stats_buffers = create_stats_buffers(shapes, modes, stats)
  File "/Users/quentingallouedec/lerobot/lerobot/common/policies/normalize.py", line 31, in create_stats_buffers
    shape = tuple(shapes[key])
KeyError: 'observation.image'

AttributeError: module 'rerun' has no attribute 'init' when running the "Visualize datasets" line specified in README

System Info

- `lerobot` version: 0.1.0
- Platform: Linux-6.5.0-28-generic-x86_64-with-glibc2.35
- Python version: 3.10.14
- Huggingface_hub version: 0.23.0
- Numpy version: 1.23.1
- PyTorch version (GPU?): 2.3.0+cu121 (True)
- Cuda version: 12010
- Using GPU in script?: No
- Using distributed or parallel set-up in script?: No

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

  1. Run the "Visualize datasets" line specified in README.
python lerobot/scripts/visualize_dataset.py \
    --repo-id lerobot/pusht \
    --episode-index 0

It gives the following error:

Fetching 222 files: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 222/222 [00:00<00:00, 377589.41it/s]
Traceback (most recent call last):
  File "/home/ubuntu/lerobot/lerobot/scripts/visualize_dataset.py", line 245, in <module>
    main()
  File "/home/ubuntu/lerobot/lerobot/scripts/visualize_dataset.py", line 241, in main
    visualize_dataset(**vars(args))
  File "/home/ubuntu/lerobot/lerobot/scripts/visualize_dataset.py", line 117, in visualize_dataset
    rr.init(f"{repo_id}/episode_{episode_index}", spawn=spawn_local_viewer)
AttributeError: module 'rerun' has no attribute 'init'

Expected behavior

According to README, it will open rerun.io and display the camera streams, robot states and actions.

Can not load a dataset from a Hugging Face repository

System Info

lerobot

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

can not load datasets from HF when doing: python lerobot/scripts/visualize_dataset.py --repo-id lerobot/pusht --episode-index 0, or python -u example/1_load_lerobot_dataset.py
error: dataset = LeRobotDataset(repo_id)
ConnectionError: Couldn't reach 'lerobot/pusht' on the Hub (ConnectionError)

Expected behavior

help me download the datasets from HF

Installation fails (egl_probe)

System Info

- `lerobot` version: unknown
- Platform: macOS-14.4.1-x86_64-i386-64bit
- Python version: 3.10.14
- Huggingface_hub version: 0.22.2
- Numpy version: 1.26.4
- PyTorch version (GPU?): 2.2.2 (False)
- Cuda version: N/A

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

python -m pip install .

Logs

  Building wheel for egl_probe (setup.py) ... error
  error: subprocess-exited-with-error
  
  ร— python setup.py bdist_wheel did not run successfully.
  โ”‚ exit code: 1
  โ•ฐโ”€> [394 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.macosx-10.9-x86_64-cpython-310
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      copying egl_probe/get_available_devices.py -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      copying egl_probe/__init__.py -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      running egg_info
      writing egl_probe.egg-info/PKG-INFO
      writing dependency_links to egl_probe.egg-info/dependency_links.txt
      writing top-level names to egl_probe.egg-info/top_level.txt
      reading manifest file 'egl_probe.egg-info/SOURCES.txt'
      reading manifest template 'MANIFEST.in'
      adding license file 'LICENSE'
      writing manifest file 'egl_probe.egg-info/SOURCES.txt'
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad' to be distributed and are
              already explicitly excluding 'egl_probe.glad' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad.EGL' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad.EGL' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad.EGL' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad.EGL' to be distributed and are
              already explicitly excluding 'egl_probe.glad.EGL' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad.KHR' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad.KHR' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad.KHR' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad.KHR' to be distributed and are
              already explicitly excluding 'egl_probe.glad.KHR' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad.X11' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad.X11' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad.X11' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad.X11' to be distributed and are
              already explicitly excluding 'egl_probe.glad.X11' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad.X11.extensions' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad.X11.extensions' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad.X11.extensions' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad.X11.extensions' to be distributed and are
              already explicitly excluding 'egl_probe.glad.X11.extensions' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      /usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/command/build_py.py:207: _Warning: Package 'egl_probe.glad.glad' is absent from the `packages` configuration.
      !!
      
              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'egl_probe.glad.glad' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.
      
              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'egl_probe.glad.glad' is explicitly added
              to the `packages` configuration field.
      
              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).
      
              You can read more about "package discovery" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html
      
              If you don't want 'egl_probe.glad.glad' to be distributed and are
              already explicitly excluding 'egl_probe.glad.glad' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.
      
              You can read more about "package data files" on setuptools documentation page:
      
              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      
      
              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************
      
      !!
        check.warn(importable)
      copying egl_probe/CMakeLists.txt -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      copying egl_probe/query_devices.cpp -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      copying egl_probe/test_device.cpp -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad
      copying egl_probe/glad/egl.cpp -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad
      copying egl_probe/glad/gl.cpp -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad
      copying egl_probe/glad/glx_dyn.cpp -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad
      copying egl_probe/glad/linmath.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/EGL
      copying egl_probe/glad/EGL/eglplatform.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/EGL
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/KHR
      copying egl_probe/glad/KHR/khrplatform.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/KHR
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/X.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/XKBlib.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xatom.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xfuncproto.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xfuncs.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xlib.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/XlibConf.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xlibint.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xmd.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xosdefs.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xproto.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xprotostr.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/Xutil.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/cursorfont.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/keysym.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      copying egl_probe/glad/X11/keysymdef.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/XKB.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/XKBstr.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/XShm.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/Xext.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/extutil.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/shape.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/shapeconst.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      copying egl_probe/glad/X11/extensions/shm.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/X11/extensions
      creating build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/glad
      copying egl_probe/glad/glad/egl.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/glad
      copying egl_probe/glad/glad/gl.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/glad
      copying egl_probe/glad/glad/glx.h -> build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/glad/glad
      running build_ext
      CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.
      
        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.
      
      
      -- The C compiler identification is Clang 17.0.6
      -- The CXX compiler identification is Clang 17.0.6
      -- Detecting C compiler ABI info
      -- Detecting C compiler ABI info - done
      -- Check for working C compiler: /opt/homebrew/opt/llvm/bin/clang - skipped
      -- Detecting C compile features
      -- Detecting C compile features - done
      -- Detecting CXX compiler ABI info
      -- Detecting CXX compiler ABI info - done
      -- Check for working CXX compiler: /opt/homebrew/opt/llvm/bin/clang++ - skipped
      -- Detecting CXX compile features
      -- Detecting CXX compile features - done
      -- Configuring done (4.1s)
      -- Generating done (0.0s)
      -- Build files have been written to: /private/var/folders/z7/y_b89yb93892c6g3g2x8wk_h0000gn/T/pip-install-lz5xiial/egl-probe_30ad3afb30db4508b76526bc03c673a2/build/lib.macosx-10.9-x86_64-cpython-310/egl_probe/build
      [ 12%] Building CXX object CMakeFiles/query_devices.dir/glad/gl.cpp.o
      [ 25%] Building CXX object CMakeFiles/test_device.dir/glad/gl.cpp.o
      [ 37%] Building CXX object CMakeFiles/query_devices.dir/query_devices.cpp.o
      [ 50%] Building CXX object CMakeFiles/query_devices.dir/glad/egl.cpp.o
      [ 62%] Building CXX object CMakeFiles/test_device.dir/glad/egl.cpp.o
      [ 75%] Building CXX object CMakeFiles/test_device.dir/test_device.cpp.o
      [100%] Linking CXX executable query_devices
      [100%] Linking CXX executable test_device
      ld: warning: ignoring file '/opt/homebrew/Cellar/llvm/17.0.6_1/lib/libunwind.1.0.dylib': found architecture 'arm64', required architecture 'x86_64'
      ld: warning: ignoring file '/opt/homebrew/Cellar/llvm/17.0.6_1/lib/libunwind.1.0.dylib': found architecture 'arm64', required architecture 'x86_64'
      Undefined symbols for architecture x86_64:
        "__Unwind_Resume", referenced from:
            _main in test_device.cpp.o
      ld: symbol(s) not found for architecture x86_64
      Undefined symbols for architecture x86_64:
        "__Unwind_Resume", referenced from:
            _main in query_devices.cpp.o
      ld: symbol(s) not found for architecture x86_64
      clang++: error: linker command failed with exit code 1 (use -v to see invocation)
      clang++: error: linker command failed with exit code 1 (use -v to see invocation)
      make[2]: *** [test_device] Error 1
      make[2]: *** [query_devices] Error 1
      make[1]: *** [CMakeFiles/test_device.dir/all] Error 2
      make[1]: *** Waiting for unfinished jobs....
      make[1]: *** [CMakeFiles/query_devices.dir/all] Error 2
      make: *** [all] Error 2
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/private/var/folders/z7/y_b89yb93892c6g3g2x8wk_h0000gn/T/pip-install-lz5xiial/egl-probe_30ad3afb30db4508b76526bc03c673a2/setup.py", line 50, in <module>
          setup(
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/__init__.py", line 104, in setup
          return distutils.core.setup(**attrs)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 184, in setup
          return run_commands(dist)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 200, in run_commands
          dist.run_commands()
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 969, in run_commands
          self.run_command(cmd)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/dist.py", line 967, in run_command
          super().run_command(command)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
          cmd_obj.run()
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/wheel/bdist_wheel.py", line 368, in run
          self.run_command("build")
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/cmd.py", line 316, in run_command
          self.distribution.run_command(command)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/dist.py", line 967, in run_command
          super().run_command(command)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
          cmd_obj.run()
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/command/build.py", line 132, in run
          self.run_command(cmd_name)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/cmd.py", line 316, in run_command
          self.distribution.run_command(command)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/dist.py", line 967, in run_command
          super().run_command(command)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
          cmd_obj.run()
        File "/private/var/folders/z7/y_b89yb93892c6g3g2x8wk_h0000gn/T/pip-install-lz5xiial/egl-probe_30ad3afb30db4508b76526bc03c673a2/setup.py", line 26, in run
          self.build_extension(ext)
        File "/private/var/folders/z7/y_b89yb93892c6g3g2x8wk_h0000gn/T/pip-install-lz5xiial/egl-probe_30ad3afb30db4508b76526bc03c673a2/setup.py", line 38, in build_extension
          subprocess.check_call("cmake ..; make -j", cwd=build_dir, shell=True)
        File "/usr/local/Caskroom/miniforge/base/envs/lerobot/lib/python3.10/subprocess.py", line 369, in check_call
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command 'cmake ..; make -j' returned non-zero exit status 2.
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for egl_probe
  Running setup.py clean for egl_probe
  Building wheel for asciitree (setup.py) ... done
  Created wheel for asciitree: filename=asciitree-0.3.3-py3-none-any.whl size=5034 sha256=59ff1abdaf119a83b7490140a16ab0b5f4deb4549a6543f1cdb70223ad12d47b
  Stored in directory: /private/var/folders/z7/y_b89yb93892c6g3g2x8wk_h0000gn/T/pip-ephem-wheel-cache-kz5egi7z/wheels/7f/4e/be/1171b40f43b918087657ec57cf3b81fa1a2e027d8755baa184
Successfully built lerobot robomimic antlr4-python3-runtime asciitree
Failed to build egl_probe
ERROR: Could not build wheels for egl_probe, which is required to install pyproject.toml-based projects

Expected behavior

No response

General support for LR scheduler and optimizer

          Okay, I see why you need these "hacks". Ideally what we want here is:
  1. General support for LR scheduling. Therefore the lr scheduler params should move out of the policy config.
  2. Policies have an optional get_optimizer_param_dicts. Might need more thinking through for the general design.
    Maybe we can keep these ideas out of this PR though. But what are your thoughts?

Originally posted by @alexander-soare in #99 (comment)

python3.10 how to install rerun-sdk

System Info

ubuntu18.04
python3.10


ERROR: Could not find a version that satisfies the requirement rerun-sdk>=0.15.1 (from lerobot) (from versions: none)
ERROR: No matching distribution found for rerun-sdk>=0.15.1

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

pip install .

ERROR: Could not find a version that satisfies the requirement rerun-sdk>=0.15.1 (from lerobot) (from versions: none)
ERROR: No matching distribution found for rerun-sdk>=0.15.1

Expected behavior

I want to know how to solve this problem

"A question about virtual environments"

System Info

python 3.10

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

Thank you very much for the excellent work you have done, which has facilitated my learning. I have a question. If I collect data using a real robot and am unable to create an env, what should I do? I have already converted my collected data into the Lerobot format, but during training and testing, I need to make_env an env for testing. How can I resolve this? Does this mean that this library can currently only be used in situations where there is already a virtual environment? Thank you very much for your response and advice.
I'm sorry I couldn't find a topic related to the inquiry, so I had to ask in the form of a bug report.

Expected behavior

"I want to use this library to train on real data that I collected myself."

Torchrl update breaks code

Due to changes in the torchrl api, running train.py with the current torchrl main will throw the following exception:

INFO 2024-03-16 18:21:20 ts/train.py:182 Start offline training on a fixed dataset
Error executing job with overrides: ['env=pusht', 'offline_steps=10', 'wandb.enable=false', 'device=cuda']
Traceback (most recent call last):
  File "/home/simon/projects/lerobot/lerobot/scripts/train.py", line 21, in train_cli
    train(
  File "/home/simon/projects/lerobot/lerobot/scripts/train.py", line 184, in train
    train_info = policy.update(offline_buffer, step)
  File "/home/simon/projects/lerobot/lerobot/common/policies/diffusion/policy.py", line 158, in update
    batch = replay_buffer.sample(batch_size)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/replay_buffers.py", line 1096, in sample
    data, info = super().sample(batch_size, return_info=True)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/replay_buffers.py", line 599, in sample
    ret = self._prefetch_queue.popleft().result()
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/concurrent/futures/_base.py", line 458, in result
    return self.__get_result()
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
    raise self._exception
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/utils.py", line 50, in decorated_fun
    output = fun(self, *args, **kwargs)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/replay_buffers.py", line 1129, in _sample
    index, info = self._sampler.sample(self._storage, batch_size)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/samplers.py", line 1499, in sample
    start_idx, stop_idx, lengths = self._get_stop_and_length(storage)
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/samplers.py", line 910, in _get_stop_and_length
    vals = self._find_start_stop_traj(
  File "/home/simon/miniconda3/envs/lerobot/lib/python3.10/site-packages/torchrl/data/replay_buffers/samplers.py", line 855, in _find_start_stop_traj
    start_idx_replace[m1] = start_idx[m2]
IndexError: The shape of the mask [0] at index 0 does not match the shape of the indexed tensor [1, 1] at index 0

Complete command run:

DATA_DIR="tests/data" python lerobot/scripts/train.py \
    hydra.job.name=pusht \ 
    env=pusht \
    offline_steps=10 \
    wandb.enable=false \
    device=cuda

Keep the last frame when preparing datasets

Currently, in _download_and_preproc_obsolete for PushT and Aloha, we are dropping the last frame meaning that we potentially don't keep the action that leads to the success condition. Also, we prepared the initial buffer as all copies of the first frame td_data = ep_td[0].expand(total_frames).memmap_like(self.root / f"{self.dataset_id}"), then populated the buffer with the frames: td_data[idxtd : idxtd + len(ep_td)] = ep_td, meaning that the end of the buffer would have a bunch of nonsensical copies of the first frame.

See this PR #50

running `python lerobot/scripts/eval.py \ -p lerobot/diffusion_pusht \ eval.n_episodes=10 \ eval.batch_size=10` on apple silicon Mac

System Info

- `lerobot` version: 0.1.0
- Platform: macOS-14.4.1-arm64-arm-64bit
- Python version: 3.10.14
- Huggingface_hub version: 0.21.4
- Numpy version: 1.26.4
- PyTorch version (GPU?): 2.3.0 (False)
- Cuda version: N/A
- Using GPU in script?: not sure, running the unmodified out of the box script
- Using distributed or parallel set-up in script?: not sure

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

run python lerobot/scripts/eval.py \ -p lerobot/diffusion_pusht \ eval.n_episodes=10 \ eval.batch_size=10 on apple silicon Mac gives following error at the end:

(lerobot) Rams-MBP:lerobot ramkumarkoppu$ python lerobot/scripts/eval.py \

-p lerobot/diffusion_pusht \
eval.n_episodes=10 \
eval.batch_size=10

README.md: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 2.56k/2.56k [00:00<00:00, 20.2MB/s]
eval_avg_max_reward.csv: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 537/537 [00:00<00:00, 6.24MB/s]
eval_pc_success.csv: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 236/236 [00:00<00:00, 2.15MB/s]
.gitattributes: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 1.52k/1.52k [00:00<00:00, 14.6MB/s]
config.json: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 1.01k/1.01k [00:00<00:00, 11.3MB/s]
config.yaml: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 2.36k/2.36k [00:00<00:00, 29.1MB/s]
demo.gif: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 601k/601k [00:00<00:00, 5.45MB/s]
train_loss.csv: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 20.7k/20.7k [00:00<00:00, 59.2MB/s]
training_curves.png: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 28.6k/28.6k [00:00<00:00, 4.40MB/s]
eval_info.json: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 83.9k/83.9k [00:00<00:00, 896kB/s]
model.safetensors: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 1.05G/1.05G [00:59<00:00, 17.8MB/s]
Fetching 11 files: 100%|โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆ| 11/11 [00:59<00:00, 5.44s/it]
Traceback (most recent call last):โ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–ˆโ–Š| 1.05G/1.05G [00:58<00:00, 18.2MB/s]
File "/Users/ramkumarkoppu/GIT/lerobot/lerobot/scripts/eval.py", line 604, in
eval(pretrained_policy_path=pretrained_policy_path, config_overrides=args.overrides)
File "/Users/ramkumarkoppu/GIT/lerobot/lerobot/scripts/eval.py", line 508, in eval
get_safe_torch_device(hydra_cfg.device, log=True)
File "/Users/ramkumarkoppu/miniconda3/envs/lerobot/lib/python3.10/site-packages/lerobot/common/utils/utils.py", line 17, in get_safe_torch_device
assert torch.cuda.is_available()
AssertionError

Expected behavior

For apple silicon Mac, script should not expect cuda instead use mps if it can

Fix reward aggregation for multi-step policies

Problem

Currently there is an issue with the way PushtEnv reports on rewards and success.

PushtEnv._step executes multiple steps in the underlying PushTenv (note the capitalized T as different from PushtEnv: this is the ported DP code). While doing so it sums the rewards, and reports on the last value of done. The consequences of this are:

  1. The reported reward is the sum of multiple steps of reward. The "reward" here is meant to be intersection with the target patch, and has no practical interpretation when summed over multiple steps. We could take the mean instead of the sum, but then we wouldn't be reporting the correct final metrics like "avg_max_reward" (see eval.py).
  2. Perhaps the done condition is met in one of the steps, but not on the final step. A simulation which should have finished, doesn't.

copy-paste of PushtEnv._step for reference:

def _step(self, tensordict: TensorDict):
    td = tensordict
    action = td["action"].numpy()
    # step expects shape=(4,) so we pad if necessary
    # TODO(rcadene): add info["is_success"] and info["success"] ?
    sum_reward = 0

    if action.ndim == 1:
        action = einops.repeat(action, "c -> t c", t=self.frame_skip)
    else:
        if self.frame_skip > 1:
            raise NotImplementedError()

    num_action_steps = action.shape[0]
    for i in range(num_action_steps):
        raw_obs, reward, done, info = self._env.step(action[i])
        sum_reward += reward

        obs = self._format_raw_obs(raw_obs)

        if self.num_prev_obs > 0:
            stacked_obs = {}
            if "image" in obs:
                self._prev_obs_image_queue.append(obs["image"])
                stacked_obs["image"] = torch.stack(list(self._prev_obs_image_queue))
            if "state" in obs:
                self._prev_obs_state_queue.append(obs["state"])
                stacked_obs["state"] = torch.stack(list(self._prev_obs_state_queue))
            obs = stacked_obs

        self.call_rendering_hooks()

    td = TensorDict(
        {
            "observation": TensorDict(obs, batch_size=[]),
            "reward": torch.tensor([sum_reward], dtype=torch.float32),
            # succes and done are true when coverage > self.success_threshold in env
            "done": torch.tensor([done], dtype=torch.bool),
            "success": torch.tensor([done], dtype=torch.bool),
        },
        batch_size=[],
    )
    return td

Quick and dirty fix

We need to properly evaluate the reward metric during training. A quick fix would be to take the summed reward and divide it by the number of steps that were taken to get a mean over that sequence of actions. This would be technically incorrect but close.

Proposed "proper" fix

There are other ways of going about this but I might suggest absorbing n_action_steps logic into the policy's forward method. It is then the policy's responsibility to keep track of the step number it is up to. For example, consider n_action_steps == 8. EnvBase.rollout calls policy(tensordict) in its main loop. Here's what would happen in each step:

policy(tensordict)  # 0. inference is done and an action trajectory `actions` is produced. `action_ix = 0; return self.actions[self.action_ix]`
policy(tensordict)  # 1. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 2. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 3. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 4. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 5. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 6. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 7. `action_ix += 1; return self.actions[self.action_ix]`
policy(tensordict)  # 0. because `action_ix+1 == n_action_steps` we do inference again and reset `action_ix = 0`; `return self.actions[action_ix]`

We can have a policy.reset() to clear actions and action_ix.

Alternative fix

If we don't feel comfortable with giving the policy an action trajectory state, we might consider making a subclass of torchrl.EnvBase and overriding rollout to gracefully handle multistep policies. This will do the same as PushtEnv._step but it won't aggregate the per-step metrics. The other advantage of this is that it handles multi-step policies universally.

Incorrect shape for vae_encoder_input for ACT

System Info

lerobot main

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

import lerobot
from lerobot.common.datasets.lerobot_dataset import LeRobotDataset

from lerobot.common.policies.normalize import Normalize, Unnormalize
from lerobot.common.datasets.utils import cycle

from lerobot.common.policies.act.configuration_act import ACTConfig
from lerobot.common.policies.act.modeling_act import ACTPolicy

import torch
import multiprocessing as mp

from aim import Run

config = ACTConfig()

delta_timestamps = {
    "observation.images.top": [0],
    "observation.state": [0],
    "action": [t / 50 for t in range(config.chunk_size)],  # this dataset was recorded at 50Hz
}
dataset = LeRobotDataset('lerobot/aloha_sim_transfer_cube_scripted', split='train', delta_timestamps=delta_timestamps)

dataloader = torch.utils.data.DataLoader(
    dataset,
    num_workers=mp.cpu_count()-1,
    batch_size=8,
    shuffle=True,
    pin_memory=True,
    drop_last=True,
)

policy = ACTPolicy(config=config, dataset_stats=dataset.stats)

for batch in dataloader:
    output_dict = policy.forward(batch)

Expected behavior

Error:

File ~/workspace/lerobot/lerobot/common/policies/act/modeling_act.py:300, in ACT.forward(self, batch)
    296 robot_state_embed = self.vae_encoder_robot_state_input_proj(batch["observation.state"]).unsqueeze(
    297     1
    298 )  # (B, 1, D)
    299 action_embed = self.vae_encoder_action_input_proj(batch["action"])  # (B, S, D)
--> 300 vae_encoder_input = torch.cat([cls_embed, robot_state_embed, action_embed], axis=1)  # (B, S+2, D)
    302 # Prepare fixed positional embedding.
    303 # Note: detach() shouldn't be necessary but leaving it the same as the original code just in case.
    304 pos_embed = self.vae_encoder_pos_enc.clone().detach()  # (1, S+2, D)

RuntimeError: Tensors must have same number of dimensions: got 3 and 4

Here are the shapes:

ipdb>  cls_embed.shape
torch.Size([8, 1, 512])
ipdb>  robot_state_embed.shape
torch.Size([8, 1, 1, 512])
ipdb>  action_embed.shape
torch.Size([8, 100, 512])

That is a trivial fix here but not sure how it is possible that I am getting this error message? I just saw some commits related to ACT merged into main -- I suppose people would be seeing this issue as well?

Anyhow -- getting late, will call it a day. Would appreciate if another set of eyes could take a look at this and confirm whether this indeed is a genuine issue.

If it is -- might be good to add an example for training ACT. Can work on adding one if there would be interest. Or maybe just a unit test? That might be even better as I suppose there is not much new that an example would introduce on top of what's already in the training example with DiffusionPolicy (just different delta_timestamps and normalization, maybe having normalization is reason enough for another example?).

Tests are broken on main as of 89c6be8

System Info

`main` / 89c6be8

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

Run

DATA_DIR="tests/data" python -m pytest -sv ./tests

Output:

================================================================= FAILURES =================================================================
_________________________________________ test_backward_compatibility[aloha-act-extra_overrides2] __________________________________________

env_name = 'aloha', policy_name = 'act', extra_overrides = ['policy.n_action_steps=10']

    @pytest.mark.parametrize(
        "env_name, policy_name, extra_overrides",
        [
            ("xarm", "tdmpc", []),
            (
                "pusht",
                "diffusion",
                ["policy.n_action_steps=8", "policy.num_inference_steps=10", "policy.down_dims=[128, 256, 512]"],
            ),
            ("aloha", "act", ["policy.n_action_steps=10"]),
        ],
    )
    # As artifacts have been generated on an x86_64 kernel, this test won't
    # pass if it's run on another platform due to floating point errors
    @require_x86_64_kernel
    def test_backward_compatibility(env_name, policy_name, extra_overrides):
        """
        NOTE: If this test does not pass, and you have intentionally changed something in the policy:
            1. Inspect the differences in policy outputs and make sure you can account for them. Your PR should
               include a report on what changed and how that affected the outputs.
            2. Go to the `if __name__ == "__main__"` block of `test/scripts/save_policy_to_safetensors.py` and
               add the policies you want to update the test artifacts for.
            3. Run `python test/scripts/save_policy_to_safetensors.py`. The test artifact should be updated.
            4. Check that this test now passes.
            5. Remember to restore `test/scripts/save_policy_to_safetensors.py` to its original state.
            6. Remember to stage and commit the resulting changes to `tests/data`.
        """
        env_policy_dir = Path("tests/data/save_policy_to_safetensors") / f"{env_name}_{policy_name}"
        saved_output_dict = load_file(env_policy_dir / "output_dict.safetensors")
        saved_grad_stats = load_file(env_policy_dir / "grad_stats.safetensors")
        saved_param_stats = load_file(env_policy_dir / "param_stats.safetensors")
        saved_actions = load_file(env_policy_dir / "actions.safetensors")
    
        output_dict, grad_stats, param_stats, actions = get_policy_stats(env_name, policy_name, extra_overrides)
    
        for key in saved_output_dict:
            assert torch.isclose(output_dict[key], saved_output_dict[key], rtol=0.1, atol=1e-7).all()
        for key in saved_grad_stats:
>           assert torch.isclose(grad_stats[key], saved_grad_stats[key], rtol=0.1, atol=1e-7).all()
E           assert tensor(False)
E            +  where tensor(False) = <built-in method all of Tensor object at 0x7d36a6cda660>()
E            +    where <built-in method all of Tensor object at 0x7d36a6cda660> = tensor(False).all
E            +      where tensor(False) = <built-in method isclose of type object at 0x7d3855386760>(tensor(0.0026), tensor(0.0005), rtol=0.1, atol=1e-07)
E            +        where <built-in method isclose of type object at 0x7d3855386760> = torch.isclose

tests/test_policies.py:274: AssertionError
========================================================= short test summary info ==========================================================
FAILED tests/test_policies.py::test_backward_compatibility[aloha-act-extra_overrides2] - assert tensor(False)
================================================ 1 failed, 38 passed, 26 skipped in 14.17s =================================================

Expected behavior

All tests to pass

aloha_static_thread_velcro videos are actually aloha_static_tape videos

Thank you for the great work!

I was looking through the dataset and it seems that videos in aloha_static_thread_velcro dataset are actually aloha_static_tape videos.

Also, most of the dataset which is supposed to be 50 episodes (checked the google drive) contain only 49 episodes (missing index 49).

Visualization during training

Thank you for this great framework. I tried to train a model following the example:

python lerobot/scripts/train.py policy=act env=aloha env.task=AlohaInsertion-v0 dataset_repo_id=lerobot/aloha_sim_insertion_human

But it seems the render_mode is hardcoded as rgb_array in lerobot/common/envs/factory.py and the environment does not support human rendering. It would be very useful for debugging the models, more so if it could somehow be linked to the rerun GUI.

I was wondering if there are plans to support non-headless training. If not, do you have any tips or recommendations for visualization during training/evaluation using any of the following approaches:

  1. rerun dataset visualizer
  2. dm_control viewer
  3. Wrapping the make env with gymnasium.experimental.wrappers.HumanRenderingV0

NOTE: I naively tried wrapping the make in lerobot/common/envs/factory.py with HumanRenderingV0. That visualizes the environment for a few iterations and quickly spawns a new window for every episode. I'm not sure this is how it should be done but this is certainly not the best approach:

env = env_cls(
        [
            lambda: HumanRenderingV0(gym.make(gym_handle, disable_env_checker=True, **kwargs)).reset()
            for _ in range(n_envs if n_envs is not None else cfg.eval.batch_size)
        ]
    )

Tests do not pass when just poetry test extras installed

System Info

Tested on `main`, commit: 1249aee

Information

  • One of the scripts in the examples/ folder of LeRobot
  • My own task or dataset (give details below)

Reproduction

gym_pusht is a missing requirement.

  1. Follow https://github.com/huggingface/lerobot/blob/main/CONTRIBUTING.md
  2. Create a new conda env
conda create -y -n lerobot-dev python=3.10 && conda activate lerobot-dev
  1. Install limited extras including test
poetry install --sync --extras "dev test"
  1. Run all tests
DATA_DIR="tests/data" python -m pytest -sv ./tests

Received the following error:

>   ???
E   ModuleNotFoundError: No module named 'gym_pusht'

<string>:8: ModuleNotFoundError
========================================================= short test summary info ==========================================================
FAILED tests/test_examples.py::test_examples_3_and_2 - ModuleNotFoundError: No module named 'gym_pusht'
================================================ 1 failed, 39 passed, 25 skipped in 20.48s =================================================

Expected behavior

All tests to pass.

[Improvement] Best way to set MUJOCO_GL

Right now, some online training won't work when the env uses mujoco if the environment variable MUJOCO_GL has not been set to egl.

Since there's no indication for that in the current README, I'm creating this issue to discuss the best way to address this moving forward. Here are the 2 ways that I see for how we could solve this:

1. Explicitly tell the user in the README to set it:

export MUJOCO_GL=egl

2. Set it directly in the code (and make it invisible to the user):

os.environ["MUJOCO_GL"] = "egl"

I don't really know what's the best way here. What do you think @Cadene @alexander-soare?

Replay buffer needs to handle observation steps, prediction horizon, and rollout horizon

Consider a policy that:

  • Takes as input a total of $N_o$ environment observations, $1$ from now and $N_o - 1$ from the past.
  • Internally generates a horizon of $N_h$ actions to execute in the environment, starting from the first (maybe past) observation.
  • Only ends up executing $N_r &lt;= N_h - (N_o - 1)$ of those actions on the environment.

Let's take an example: $N_o = 2$, $N_h = 8$, $N_r = 4$.

image

To be clear, the whole purpose of having a longer prediction horizon than actually needed for rollout is to train a policy with longer horizon modelling capabilities than it will actually be used for (in hopes that this improves the performance in rollouts).

For training such a policy it's important every bit of the replay buffer ends up in the window of "r"s I drew above at some point in the training process. To illustrate what I mean: suppose the sampler is only aware of $N_h$ but is not aware of $N_o$ and $N_r$. Then given an episode with 16 time steps, the sampler has 8 possible sequences it can sample:

bad

But this means the policy is never trained to generate an action trajectory that can complete the task in $N_r$ steps! During rollout, the policy might get close to completing a task, but would struggle to finish it (and this is exactly what happened: see https://github.com/huggingface/lerobot/pull/41#issue-2199930267).

The sampler must be able to do this:

good

Of course, that means we'd need to fill in the blanks. For example, at this position, the red letters aren't in the actual replay buffer so we need to somehow fill them in:

image

or another example:

image

One strategy could be padding with copies.


Currently, the TorchRL sample does the first variant of sample (without appropriate padding). We need to come up with a solution for padding correctly.

`transformers` style scripts

We should try to converge to something that roughly looks like this for our scripts:

#!/usr/bin/env python3
"""Train my model on a dataset."""

from dataclasses import dataclass, field
from datasets import load_dataset
from transformers import AutoConfig, HfArgumentParser, Trainer, TrainingArguments
from my_model import MyModel


@dataclass
class ModelArguments:
    """
    Arguments pertaining to which model/config we are going to train from.
    """

    model_name_or_path: str = field(
        metadata={"help": "Path to pretrained model or model identifier from huggingface.co/models"}
    )
    trust_remote_code: bool = field(
        default=False,
        metadata={
            "help": (
                "Whether or not to allow for custom models defined on the Hub in their own modeling files. This option"
                "should only be set to `True` for repositories you trust and in which you have read the code, as it "
                "will execute code present on the Hub on your local machine."
            )
        },
    )


@dataclass
class DataTrainingArguments:
    """
    Arguments pertaining to what data we are going to input our model for training and eval.
    """


def main():
    parser = HfArgumentParser((ModelArguments, DataTrainingArguments, TrainingArguments))
    model_args, data_args, training_args = parser.parse_args_into_dataclasses()

    # Load the model and the processor
    config = AutoConfig.from_pretrained(
        model_args.model_name_or_path,
        trust_remote_code=model_args.trust_remote_code,
    )
    model = MyModel(config)

    # Load the dataset
    dataset = load_dataset("my_dataset")

    # Train
    trainer = Trainer(model=model, args=training_args, train_dataset=dataset)
    trainer.train()


if __name__ == "__main__":
    main()

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.