Go beyond running a new simulator example: Identify the observations, actions, and physics that your research task requires you to change.
Before practice
01 Do the task, physics, renderer, and RL library serve the same role?
Description
The task defines observations, actions, rewards, resets, and terminations. The physics backend handles physics calculations, the renderer generates images, and the RL library trains policies.
02 What must be aligned when the policy control period differs from the physics step?
Description
The physics step and policy control period may differ. Align action scale, joint units, and control decimation to transfer a policy to another simulator or robot.
GPU environment: Check before class. Prefer personal equipment, supplemented by shared resources.
Jetson extension: edge inference and latency measurement.
Applications
Mobile robot paths and safety
An application design case choosing either grid paths or continuous velocity control.
Observation·State
Position, target-relative position, and nearby obstacle observations.
Action
Grid direction selection or bounded linear and angular velocities.
Reward·Constraint
Separate arrival, collision, and movement costs. Distinguish collisions from timeouts.
Comparison baseline
Shortest path and rule-based avoidance.
Metrics to check
Success rate, collision rate, travel distance, and time. Evaluate on unseen maps.
Drive-system tracking performance and input cost
A synthetic 1st-order motor model that tracks a constant reference angular velocity in each experiment. Separate training at target 1 from evaluation at 0.5, 1, and 1.5.
Observation·State
Angular velocity , target .
Action
Continuous , actual input .
Reward·Constraint
. Termination at ; time limit at 100 steps.
Comparison baseline
P control with the same input limits.
Metrics to check
Tracking RMSE, mean u², and number of safety terminations. Evaluate separately for each target.
Start from CartPole-v1 observations, actions, resets, and time limits.
Procedure
Run the provided rule policy and record observations and actions for one episode.
In the official Isaac Lab Quickstart, identify and map the roles of the task, physics backend, renderer, and RL library.
Results to retain
Environment interface mapping table and one rollout.
Items to record and points to check
Role
Gymnasium example
Isaac Lab configuration
What I will change
Points to check
Did you distinguish the physics simulation from the learning algorithm as separate components?
Did you distinguish the policy control period from the physics simulation period?
2. Environment onboarding: execution or transition analysis
Starting conditions
GPU environment: On a prepared Linux/Windows NVIDIA system, follow the official Quickstart in this order: task list → zero/random agent → training → play. CPU environment: During the same session, complete CartPole transition and policy comparisons and task configuration mapping.
Procedure
If a GPU environment is ready, run the Cartpole task following the current official documentation, and record the task ID, backend, seed, and execution command.
If no GPU environment is available, compare Random and Rule trajectories with the provided CPU code and identify termination causes.
In your selected path, find the setting to modify to change one observation, action, or termination rule.
Results to retain
GPU: Run screenshot or rollout and execution conditions. CPU: State trajectory plot and configuration mapping table.
Items to record and points to check
Path
Task and environment
Execution conditions
Observed results
Settings to modify
Points to check
Did you avoid presenting unexecuted Isaac results as actual run results?
Did you trace observations, actions, and terminations beyond merely resolving installation issues?
3. Minimum components of a research task
Starting conditions
Choose manipulation, mobile robotics, or process control.
Procedure
Tabulate the scene, state observations, action scale, reward, reset, and termination.
Link to the files and components containing these settings in the official Isaac Lab robot tutorial.
Decide what to hold fixed and which single item to change in the first experiment.
Results to retain
Minimum task design table and initial validation plan.
Items to record and points to check
Components
My task definition
Reference configuration location
Initial verification
Points to check
Did you distinguish successful visualization from a correctly defined learning problem?
Did you identify the core issue to validate rather than trying to reproduce a complete robot system from the start?