update basic tutorials for foxy (#201)

* update basic tutorials for foxy

Signed-off-by: Mikael Arguedas <[email protected]>

* remove spurious line change

Signed-off-by: Mikael Arguedas <[email protected]>

SROS2_Linux.md

@@ -69,8 +69,8 @@ ros2 security create_keystore demo_keys
 #### Generate keys and certificates for the talker and listener nodes
 
 ```bash
-ros2 security create_key demo_keys /talker
-ros2 security create_key demo_keys /listener
+ros2 security create_key demo_keys /talker_listener/talker
+ros2 security create_key demo_keys /talker_listener/listener
 ```
 
 ### Define the SROS2 environment variables
@@ -100,13 +100,13 @@ Note that secure communication between vendors is not supported.
 Run the `talker` demo program:
 
 ```bash
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker
 ```
 
 In another terminal (after preparing the terminal as previously described), we will do the same thing with the `listener` program.
 
 ```bash
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener
 ```
 
 These nodes will be communicating using authentication and encryption!
@@ -115,12 +115,6 @@ If you look at the packet contents on e.g. Wireshark, the messages will be encry
 Note: You can switch between the C++ (demo_nodes_cpp) and Python (demo_nodes_py) packages arbitrarily.
 
 These nodes are able to communicate because we have created the appropriate keys and certificates for them.
-However, other nodes will not be able to communicate, e.g. the following invocation will fail to start a node with a name that is not associated with valid keys/certificates:
-
-```bash
-# This will fail because the node name does not have valid keys/certificates
-ros2 run demo_nodes_cpp talker --ros-args -r __node:=not_talker
-```
 
 
 ### Run the demo on different machines
@@ -153,14 +147,14 @@ Now, we're ready to run a multi-machine talker/listener demo!
 Once the environment is setup we can run on oldschool:
 
 ```bash
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker
 ```
 
 
 and on feather2
 
 ```bash
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener
 ```
 
 
@@ -181,22 +175,22 @@ svn checkout https://github.com/ros2/sros2/trunk/sros2/test/policies
 And now we will use it to generate the XML permission files expected by the middleware:
 
 ```bash
-ros2 security create_permission demo_keys /talker policies/sample_policy.xml
-ros2 security create_permission demo_keys /listener policies/sample_policy.xml
+ros2 security create_permission demo_keys /talker_listener/talker policies/sample.policy.xml
+ros2 security create_permission demo_keys /talker_listener/listener policies/sample.policy.xml
 ```
 
 These permission files will be stricter than the ones that were used in the previous demo: the nodes will only be allowed to publish or subscribe to the `chatter` topic (and some other topics used for parameters).
 
 In one terminal (after preparing the terminal as previously described), run the `talker` demo program:
 
 ```
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker
 ```
 
 In another terminal (after preparing the terminal as previously described), we will do the same thing with the `listener` program:
 
 ```
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener
 ```
 
 At this point, your `talker` and `listener` nodes should be communicating securely, using explicit access control lists!
@@ -207,5 +201,5 @@ For example, the following attempt for the `listener` node to subscribe to a top
 
 ```bash
 # This will fail because the node is not permitted to subscribe to topics other than chatter.
-ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter
+ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter -e /talker_listener/talker
 ```

SROS2_MacOS.md

@@ -78,8 +78,8 @@ ros2 security create_keystore demo_keys
 #### Generate keys and certificates for the talker and listener nodes
 
 ```bash
-ros2 security create_key demo_keys /talker
-ros2 security create_key demo_keys /listener
+ros2 security create_key demo_keys /talker_listener/talker
+ros2 security create_key demo_keys /talker_listener/listener
 ```
 
 ### Define the SROS2 environment variables
@@ -111,12 +111,12 @@ Note that secure communication between vendors is not supported.
 Run the `talker` demo program:
 
 ```bash
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker
 ```
 
 In another terminal (after preparing the terminal as previously described), we will do the same thing with the `listener` program:
 ```bash
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener
 ```
 
 These nodes will be communicating using authentication and encryption!
@@ -125,12 +125,6 @@ If you look at the packet contents on e.g. Wireshark, the messages will be encry
 Note: You can switch between the C++ and Python packages arbitrarily.
 
 These nodes are able to communicate because we have created the appropriate keys and certificates for them.
-However, other nodes will not be able to communicate, e.g. the following invocation will fail to start a node with a name that is not associated with valid keys/certificates:
-
-```bash
-# This will fail because the node name does not have valid keys/certificates
-ros2 run demo_nodes_cpp talker --ros-args -r __node:=not_talker
-```
 
 
 ### Access Control
@@ -149,22 +143,22 @@ svn checkout https://github.com/ros2/sros2/trunk/sros2/test/policies
 And now we will use it to generate the XML permission files expected by the middleware:
 
 ```bash
-ros2 security create_permission demo_keys /talker policies/sample_policy.xml
-ros2 security create_permission demo_keys /listener policies/sample_policy.xml
+ros2 security create_permission demo_keys /talker_listener/talker policies/sample.policy.xml
+ros2 security create_permission demo_keys /talker_listener/listener policies/sample.policy.xml
 ```
 
 These permission files will be stricter than the ones that were used in the previous demo: the nodes will only be allowed to publish or subscribe to the `chatter` topic (and some other topics used for parameters).
 
 In one terminal (after preparing the terminal as previously described), run the `talker` demo program:
 
 ```
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker
 ```
 
 In another terminal (after preparing the terminal as previously described), we will do the same thing with the `listener` program:
 
 ```
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener
 ```
 
 At this point, your `talker` and `listener` nodes should be communicating securely, using explicit access control lists!
@@ -175,5 +169,5 @@ For example, the following attempt for the `listener` node to subscribe to a top
 
 ```bash
 # This will fail because the node is not permitted to subscribe to topics other than chatter.
-ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter
+ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter -e /talker_listener/talker
 ```

SROS2_Windows.md

@@ -61,8 +61,8 @@ ros2 security create_keystore demo_keys
 #### Generate keys and certificates for the talker and listener nodes
 
 ```bat
-ros2 security create_key demo_keys /talker
-ros2 security create_key demo_keys /listener
+ros2 security create_key demo_keys /talker_listener/talker
+ros2 security create_key demo_keys /talker_listener/listener
 ```
 
 If `unable to write 'random state'` appears then set the environment variable `RANDFILE`.
@@ -105,7 +105,7 @@ call <path_to_ros2_install>/setup.bat
 set ROS_SECURITY_KEYSTORE=%cd%/demo_keys
 set ROS_SECURITY_ENABLE=true
 set ROS_SECURITY_STRATEGY=Enforce
-ros2 run demo_nodes_py talker
+ros2 run demo_nodes_py talker --ros-args --enclave /talker_listener/talker
 ```
 
 Open another terminal:
@@ -115,7 +115,7 @@ call <path_to_ros2_install>/setup.bat
 set ROS_SECURITY_KEYSTORE=%cd%/demo_keys
 set ROS_SECURITY_ENABLE=true
 set ROS_SECURITY_STRATEGY=Enforce
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener
 ```
 
 These nodes will be communicating using authentication and encryption!
@@ -124,12 +124,6 @@ If you look at the packet contents on e.g. Wireshark, the messages will be encry
 Note: You can switch between the C++ (demo_nodes_cpp) and Python (demo_nodes_py) packages arbitrarily.
 
 These nodes are able to communicate because we have created the appropriate keys and certificates for them.
-However, other nodes will not be able to communicate, e.g. the following invocation will fail to start a node with a name that is not associated with valid keys/certificates:
-
-```bat
-REM This will fail because the node name does not have valid keys/certificates
-ros2 run demo_nodes_cpp talker --ros-args -r __node:=not_talker
-```
 
 ### Access Control
 
@@ -147,22 +141,22 @@ svn checkout https://github.com/ros2/sros2/trunk/sros2/test/policies
 And now we will use it to generate the XML permission files expected by the middleware:
 
 ```bat
-ros2 security create_permission demo_keys /talker policies/sample_policy.xml
-ros2 security create_permission demo_keys /listener policies/sample_policy.xml
+ros2 security create_permission demo_keys /talker_listener/talker policies/sample.policy.xml
+ros2 security create_permission demo_keys /talker_listener/listener policies/sample.policy.xml
 ```
 
 These permission files will be stricter than the ones that were used in the previous demo: the nodes will only be allowed to publish or subscribe to the `chatter` topic (and some other topics used for parameters).
 
 In one terminal (after preparing the terminal as previously described), run the `talker` demo program:
 
 ```bat
-ros2 run demo_nodes_cpp talker
+ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker
 ```
 
 In another terminal (after preparing the terminal as previously described), we will do the same thing with the `listener` program:
 
 ```bat
-ros2 run demo_nodes_py listener
+ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener
 ```
 
 At this point, your `talker` and `listener` nodes should be communicating securely, using explicit access control lists!
@@ -173,5 +167,5 @@ For example, the following attempt for the `listener` node to subscribe to a top
 
 ```bat
 REM This will fail because the node is not permitted to subscribe to topics other than chatter.
-ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter
+ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter -e /talker_listener/talker
 ```