Skip to content

Commit

Permalink
Merge pull request #54 from YuZhong-Chen/fix-ros1-bridge-ws
Browse files Browse the repository at this point in the history
Fix ros1_bridge_ws
  • Loading branch information
j3soon authored Aug 27, 2024
2 parents e39b310 + 258589b commit a58cfab
Show file tree
Hide file tree
Showing 6 changed files with 153 additions and 122 deletions.
126 changes: 48 additions & 78 deletions ros1_bridge_ws/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ This workspace is utilized to create a bridge between ROS1 and ROS2-humble.

# ◻️ Introduction ◻️

ros1_bridge provides a network bridge that enables the exchange of messages between ROS 1 and ROS 2.
`ros1_bridge` provides a network bridge that enables the exchange of messages between ROS 1 and ROS 2.
You can locate the original repository [here](https://github.com/ros2/ros1_bridge).

Within this workspace, you'll find a Dockerfile specifically crafted to build both ros-humble and ros1_bridge from their source code.
Expand All @@ -29,6 +29,8 @@ ros1_bridge_ws
├── .devcontainer
| └── devcontainer.json
├── docker
| ├── .dockerignore
| ├── .env
| ├── compose.yaml
| ├── compose.debug.yaml
| ├── Dockerfile
Expand All @@ -38,17 +40,14 @@ ros1_bridge_ws

# 🚩 How to use 🚩

> There are two services in the docker compose, one is `ros1-bridge`, and the other one is `ros1-bridge-build`.
> `ros1-bridge` should be sufficient for normal usage.
> `ros1-bridge-build`, which contains all the necessary build tools, is used for debugging purposes.
> The docker compose includes two services: `ros1-bridge` and `ros1-bridge-build`. The `ros1-bridge` service is typically sufficient for regular use, while `ros1-bridge-build` is intended for debugging, as it retains all the necessary build tools in the docker image.
>
> If you are not debugging ros1-bridge, it is recommended to use the terminal rather than VScode-devcontainer.
> If you are not debugging `ros1-bridge`, it is recommended to use the terminal rather than VScode-devcontainer.
> By default, the VScode-devcontainer uses the `ros1-bridge-build` service.
## 1. Get the docker image
## 1. Build the docker image

While building the image directly from the Dockerfile is possible, it may not be the most efficient choice.
To save time, you can pull the image from Dockerhub instead of compiling it from the source:
While building the image directly from the Dockerfile is possible, it may not be the most efficient choice. To save time, you can pull the image from Dockerhub instead of compiling it from the source.

If you still prefer to build the image yourself, please follow the instructions below:

Expand All @@ -57,132 +56,103 @@ If you still prefer to build the image yourself, please follow the instructions
- Terminal user
- Open a terminal, change the directory to the docker folder, and type `docker compose build`.

> Just so you know, the building process may take approximately 1 hour to complete.
> Please note that the build process may take approximately 1 hour to complete, with potential delays depending on your computer's performance and network conditions.
## 2. Start the container
## 2. Adjust the parameters in the `.env` file

We've placed all ROS-related parameters in the `.env` file. Please adjust these parameters according to your environment. By default, we set the `ROS1` master at `127.0.0.1`, and the `ROS2` domain ID to `0`. These settings should work for most scenarios.

Please note that if these parameters are not configured correctly, the `ros1_bridge` will not function properly!

## 3. Start the container

- VScode user
- If you build the image through the devcontainer, it will automatically start the container.
After you get into the container, type `./start-bridge.sh` in the terminal.
- Terminal user
- Open a terminal, change the directory to the docker folder, and type `docker compose up`.

## 3. Launch rosmaster in ROS1
## 4. Launch rosmaster in ROS1

> This step is automatically executed when you run `docker compose up`.
As mentioned in https://github.com/ros2/ros1_bridge/issues/391, you should avoid using `roscore` in ROS1 to prevent the issue of not bridging `/rosout`.
Instead, use `rosmaster --core` as an alternative.

This command is automatically executed when you run `docker compose up`.

## 4. Begin communication
## 5. Begin communication

You have successfully executed all the instructions.
Now, you can proceed to initiate communication between ROS1 and ROS2-humble.

Please keep in mind that the bridge will be established only when
there are matching publisher-subscriber pairs active for a topic on either side of the bridge.
Please keep in mind that the bridge will be established only when there are matching publisher-subscriber pairs active for a topic on either side of the bridge.

# ✨ Example ✨

## Run the bridge and the example talker and listener

> Before beginning the example, ensure you have three containers ready:
>
> - `ros1_bridge`
> - `ROS1`
> - `ROS2`
>
> All containers are automatically launched when you run `docker compose up`.
>
> Furthermore, ensure that you mount `/dev/shm` into both the `ros1_bridge` and `ROS2` containers,
> and that all containers share the host network.
Before beginning the example, ensure you have four containers ready:

- `ros-core`
- `ros2-ros1-bridge-ws`
- `ros1`
- `ros2`

### 1. Start the rosmaster in `ROS1` container
> When using `ros1-bridge` in your application scenarios, you only need the `ros-core` and `ros2-ros1-bridge-ws` containers. Please replace the `ros1` and `ros2` containers with your application containers, as those are only included for demonstration purposes and are not required for using `ros1-bridge`.
>
> Furthermore, ensure that you mount `/dev/shm` into both the `ros2-ros1-bridge-ws` and `ros2` containers, and that all containers share the host network.
> This container is automatically launched when you run `docker compose up`. No further action is required.
### 1. Start the `ros1_bridge` and other container

```bash
# In ROS 1 container
rosmaster --core &
# In docker folder
docker compose up
```

### 2. Start the `ros1_bridge` container

> This container is automatically launched when you run `docker compose up`. No further action is required.
(Same as [here](#2-start-the-container))

- VScode user
- After getting into the container, type `./start-bridge.sh` in the terminal.
- Terminal user
- ```bash
# In docker folder
docker compose run ros1-bridge
```
This command will start the four containers mentioned above.

### 3. Run the talker and listener node
### 2. Run the talker and listener node

> These containers are automatically launched when you run `docker compose up`. You only need to execeute the commands below.
We run the listener node in the `ros1` container and the talker node in the `ros2` container. You can run the talker node in `ros1` and the listener node in `ros2` if you'd like. To achieve this, modify the command provided below.

Run the listener node in the `ROS1` container and the talker node in the `ROS2` container.
#### ROS1

```bash
docker exec -it ros1 /ros_entrypoint.sh bash
# In ROS 1 container
# Inside ros1 container
rosrun roscpp_tutorials listener
# or
# rosrun roscpp_tutorials talker
```

#### ROS2

```bash
docker exec -it ros2 /ros_entrypoint.sh bash
# In ROS 2 container
# Use the same UID as ros1_bridge to prevent Fast-DDS Shared Memory permission issues.
# Inside ros2 container
# Use the same UID as ros1_bridge to prevent Fast-DDS shared memory permission issues.
# Ref: https://github.com/j3soon/ros2-essentials/pull/9#issuecomment-1795743063
useradd -ms /bin/bash user
su user
source /ros_entrypoint.sh
source /opt/ros/humble/setup.bash
ros2 run demo_nodes_cpp talker
# or
# ros2 run demo_nodes_cpp listener
```

> You can run the talker node in `ROS1` and the listener node in `ROS2` if you'd like.
> To achieve this, simply modify the command provided above.
Certainly, you can try the [example](https://github.com/ros2/ros1_bridge#example-1-run-the-bridge-and-the-example-talker-and-listener) provided by `ros1_bridge`.
However, there's no need to source the setup script within the `ros1_bridge` container,
simply starting the container will suffice.
Certainly, you can try the [example](https://github.com/ros2/ros1_bridge#example-1-run-the-bridge-and-the-example-talker-and-listener) provided by `ros1_bridge`. However, there's no need to source the setup script within the `ros2-ros1-bridge-ws` container, simply starting the container will suffice.

# 🔍 Troubleshooting 🔍

> If you are trying to debug ros1_bridge, it is recommended to use the `ros1-bridge-build` service in docker compose.
> It contains all the necessary build tools, which should be helpful for you.

## Failed to contact master

Before launching the master, make sure you have set the `ROS_MASTER_URI`.
Execute the following command to configure it.
> If you are trying to debug `ros1_bridge`, it is recommended to use the `ros1-bridge-build` service in docker compose. It contains all the necessary build tools, which should be helpful for you.
```bash
export ROS_MASTER_URI=http://localhost:11311
```

You can replace localhost with the actual IP address or hostname of your ROS Master.
This command ensures that your ROS nodes know where to find the ROS Master for communication.
## Failed to contact ros master

If you've modified the default URI, please execute the `start-bridge.sh` script with the new URI address to ensure proper configuration and communication.
Before launching `ros-core`, make sure to adjust the `ROS_MASTER_URI` correctly. For more information, please check the `.env` file and [this section](#2-adjust-the-parameters-in-the-env-file).

For example, if you've changed the default URI to `127.0.0.1`, you should make the following modification to the `compose.yaml`:

```bash
command: ./start-bridge.sh http://127.0.0.1:11311
```
You can replace `127.0.0.1` with the actual IP address or hostname of your ros master. This configuration ensures that your ros nodes know where to find the ros master for communication. Remember, in addition to modifying the parameters for `ros1_bridge`, you also need to adjust the parameters for your own container!

## ROS2 can't receive the topic

The latest releases of Fast-DDS come with the SharedMemory transport enabled by default.
Therefore, you need to mount shared memory, also known as `/dev/shm`, into every container you intend to communicate with when using Fast-DDS. This ensures proper communication between containers.
Ensure that you use the same UID as `ros1-bridge` to avoid Fast-DDS shared memory permission issues.
The latest releases of Fast-DDS come with the shared memory transport enabled by default. Therefore, you need to mount shared memory, also known as `/dev/shm`, into every container you intend to communicate with when using Fast-DDS. This ensures proper communication between containers. Ensure that you use the same UID as `ros2-ros1-bridge-ws` to avoid Fast-DDS shared memory permission issues.

Reference: https://github.com/eProsima/Fast-DDS/issues/1698#issuecomment-778039676
1 change: 1 addition & 0 deletions ros1_bridge_ws/docker/.dockerignore
Original file line number Diff line number Diff line change
@@ -1,2 +1,3 @@
*
!start-bridge.sh
!.env
6 changes: 6 additions & 0 deletions ros1_bridge_ws/docker/.env
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
# ROS1
ROS_HOSTNAME: 127.0.0.1
ROS_MASTER_URI: http://127.0.0.1:11311
# ROS2
ROS_DOMAIN_ID: 0
ROS_LOCALHOST_ONLY: 0
Loading

0 comments on commit a58cfab

Please sign in to comment.