ros1-noetic-general（ros1 思维将军）

ROS1 Noetic General

Use this skill for project-agnostic ROS1 Noetic work, not only quadruped tasks.

Typical trigger phrasing includes requests like:

• "启动机器狗"
• "启动 ROS 程序"
• "启动 ROS"
• "帮我看一下 ROS"
• "帮我编译一下这个 ROS 项目"
• "检查这个 catkin 工作区"
• "帮我把这个 launch 跑起来"
• "看看这个 ROS 节点为什么没起来"
• "build this ROS package"
• "start this ROS launch"
• "check this ROS workspace"
• "debug this ROS node"
• "use rosskill"

Routing rule inside this skill:

• If the request is mainly general ROS knowledge (concepts, terminology, architecture, best practices), answer with ROS guidance first.
• If the request touches local files, local workspace state, local commands, build/start/launch/run/monitor/stop actions, or runtime diagnostics, use this skill's scripts and execution workflow.
• If the user explicitly says 使用 rosskill, 用 ros skill, or use rosskill, strongly prefer this skill even when the request could also be answered more generally.

When the request mentions OpenClaw, rosbridge, websocket ROS control, or remote intent mapping, load references/ros1-openclaw-adapter.md early.

Workflow

1. Resolve execution context and bundled resource paths.
2. Validate ROS1 environment and active graph.
3. Classify request into a project profile.
4. Execute profile-specific checklist.
5. Apply safe rollout and verification.
6. Report result with reproducible commands.

Step 1: Resolve execution context first

Bundled scripts live inside this skill directory. Do not assume the current shell directory is the skill root.

• Resolve scripts/... and references/... relative to this SKILL.md file before using them.
• If you execute a bundled script, prefer an absolute path to the script.
• If the host runtime already provides equivalent ROS inspection commands, it is fine to use those directly.

Example pattern:

SKILL_DIR="<absolute-path-to-this-skill>"
zsh "$SKILL_DIR/scripts/ros1_shell_detect.sh"
zsh "$SKILL_DIR/scripts/ros1_env_check.sh"

Step 2: Validate environment

Run:

zsh "$SKILL_DIR/scripts/ros1_shell_detect.sh"
zsh "$SKILL_DIR/scripts/ros1_env_check.sh"
zsh "$SKILL_DIR/scripts/ros1_graph_probe.sh" topic

If ROS commands are missing, use the shell detector output to decide whether the machine expects setup.bash or setup.zsh, then source ROS first.

Typical pattern:

source /opt/ros/noetic/setup.zsh

If workspace overlays exist, source base first and overlays second.

Step 3: Choose project profile

• A. Bringup/Build: catkin workspace, package dependencies, launch files.
• B. Runtime Debug: topics/services/actions, tf tree, node health.
• C. Motion Control: velocity/joint commands with feedback checks.
• D. Data Pipeline: rosbag record/playback, offline analysis.
• E. OpenClaw Integration: rosbridge websocket adaptation and intent mapping.
• F. Architecture/Performance: nodelets, callback-threading, message_filters, dynamic_reconfigure.
• G. Migration Planning: ROS1 legacy maintenance and ROS1→ROS2 transition strategy.

Read detailed commands from references/project-profiles.md.

For full ROS1 coverage (core graph, launch, tf/tf2, actions, bags, diagnostics, networking), load references/ros1-full-scope.md.

Step 4: Execute by profile

A) Bringup/Build

• bringup means bringing a ROS system up far enough to run: source ROS, identify workspace, build if needed, find launch files, start nodes, and confirm the graph is healthy.
• Verify workspace structure and package discoverability.
• Detect workspace/build strategy first with scripts/ros1_workspace_probe.sh.
• Run scripts/ros1_bringup_check.sh before starting or rebuilding a project.
• For OpenClaw-style tool use, prefer the runtime loop: ros1_start_target.sh -> ros1_runtime_health_check.sh -> ros1_stop_target.sh.
• Build with the detected catkin command and stop on first error.
• Discover and validate launch files before runtime.

