Add ROS 1 to ROS 2 migration note for group parameter handling (#4983) (

#5002)

* Add ROS 1 to ROS 2 migration note for group parameter handling

Add information to help developers safely migrate parameter updates by
highlighting that ROS 2's default set_parameters service behaves
differently than ROS 1's dynamic_reconfigure regarding atomic updates.
Points users to set_parameters_atomically service to maintain atomic
behavior during migration.

* Remove 'default' terminology from parameter services note

* Adapt the structure of the migration guide from ROS 1 to ROS 2

* Refactor based on code review

* Fix console code-block

(cherry picked from commit 3dbac70)

Co-authored-by: MariuszSzczepanikSpyrosoft <[email protected]>

source/Concepts/Basic/About-Parameters.rst

@@ -119,16 +119,4 @@ Migrating from ROS 1
 
 The :doc:`Launch file migration guide <../../How-To-Guides/Migrating-from-ROS1/Migrating-Launch-Files>` explains how to migrate ``param`` and ``rosparam`` launch tags from ROS 1 to ROS 2.
 
-The :doc:`YAML parameter file migration guide <../../How-To-Guides/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter files from ROS 1 to ROS 2.
-
-In ROS 1, the ``roscore`` acted like a global parameter blackboard where all nodes could get and set parameters.
-Since there is no central ``roscore`` in ROS 2, that functionality no longer exists.
-The recommended approach in ROS 2 is to use per-node parameters that are closely tied to the nodes that use them.
-If a global blackboard is still needed, it is possible to create a dedicated node for this purpose.
-ROS 2 ships with one in the ``ros-{DISTRO}-demo-nodes-cpp`` package called ``parameter_blackboard``; it can be run with:
-
-.. code-block:: console
-
-   ros2 run demo_nodes_cpp parameter_blackboard
-
-The code for the ``parameter_blackboard`` is `here <https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/parameters/parameter_blackboard.cpp>`__.
+The :doc:`Migration guide <../../How-To-Guides/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter from ROS 1 to ROS 2.

source/How-To-Guides/Migrating-from-ROS1/Migrating-Parameters.rst

@@ -18,6 +18,21 @@ In ROS 2, parameters are associated per node and are configurable at runtime wit
 
 * See :doc:`ROS 2 CLI usage <../../Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` for a better understanding of how the CLI tools work and its differences with ROS 1 tooling.
 
+Global Parameter Server
+-----------------------
+
+In ROS 1, the ``roscore`` acted like a global parameter blackboard where all nodes could get and set parameters.
+Since there is no central ``roscore`` in ROS 2, that functionality no longer exists.
+The recommended approach in ROS 2 is to use per-node parameters that are closely tied to the nodes that use them.
+If a global blackboard is still needed, it is possible to create a dedicated node for this purpose.
+ROS 2 ships with one in the ``ros-{DISTRO}-demo-nodes-cpp`` package called ``parameter_blackboard``; it can be run with:
+
+.. code-block:: console
+
+   ros2 run demo_nodes_cpp parameter_blackboard
+
+The code for the ``parameter_blackboard`` is `here <https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/parameters/parameter_blackboard.cpp>`__.
+
 Migrating YAML Parameter Files
 ------------------------------
 
@@ -67,3 +82,13 @@ Some features of ROS 1 parameters files do not exist in ROS 2:
 
 - Mixed types in a list is not supported yet (`related issue <https://github.com/ros2/rcl/issues/463>`_)
 - ``deg`` and ``rad`` substitutions are not supported
+
+
+Parameter Atomic Operation
+--------------------------
+
+When migrating parameter groups from ROS 1 to ROS 2, there are important differences to consider.
+In ROS 1, ``dynamic_reconfigure`` handles parameter groups atomically, meaning all parameters in a reconfiguration request are processed together in a single callback.
+In ROS 2, the ``set_parameters`` service processes each parameter individually, which may lead to multiple callback invocations.
+To maintain atomic behavior when migrating from ``dynamic_reconfigure``, use the ``set_parameters_atomically`` service, which validates and applies all parameters as a single operation.
+If any parameter fails validation, no parameters will be updated.