Behavior control of ROS containers in Docker on distal turtlebot

behavior control of ROS containers in Docker on distal Turtlebot

Docker's existing network model is simple, scalability and flexibility do not meet the needs of many complex scenarios, most of the time users need to customize the Docker container network, rather than using Docker created by default IP and NAT rules.

In the previous blog post, we explained how to view the Rosnode, Rostopic, etc. running on the remote host in the Ros container, but it has not realized two-way communication. A basic two-way communication is that the Ros container in the local host can control the movement of the Turtlesim small turtle in the remote host with the upper and lower left arrows of the keyboard. This section describes the implementation of this process. 1. Configure the Ros container in Docker to the local network

In last week's experiment, the main reason for not communicating in two directions was that the remote host (198.x.x.x) "Could not find" the local Ros container's IP (172.x.x.x). This is obvious because the Ros container's IP is assigned by Docker on the local host, mounted to the Docker0 bridge. The IP assigned on the host is not visible to the external host. The external performance of the IP of the Ros container is actually the IP of the local host.

Then we need to change the default mechanism to reconfigure the ROS container's IP to the local network, which is visible to the remote host.

If you want to have the Docker container and the container host on the same network, then the container and the host should be in a two-tier network. The conceivable scenario is to connect the two machines to the same switch or to a different cascade switch. In the virtual scene, the virtual bridge can connect the container to a two-tier network, as long as the host's network card is bridged to the virtual bridge, the container and the host can be connected together. After building this topology (with a map), you only need to assign a local LAN IP to the Docker container. The experimental ideas are also verified in the later experiments. Two-way communication between the ROS container and the remote Turtlebot host.

In the following, the local network is 192.168.1.0/24, the gateway is 192.168.1.254, the IP of the remote host Turtlebot is 192.168.1.103 Local host IP is 192.168.1.100 (NIC is eth0), The local host launches a Docker container named Rostest2 and configures it with a local IP of 192.168.1.97/24. Because the default mechanism of Docker is not required to provide a network for-DOCKER0, the--net=none parameter is used when the container is started by mirroring. The process is as follows:

(1) Launch a Docker container named Rostest2

$ sudo docker run-idt--name=rostest2--net=none Ros:indigo-robot/bin/bash

(2) Create a bridge for the container connection Brros

$ sudo brctl addbr brros
$ sudo ip link set brros up

(3) bridge the host eth0 to the Brros and configure the eth0 to Brros, then configure the Brros route

$ sudo ip addr add 192.168.1.100/24 dev brros
$ sudo ip addr del 192.168.1.100/24 dev eth0
$ sudo brctl addif Brro S eth0
$ sudo ip route del default
$ sudo ip route add default via 192.168.1.254 Dev Brros

(4) Find Rostest2 in the host's process PID value, save to Pidros

$ pidros=$ (sudo docker inspect--format ' {. State.pid}} ' Rostest2)

(5) Add the network namespace of the container to the/var/run/netns directory

$ sudo mkdir-p/var/run/netns
$ sudo ln-s/proc/$pidROS/ns/net/var/run/netns/$pidROS

(6) Create a virtual network card device that connects the Brros Bridge and Docker's Ros container veth-a, Veth-b, and place veth-a in the Brros bridge

$ sudo ip link add veth-a type Veth Peer name veth-b
$ sudo ip link add veth-b type Veth Peer name veth-a
$ sudo B Rctl addif brros veth-a
$ sudo ip link set veth-a up

Use the Brctl Show command to view the device mounts on the Brros Bridge for eth0 (native NIC) and Veth-a

(7) Place the Veth-b in the network namespace of the container rostest2. Rename to eth0 and configure IP and default routing for it.

$ sudo ip link set veth-b netns $pidROS
$ sudo ip netns exec $pidROS IP link set dev veth-b name eth0
$ sudo ip ne TNS EXEC $pidROS IP link set eth0 up
$ sudo ip netns exec $pidROS IP addr add 192.168.1.97/24 dev eth0
$ sudo ip n ETNs exec $pidROS IP route add default via 192.168.1.254

PS. Veth-b renamed to Eth0 because the Docker container from the container name eth0 virtual network card for data transmission, do not change the name can not be transferred, during the experiment with the pipework tool for the container configured IP, but the virtual network card is eth1, The container is still transmitted with the default eth0, as shown in the following figure
2. Complete the network topology diagram for the above steps

By logging on to the local router interface, you can discover the Rostest2 container and be configured to
In the local network

In the figure, the four IPs in turn correspond to the following:

name	IP	explain
Chenming	192.168.1.104	I Windows host, view router
Anonymous host	192.168.1.97	New configuration IP for Docker container rostest2
Mingchen-hp	192.168.1.100	My Ubuntu host, a real host with a DOCKER,ROSTEST2 container
Turtlebot-x555li	192.168.1.103	Remote Turtlebot host, equipped with Ros system, running Turtlesim test Little Turtle

Can ping the Turtlebot host in the container
3. Control Experiments

After completing the above configuration and checking, continue with the problems in the previous blog post, run the command Rosrun Turtlesim Turtle_teleop_key in the Rostest2 container:

root@f8289b197a45:/# Rosrun Turtlesim Turtle_teleop_key

Get tips:

And look at the remote Turtlebot host on the Small turtle movement

On the right side of the image, you can see the ping container and two-way communication.

Therefore, this method is done experimentally.