Minimal runtime loop example:

zsh "$SKILL_DIR/scripts/ros1_start_target.sh" \
  --workspace /path/to/ws \
  --package my_pkg \
  --launch demo.launch

zsh "$SKILL_DIR/scripts/ros1_runtime_health_check.sh" \
  --state-file /tmp/ros1_skill_runtime/<run>/state.env \
  --expect-topic /rosout

zsh "$SKILL_DIR/scripts/ros1_stop_target.sh" \
  --state-file /tmp/ros1_skill_runtime/<run>/state.env

B) Runtime Debug

• Confirm graph visibility (rosnode list, rostopic list).
• Check type/rate/bandwidth for critical topics.
• Verify tf availability and frame consistency.

C) Motion Control

• Verify command topic type and active subscribers.
• Validate critical interface types explicitly with scripts/ros1_interface_check.sh.
• Prefer closed-loop motion if distance/angle is requested.
• Keep conservative defaults and always send explicit stop.

Use interface/type checks first, then run motion script (mobile base profile):

zsh "$SKILL_DIR/scripts/ros1_interface_check.sh" topic /cmd_vel geometry_msgs/Twist
python3 "$SKILL_DIR/scripts/move_forward_by_odom.py" \
  --cmd-topic /cmd_vel \
  --odom-topic /odom \
  --distance 1.0 \
  --speed 0.2

D) Data Pipeline

• Record minimal required topics (avoid “record all” unless requested).
• Confirm clock/time behavior in playback scenarios.
• Document bag metadata and replay command for reproducibility.

E) OpenClaw Integration (ROS1)

• rosbridge is the websocket bridge that lets OpenClaw or other external clients publish/subscribe/call into a ROS graph without writing native rospy / roscpp code.
• Start ROS1 rosbridge websocket.
• Preflight the ROS graph before exposing any endpoint to OpenClaw.
• Map high-level intents to ROS1 topic/service/action operations with explicit templates.
• Enforce safety stop semantics, timeout, and disconnect behavior for every motion intent.

See references/ros1-openclaw-adapter.md.

F) Architecture / Performance

• Enforce single-responsibility node boundaries.
• Choose queue sizes intentionally for high-rate sensor topics.
• Use message_filters for sensor-time synchronization.
• Apply callback threading patterns (MultiThreadedSpinner / worker queue).
• Use nodelets for large intra-process data when zero-copy matters.
• Use dynamic_reconfigure for runtime tuning instead of hard-coded constants.

See references/ros1-engineering-patterns.md.

G) Migration Planning (ROS1 → ROS2)

• Capture current ROS1 interfaces (topics/services/actions/params) before migration.
• Prefer staged migration from leaf nodes inward.
• Use bridge period planning where mixed ROS1/ROS2 runtime is required.

See references/ros1-engineering-patterns.md migration section.

Step 5: Safety and quality gates

• Never leave a robot/controller moving on function exit.
• Add timeout for every long-running command.
• Fail fast when telemetry is stale or missing.
• Report exact measured outcome (not only “success”).
• When starting long-running processes, persist pid/log/state metadata so later health checks and stop actions can use the same handle.
• Ask for confirmation before commands that install packages, require sudo, change system configuration, or move hardware in the real world.
• Prefer dry-run inspection before any destructive or stateful ROS action.

Step 6: References

• Official ROS docs and package index links: references/official-docs.md
• Full ROS1 capability map and command matrix: references/ros1-full-scope.md
• Engineering patterns & migration playbook: references/ros1-engineering-patterns.md
• Project-profile checklists and command templates: references/project-profiles.md
• OpenClaw↔ROS1 adapter blueprint: references/ros1-openclaw-adapter.md
• ROS1 knowledge-base sources ledger (official pages reviewed): references/ros1-knowledge-base-sources.md

If official sites block simple fetches, use whatever browsing or browser-automation tools the host runtime actually exposes. Do not assume tool names that the host has not provided.