Data auto-generation part using a simple state machine

[Papaercold]

Summary

This PR introduces a state-machine–based data generation pipeline for the SO101 pick-orange task in LeIsaac.

The main implementation lives under scripts/environments/state_machine, where a scripted finite state machine is used to generate deterministic pick-and-place demonstrations. To integrate this pipeline with the existing teleoperation and replay infrastructure, a new teleoperation device type named so101_state_machine is added, with corresponding changes under source/leisaac.

The implementation intentionally follows the coding style and structure of
scripts/environments/teleoperation/teleop_se3_agent.py, and includes detailed comments for readability and maintainability.

---

Key Features

• State-machine–based data generation

  • Implemented under scripts/environments/state_machine
  • Designed to be deterministic, readable, and easy to extend

• New teleoperation device: so101_state_machine

  • Integrated into the existing teleoperation interface
  • Allows scripted policies to drive the environment using the same action pipeline as keyboard/gamepad devices

• Replay compatibility

  • Recorded datasets can be replayed using the existing
    scripts/environments/teleoperation/replay.py
  • No custom replay logic is required

---

Usage Examples

Generate data

python scripts/environments/state_machine/pick_orange.py \
  --dataset_file=./datasets/dataset_test.hdf5 \
  --task=LeIsaac-SO101-PickOrange-v0 \
  --num_envs=1 \
  --device=cuda \
  --enable_cameras \
  --record \
  --num_demos=1

Replay recorded data

python scripts/environments/teleoperation/replay.py \
  --dataset_file=./datasets/dataset_test.hdf5 \
  --task=LeIsaac-SO101-PickOrange-v0 \
  --num_envs=1 \
  --device=cuda \
  --enable_cameras \
  --select_episodes 0 \
  --replay_mode=action \
  --task_type=so101_state_machine

---

Observed Issue / Open Question

When running the state-machine–based data generation script, the robot gripper exhibits a brief downward drop at the beginning of each episode before stabilizing.

At first glance, this behavior appears to be gravity-related. However, gravity is explicitly disabled at spawn time for all relevant teleoperation devices, including the newly introduced state-machine device:

def use_teleop_device(self, teleop_device) -> None:
    self.task_type = teleop_device
    if teleop_device in ["keyboard", "gamepad", "so101_state_machine"]:
        self.scene.robot.spawn.rigid_props.disable_gravity = True

Given this configuration, it is unclear whether the observed initial drop is truly caused by gravity. Other potential factors may include controller or drive initialization behavior, insufficient drive stiffness during the first few simulation steps, or the absence of an explicit action warm-start when the episode begins.

I would appreciate feedback on the following questions:

• Is this type of initial transient expected when introducing a scripted state machine as a teleoperation device?
• Could this behavior be related to controller initialization, drive parameter settings, or action preprocessing rather than gravity itself?
• Are there recommended best practices in Isaac Lab / LeIsaac for avoiding such initial transients when using scripted or non-interactive teleoperation devices?

Any insights, suggestions, or references to similar patterns in existing tasks would be greatly appreciated.

---

Notes

• This PR focuses on clarity, determinism, and minimal intrusion into existing teleoperation and replay logic.
• The issue described above does not affect replay correctness once the episode is running, but it does impact the visual behavior at the very beginning of an episode.

[EverNorif]

@Papaercold Thank you for your PR. Due to a busy schedule recently, I may not be able to review the code right away, I'll check it later.

Regarding the brief drop of the gripper that you mentioned, I haven’t observed this behavior so far. I’ll check for it again using the latest code.