Navigation Environment

---
name: navigation-environment
description: "Operate and validate the GazeboEnv observation, action, reset,
  timing, and reward contract for the ROS/Gazebo Velodyne navigation environment
  without requiring a live simulator."
disable-model-invocation: true
metadata:
  disco-role: operating
license: MIT
---

# Navigation environment

Use this skill when a downstream agent needs to reason about the mobile-robot
`GazeboEnv` interface, prepare a compatible observation/action, diagnose a
sensor or ROS integration failure, or check a synthetic transition. This skill
is a distilled contract, not a simulator launcher and not a TD3 training guide.

## Operating contract

- The repository's training configuration uses `environment_dim=20` and four
  robot features, so every observation is a flat numeric vector of length 24.
- The first 20 values are Velodyne distance bins, initialized to 10 and
  updated by the point-cloud callback. The final four values are, in order,
  distance to goal, relative goal heading, linear action, and angular action.
  `reset` returns the two action slots as 0; `step` places the action used for
  that transition in them. There is no separate previous-action history in
  the implementation, so do not invent one.
- The environment-facing action is `[linear_x, angular_z]`: linear is in
  `[0, 1]`, angular is in `[-1, 1]`. `step` publishes these values directly;
  it does not rescale them. A TD3 actor output in `[-1, 1]` therefore needs its
  first component mapped with `(a_linear + 1) / 2` before calling `step`.
- `done` becomes true on a laser collision or a goal hit. A goal hit is
  reported separately as `target=True`; collision and target reward priority
  is target first, then collision.
- Use `scripts/validate_navigation_contract.py` for offline numeric checks.
  It imports no ROS package, starts no process, and is the preferred check for
  state length, action range, point-bin fixtures, and threshold behavior.

## Safe reasoning workflow

1. Confirm the caller has ROS Noetic/Ubuntu 20.04-compatible ROS message and
   Gazebo dependencies, plus Python dependencies used by the environment
   (`numpy` and `squaternion`). A live run additionally needs `roscore`,
   `roslaunch`, Gazebo, and a built catkin workspace with the scenario and
   Velodyne plugin packages. This host-independent skill does not install or
   launch any of them.
2. Treat a relative launch name as relative to the environment module's
   `assets` directory, not the caller's current directory. The repository's
   `multi_robot_scenario.launch` includes the empty TD3 world and spawns model
   `r1`.
3. Validate an observation as 20 finite sensor values followed by four finite
   robot values. Reject 23- or 25-value vectors rather than silently padding or
   truncating them.
4. Validate action-space provenance. If an actor produced `[-1, 1]` for both
   dimensions, transform only the linear component before using this
   environment contract.
5. For a synthetic sensor case, reduce points into the same 20 angular bins,
   compute the minimum distance per bin, and then apply the strict collision
   threshold. Keep simulator verification explicitly unavailable when ROS or
   Gazebo is absent.
6. Interpret `reset` and `step` as ROS-dependent calls. A valid offline vector
   does not prove that odometry, PointCloud2, publishers, or physics services
   are connected.

## Scope boundaries

This skill covers constructor prerequisites and launch resolution, point-cloud
reduction, state/action/reward semantics, reset randomization, ROS interfaces,
and predictable numeric/integration failures. Do not use it to explain TD3
network architecture, replay-buffer behavior, optimizer settings, training
loops, model checkpoints, or installation procedures beyond naming prerequisites.
See the bundled references for the detailed contract and troubleshooting.

## Numeric and evidence notes

The source callback has no explicit finite-value or zero-horizontal-range
 guard. Use the validator's stricter finite-input policy for synthetic data;
never turn NaN or an `acos` domain error into a claimed sensor reading.

## Evidence and verification status

The contract was distilled from the pinned repository's environment module,
launch file, scenario xacro/URDF, Velodyne description and Gazebo plugin, and
training caller. The offline validator is checked with its help/parser path,
self-test, a valid 24-value fixture, invalid 23/25-value fixtures, action-range
mismatches, a synthetic point cloud, and strict threshold cases. No ROS,
Gazebo, `roscore`, `roslaunch`, or catkin runtime is claimed or required here.