From 3946c464a2e76d95f4c53cc9c5bb6192cc0df1e7 Mon Sep 17 00:00:00 2001 From: Chris Iverach-Brereton Date: Tue, 7 Jan 2025 13:43:26 -0500 Subject: [PATCH 1/3] Fix duplicate TOC entries for Create3 Republisher --- software/create3.md | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/software/create3.md b/software/create3.md index 0a1bfc3..24dc21e 100644 --- a/software/create3.md +++ b/software/create3.md @@ -108,21 +108,6 @@ See [irobot_create_msgs](https://github.com/iRobotEducation/irobot_create_msgs) ```note When publishing or subscribing to topics, make sure that the [QoS](https://docs.ros.org/en/humble/Concepts/About-Quality-of-Service-Settings.html) that you use matches that of the topic. ``` - -## Create® 3 Republisher {#create-3-republisher} - -In certain network configurations it is beneficial to isolate the Create® 3 from the remainder of the ROS 2 network traffic. The Create® 3 has limited resources and can be overwhelmed with too many topics to discover. The Create® 3 Republisher is used to achieve this. All communication to the Create® 3 is routed through the Raspberry Pi via the republished ROS 2 topics, action and services. This allows nodes to interact with the Create® 3 ROS 2 elements normally while only needing communication with the Raspberry Pi. - -This is achieved by having the Create® 3 on its own unique namespace which is a combination of the robot namespace and `_do_not_use`. This results in all of its topics being hidden and indicates clearly that these topics, actions and services are not to be used directly by the user. The Create® 3 only communicates with the single Raspberry Pi that is present on the same robot. All of the Create® 3 topics, actions and services are then republished and relayed by the Raspberry Pi `create3_republisher` node with just the robot namespace so they are fully visible and available to the rest of the ROS 2 network. In order to interact with the Create® 3, any given node will interact with the topics, actions, and servers generated by the Raspberry Pi, and the republisher node on the Raspberry Pi will relay that information back to the Create® 3. - -```note -The `_do_not_use` namespace, as the name suggests, should _not_ be used by any other nodes. The only place this namespace should ever be referenced is inside the configuration file for the `create3_republisher` node and within the Create® 3's application configuration. - -All other ROS nodes, shell commands (e.g. `ros2 topic echo ...`) should use the republished topics, actions, and services. -``` - -In order to prevent overloading the system with too many topics, the number of topics, actions and services that are relayed through the republisher node are limited. The default list of topics, actions and services that are being relayed can be found in the [`create3_republisher` launch parameters](https://github.com/iRobotEducation/create3_examples/blob/humble/create3_republisher/bringup/params.yaml). To optimize the system, update this list to only include the necessary topics, actions and services that are needed. - {% endtab %} {% tab create3 jazzy %} @@ -174,9 +159,20 @@ See [irobot_create_msgs](https://github.com/iRobotEducation/irobot_create_msgs) ```note When publishing or subscribing to topics, make sure that the [QoS](https://docs.ros.org/en/jazzy/Concepts/About-Quality-of-Service-Settings.html) that you use matches that of the topic. ``` +{% endtab %} +{% endtabs %} ## Create® 3 Republisher {#create-3-republisher} +{% tabs republisher %} +{% tab republisher galactic %} +```warning +**ROS 2 Galactic is no longer supported.** Please consider upgrading to a newer release +``` + +Create® 3 Republisher is not available for ROS 2 Galactic. +{% endtab %} +{% tab republisher humble %} By default, the Turtlebot 4 uses the `create3_republisher` node to isolate the Create® 3 from the remainder of the ROS 2 network traffic. This helps limit the network traffic that reaches the Create® 3 when it is connected to the wireless network, especially when multiple robots are connected. All ROS 2 traffic is routed via the Turtlebot 4's Raspberry Pi computer, and the `create3_republisher` node exposes the Create® 3's topics, services, and actions the robot's main namespace. This allows external workstations and other robots to interact with the robot via the Raspberry Pi's wireless connection. The Create® 3's topics, services, and actions are all available inside a namespace called `_do_not_use`. This results in the topics being hidden, and clearly indicates that they should not be used directly by the user. The Create® 3 only communicates with the single Raspberry Pi that is present on the same robot. All of the Create® 3 topics, actions and services are then republished and relayed by the Raspberry Pi `create3_republisher` node with just the robot namespace so they are fully visible and available to the rest of the ROS 2 network. In order to interact with the Create® 3, any given node will interact with the topics, actions, and servers generated by the Raspberry Pi, and the republisher node on the Raspberry Pi will relay that information back to the Create® 3. @@ -188,6 +184,18 @@ All other ROS nodes, shell commands (e.g. `ros2 topic echo ...`) should use the ``` In order to prevent overloading the system with too many topics, the number of topics, actions and services that are relayed through the republisher node are limited. The default list of topics, actions and services that are being relayed can be found in the [`create3_republisher` launch parameters](https://github.com/iRobotEducation/create3_examples/blob/jazzy/create3_republisher/bringup/params.yaml). To optimize the system, update this list to only include the necessary topics, actions and services that are needed. +{% endtab %} +{% tab republisher jazzy %} +In certain network configurations it is beneficial to isolate the Create® 3 from the remainder of the ROS 2 network traffic. The Create® 3 has limited resources and can be overwhelmed with too many topics to discover. The Create® 3 Republisher is used to achieve this. All communication to the Create® 3 is routed through the Raspberry Pi via the republished ROS 2 topics, action and services. This allows nodes to interact with the Create® 3 ROS 2 elements normally while only needing communication with the Raspberry Pi. + +This is achieved by having the Create® 3 on its own unique namespace which is a combination of the robot namespace and `_do_not_use`. This results in all of its topics being hidden and indicates clearly that these topics, actions and services are not to be used directly by the user. The Create® 3 only communicates with the single Raspberry Pi that is present on the same robot. All of the Create® 3 topics, actions and services are then republished and relayed by the Raspberry Pi `create3_republisher` node with just the robot namespace so they are fully visible and available to the rest of the ROS 2 network. In order to interact with the Create® 3, any given node will interact with the topics, actions, and servers generated by the Raspberry Pi, and the republisher node on the Raspberry Pi will relay that information back to the Create® 3. + +```note +The `_do_not_use` namespace, as the name suggests, should _not_ be used by any other nodes. The only place this namespace should ever be referenced is inside the configuration file for the `create3_republisher` node and within the Create® 3's application configuration. +All other ROS nodes, shell commands (e.g. `ros2 topic echo ...`) should use the republished topics, actions, and services. +``` + +In order to prevent overloading the system with too many topics, the number of topics, actions and services that are relayed through the republisher node are limited. The default list of topics, actions and services that are being relayed can be found in the [`create3_republisher` launch parameters](https://github.com/iRobotEducation/create3_examples/blob/humble/create3_republisher/bringup/params.yaml). To optimize the system, update this list to only include the necessary topics, actions and services that are needed. {% endtab %} {% endtabs %} \ No newline at end of file From ba3dcfcb70650b2cf2702b7e08e69612564833c5 Mon Sep 17 00:00:00 2001 From: Chris Iverach-Brereton Date: Tue, 7 Jan 2025 13:56:15 -0500 Subject: [PATCH 2/3] Remove duplicate TOC entries for Discovery Server --- setup/discovery_server.md | 100 +++++++++++++++++++++----------------- 1 file changed, 56 insertions(+), 44 deletions(-) diff --git a/setup/discovery_server.md b/setup/discovery_server.md index 4266c66..174504a 100644 --- a/setup/discovery_server.md +++ b/setup/discovery_server.md @@ -339,6 +339,10 @@ You may also need to call `ros2 topic list` twice to get a full list of topics. ## Example Configuration +### 2 Robots and 1 User Computer + +#### Recommended Architecture + {% tabs discovery %} {% tab discovery galactic %} ```warning @@ -346,13 +350,17 @@ You may also need to call `ros2 topic list` twice to get a full list of topics. ``` There is currently no example for Galactic. - {% endtab %} {% tab discovery humble %} +Each robot is always configured with its own discovery server. This allows each robot to operate independently even if the WiFi is disconnected. Since there are two robots and therefore two discovery servers in the system, the discovery servers must be assigned unique server IDs. In this case, the first robot will be assigned server ID 0 and the second robot will be assigned server ID 1. Similarly, the robots need unique namespaces in order for their topics to be distinguished from each other. In this case they will be assigned as `/robot1` and `/robot2`. -### 2 Robots and 1 User Computer +Although both robots are present in the same system, this example will not include direct inter-robot communication. Each robot's discovery server will be isolated from the other. Instead, the robots will both communicate with the user computer which can be thought of as a command center. This allows for the number of robots to be scaled up while minimizing the load on the network. -#### Recommended Architecture +The user computer will connect to both discovery servers, allowing the user computer to see all of the ROS nodes / topics from each of the robots. Each of the robots will be able to see all of the ROS nodes / topics from the user computer as well. This allows the user computer to send commands to each of the robots, coordinating the system and sharing information across the fleet as necessary. + +Although one could run another discovery server on the user computer, this would add significant load on all of the robots unless done in such a way that the server was isolated from the robot servers. This is not recommended for most use cases. +{% endtab %} +{% tab discovery jazzy %} Each robot is always configured with its own discovery server. This allows each robot to operate independently even if the WiFi is disconnected. Since there are two robots and therefore two discovery servers in the system, the discovery servers must be assigned unique server IDs. In this case, the first robot will be assigned server ID 0 and the second robot will be assigned server ID 1. Similarly, the robots need unique namespaces in order for their topics to be distinguished from each other. In this case they will be assigned as `/robot1` and `/robot2`. Although both robots are present in the same system, this example will not include direct inter-robot communication. Each robot's discovery server will be isolated from the other. Instead, the robots will both communicate with the user computer which can be thought of as a command center. This allows for the number of robots to be scaled up while minimizing the load on the network. @@ -360,9 +368,20 @@ Although both robots are present in the same system, this example will not inclu The user computer will connect to both discovery servers, allowing the user computer to see all of the ROS nodes / topics from each of the robots. Each of the robots will be able to see all of the ROS nodes / topics from the user computer as well. This allows the user computer to send commands to each of the robots, coordinating the system and sharing information across the fleet as necessary. Although one could run another discovery server on the user computer, this would add significant load on all of the robots unless done in such a way that the server was isolated from the robot servers. This is not recommended for most use cases. +{% endtab %} +{% endtabs %} #### Example Robot Setup +{% tabs example21 %} +{% tab example21 galactic %} +```warning +**ROS 2 Galactic is no longer supported.** Please consider upgrading to a newer release +``` + +There is currently no example for Galactic. +{% endtab %} +{% tab example21 humble %} @@ -417,46 +436,8 @@ Although one could run another discovery server on the user computer, this would
Robot 1
- - -#### Example User Computer Setup -From the robot configuration the robot server IDs and the ROS Domain ID are known, and from the robots themselves or the router the IP addresses are known. It is recommended that the robot IPs be reserved on the router so that they always remain the same and this process does not need to be repeated. Running the user computer configuration script as described above, would look as follows: - -``` -ROS_DOMAIN_ID [0]: 0 -Enter the information for the first discovery server -Discovery Server ID [0]: 0 -Discovery Server IP: 192.168.131.5 -Discovery Server Port [11811]: -Re-enter the last server (r), add another server (a), or done (d): a -Enter the information for the next discovery server -Discovery Server ID [0]: 1 -Discovery Server IP: 192.168.131.6 -Discovery Server Port [11811]: -Re-enter the last server (r), add another server (a), or done (d): d -Configuring: - ROS_DOMAIN_ID=0 - ROS_DISCOVERY_SERVER="192.168.131.5:11811;192.168.131.6:11811;" -[sudo] password for cpr-1234: -Source your ~/.bashrc file to apply changes -``` - {% endtab %} -{% tab discovery jazzy %} - -### 2 Robots and 1 User Computer - -#### Recommended Architecture -Each robot is always configured with its own discovery server. This allows each robot to operate independently even if the WiFi is disconnected. Since there are two robots and therefore two discovery servers in the system, the discovery servers must be assigned unique server IDs. In this case, the first robot will be assigned server ID 0 and the second robot will be assigned server ID 1. Similarly, the robots need unique namespaces in order for their topics to be distinguished from each other. In this case they will be assigned as `/robot1` and `/robot2`. - -Although both robots are present in the same system, this example will not include direct inter-robot communication. Each robot's discovery server will be isolated from the other. Instead, the robots will both communicate with the user computer which can be thought of as a command center. This allows for the number of robots to be scaled up while minimizing the load on the network. - -The user computer will connect to both discovery servers, allowing the user computer to see all of the ROS nodes / topics from each of the robots. Each of the robots will be able to see all of the ROS nodes / topics from the user computer as well. This allows the user computer to send commands to each of the robots, coordinating the system and sharing information across the fleet as necessary. - -Although one could run another discovery server on the user computer, this would add significant load on all of the robots unless done in such a way that the server was isolated from the robot servers. This is not recommended for most use cases. - -#### Example Robot Setup - +{% tab example21 jazzy %} @@ -511,9 +492,19 @@ Although one could run another discovery server on the user computer, this would
Robot 1
- +{% endtab %} +{% endtabs %} #### Example User Computer Setup +{% tabs computer21 %} +{% tab computer21 galactic %} +```warning +**ROS 2 Galactic is no longer supported.** Please consider upgrading to a newer release +``` + +There is currently no example for Galactic. +{% endtab %} +{% tab computer21 humble %} From the robot configuration the robot server IDs and the ROS Domain ID are known, and from the robots themselves or the router the IP addresses are known. It is recommended that the robot IPs be reserved on the router so that they always remain the same and this process does not need to be repeated. Running the user computer configuration script as described above, would look as follows: ``` @@ -534,6 +525,27 @@ Configuring: [sudo] password for cpr-1234: Source your ~/.bashrc file to apply changes ``` +{% endtab %} +{% tab computer21 jazzy %} +From the robot configuration the robot server IDs and the ROS Domain ID are known, and from the robots themselves or the router the IP addresses are known. It is recommended that the robot IPs be reserved on the router so that they always remain the same and this process does not need to be repeated. Running the user computer configuration script as described above, would look as follows: +``` +ROS_DOMAIN_ID [0]: 0 +Enter the information for the first discovery server +Discovery Server ID [0]: 0 +Discovery Server IP: 192.168.131.5 +Discovery Server Port [11811]: +Re-enter the last server (r), add another server (a), or done (d): a +Enter the information for the next discovery server +Discovery Server ID [0]: 1 +Discovery Server IP: 192.168.131.6 +Discovery Server Port [11811]: +Re-enter the last server (r), add another server (a), or done (d): d +Configuring: + ROS_DOMAIN_ID=0 + ROS_DISCOVERY_SERVER="192.168.131.5:11811;192.168.131.6:11811;" +[sudo] password for cpr-1234: +Source your ~/.bashrc file to apply changes +``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} From 4790509e95bfe0146d4fa5cfebee0d078cc1de3b Mon Sep 17 00:00:00 2001 From: Chris Iverach-Brereton Date: Tue, 7 Jan 2025 14:02:51 -0500 Subject: [PATCH 3/3] Remove duplicate TOC entries for simple discovery --- setup/simple_discovery.md | 49 ++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 27 deletions(-) diff --git a/setup/simple_discovery.md b/setup/simple_discovery.md index b783bfc..ddc20cd 100644 --- a/setup/simple_discovery.md +++ b/setup/simple_discovery.md @@ -18,11 +18,10 @@ To use the TurtleBot 4 with Simple Discovery, the Create® 3 should be connected The Create® 3 can only be connected to 2.4 GHz Wi-Fi networks. ``` -{% tabs wifi %} -{% tab wifi galactic %} - ### Wi-Fi Setup +{% tabs wifi %} +{% tab wifi galactic %} Access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver), then navigate to the Connect tab. Enter your Wi-Fi SSID and password, and then click 'Connect'. Wait for it to initiate the WiFi connection, and then play a "happy sound" to signal successful connection. This may take a couple minutes. Click on the Connect tab once again and it should now show an IP address if the connection was successful. If the light ring turns yellow during this process, it indicates an error in connection. See [the Create® 3 documentation](https://iroboteducation.github.io/create3_docs/hw/face/) to understand what the different light ring colors indicate. @@ -34,22 +33,8 @@ If the Create® 3 is unable to connect to your 2.4 GHz WiFi network and the ligh Create® 3 connect
Connecting the Create® 3 to Wi-Fi
- -### Application Configuration - -Access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver), then navigate to the Application Configuration tab. -Set ROS 2 Domain ID to 0, ROS 2 Namespace to an empty string, and RMW_IMPLEMENTATION to the [default](networking.md#dds) for your ROS 2 version. Additionally, make -sure that the Fast DDS discovery server is disabled. - -
- Create® 3 config -
Configuring the Create® 3 application for Galactic
-
{% endtab %} {% tab wifi humble %} - -### Wi-Fi Setup - Access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver), then navigate to the Connect tab. Enter your Wi-Fi SSID and password, and then click 'Connect'. Wait for it to initiate the WiFi connection, and then play a "happy sound" to signal successful connection. This may take a couple minutes. Click on the Connect tab once again and it should now show an IP address if the connection was successful. If the light ring turns yellow during this process, it indicates an error in connection. See [the Create® 3 documentation](https://iroboteducation.github.io/create3_docs/hw/face/) to understand what the different light ring colors indicate. @@ -61,9 +46,28 @@ If the Create® 3 is unable to connect to your 2.4 GHz WiFi network and the ligh Create® 3 connect
Connecting the Create® 3 to Wi-Fi
+{% endtab %} +{% tab wifi jazzy %} +The Create® 3 must _not_ be connected to Wifi when using ROS 2 Jazzy. All communication between the Raspberry Pi and the Create® 3 is done over the internal wired connection. The [`create3_republisher`](../software/create3.md#create-3-republisher) node ensures that all ROS 2 topics, services, and actions from the Create® 3 are accessible by other computers on the same wireless network. + +To disconnect the Create® 3 from wi-fi, access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver) and choose the "Forget wi-fi settings" item from the menu at the top of the screen. +{% endtab %} +{% endtabs %} ### Application Configuration +{% tabs application %} +{% tab application galactic %} +Access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver), then navigate to the Application Configuration tab. +Set ROS 2 Domain ID to 0, ROS 2 Namespace to an empty string, and RMW_IMPLEMENTATION to the [default](networking.md#dds) for your ROS 2 version. Additionally, make +sure that the Fast DDS discovery server is disabled. + +
+ Create® 3 config +
Configuring the Create® 3 application for Galactic
+
+{% endtab %} +{% tab application humble %} Use the [`turtlebot4-setup`](../software/turtlebot4_setup.md) tool to configure the Create® 3. You can access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver) and navigate to the Application Configuration tab to confirm the configuration as follows: - ROS 2 Domain ID is `0` - ROS 2 Namespace is empty @@ -75,16 +79,7 @@ Use the [`turtlebot4-setup`](../software/turtlebot4_setup.md) tool to configure
Configuring the Create® 3 application for Humble
{% endtab %} -{% tab wifi jazzy %} - -### Wi-Fi Setup - -The Create® 3 must _not_ be connected to Wifi when using ROS 2 Jazzy. All communication between the Raspberry Pi and the Create® 3 is done over the internal wired connection. The [`create3_republisher`](../software/create3.md#create-3-republisher) node ensures that all ROS 2 topics, services, and actions from the Create® 3 are accessible by other computers on the same wireless network. - -To disconnect the Create® 3 from wi-fi, access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver) and choose the "Forget wi-fi settings" item from the menu at the top of the screen. - -### Application Configuration - +{% tab application jazzy %} Use the [`turtlebot4-setup`](../software/turtlebot4_setup.md) tool to configure the Create® 3. You can access the [Create® 3 webserver](./basic.md#accessing-the-create-3-webserver) and navigate to the Application Configuration tab to confirm the configuration as follows: - ROS 2 Domain ID is `0` - ROS 2 Namespace is `/_do_not_use`