Skip to content

Refactor jazzy-devel installation docs, dependency manifests and development Docker workflow#70

Open
jlgalanRB wants to merge 13 commits into
RobotnikAutomation:jazzy-develfrom
jlgalanRB:refactor/jazzy/install-docs-dependencies
Open

Refactor jazzy-devel installation docs, dependency manifests and development Docker workflow#70
jlgalanRB wants to merge 13 commits into
RobotnikAutomation:jazzy-develfrom
jlgalanRB:refactor/jazzy/install-docs-dependencies

Conversation

@jlgalanRB
Copy link
Copy Markdown
Collaborator

Summary

This PR refactors the installation, dependency and development workflow for jazzy-devel, aligning the repository with the setup that is currently validated for ROS 2 Jazzy + Gazebo Harmonic.

The original motivation was to clean up the remaining mix between generic multi-distro guidance and branch-specific instructions. The final scope also includes dependency review, repository manifest reorganization, a full Docker-based development workflow, and a small controller bringup fix.

This work is intentionally focused on leaving the jazzy-devel branch consistent and operational first. If this approach is approved, the same review and restructuring should later be applied to humble-devel, adapting the manifests, dependencies and documentation to the validated setup for that branch.

Main goals

  • Leave a clearer and more consistent installation guide for jazzy-devel
  • Separate generic repository information from branch-specific operational setup
  • Clarify the source of truth for external repositories and runtime/build dependencies
  • Reduce setup errors caused by mixed Humble/Jazzy guidance
  • Provide a reproducible Docker-based development environment for this branch

What changed

Documentation

  • Reworked robotnik_gazebo_ignition/README.md as the branch-specific operational guide for jazzy-devel
  • Reorganized installation, quick start, usage, teleoperation, MoveIt, troubleshooting and Docker references
  • Added a new conceptual guide for ROS 2 <-> Gazebo integration and branch compatibility in docs/ros2-gazebo-compatibility.md
  • Moved the Docker workflow guide to docker/docker.md and linked it from the simulator README

Repository manifests and dependency organization

  • Reorganized external repository manifests under dependencies/repos/
  • Added robotnik_simulation.jazzy-devel.repos as the development manifest, following branch heads
  • Added robotnik_simulation.jazzy.repos as the validated release-oriented manifest pinned to known-good revisions
  • Included teleop_panel in the manifests
  • Reviewed dependency declarations across the simulation packages and adjusted package.xml files to make required runtime dependencies explicit
  • Aligned Docker package installation with dedicated builder and base package lists

Dependency policy

One of the decisions in this PR is to keep the workspace bootstrap focused on Robotnik repositories and rely on apt packages for external upstream components that are already available and stable in Jazzy.

In particular, packages such as:

  • ur_description
  • ur_simulation_gz
  • ros_gz_sim / ros_gz integration packages

are installed from apt instead of cloning their source repositories into the workspace.

The goal is to keep the development workspace simpler, reduce maintenance overhead, and avoid pulling additional upstream repositories when the validated binary packages already cover the required functionality for this branch.

Docker workflow

  • Added a development-oriented Docker image and compose workflow for jazzy-devel
  • Added:
    • docker/Dockerfile
    • docker/docker-compose.yaml
    • docker/docker-compose.gpu.yaml
    • docker/bootstrap-workspace.sh
    • docker/devel-entrypoint.sh
    • docker/docker.md
  • The container now:
    • bootstraps the workspace from the selected repos manifest
    • installs Robotnik local .deb packages when present
    • resolves remaining dependencies with rosdep
  • The Docker setup is intentionally oriented to development on jazzy-devel
  • Switching to the stable manifest later only requires changing the default external repos file from *.${ROS_DISTRO}-devel.repos to *.${ROS_DISTRO}.repos

Functional fixes included in this branch

  • Added explicit controller_manager and service call timeouts to the controller spawner in spawn_robot.launch.py
    • this improves robustness during controller bringup and avoids races when joint_state_broadcaster is spawned before the Robotnik controllers are fully ready
  • Removed arm controller entries from rbsummit_steel_ros2_control.yaml
    • there is currently no arm-enabled rbsummit_steel model provided in this branch
    • if arm support is added later, it should follow the same pattern already used for platforms such as Kairos, with the corresponding description and simulation-specific configuration

Source-of-truth policy after this PR

  • dependencies/repos/robotnik_simulation.jazzy.repos
    • validated release snapshot
    • intended as the stable reference manifest
  • dependencies/repos/robotnik_simulation.jazzy-devel.repos
    • development manifest
    • intended for day-to-day work against active branch heads
  • dependencies/requirements/builder/packages.txt
    • packages used by the Docker builder/bootstrap stage
  • dependencies/requirements/base/packages.txt
    • packages used by the Docker runtime/base simulation stage
  • remaining ROS package dependencies continue to be resolved through rosdep from the package manifests

Related PRs

Notes

  • This refactor is currently scoped to jazzy-devel
  • If the approach is approved, the same cleanup and restructuring should be replicated for humble-devel with its corresponding validated dependency set and documentation
  • Final Docker validation is being completed together with this branch refresh
  • The release-oriented .jazzy.repos manifest is currently pinned to validated commits; once the corresponding release tags exist in the dependent repositories, it can be updated to use tags instead of commit SHAs

@jlgalanRB jlgalanRB requested a review from asoriano1 May 21, 2026 08:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant