You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Remove references to dedicated ROS distros
as final ROS 1 version, Noetic, is now EOL
* Redirect primary links to documentation landing page
as docs page is more up-to-date and pertinent for users
* Remove retired ROS blog
- https://www.ros.org/news/2020/01/ros-blog-retired.html
* Update OSRF URL redirect
* Update example image tag to rolling
to avoid docs from becoming stale
* Consolidate branding and dated references
* Update Q&A links to stackexchange given migration
- https://discourse.ros.org/t/planned-migration-of-ros-answers-and-gazebo-answers-to-robotics-stack-exchange/28068
- https://discourse.ros.org/t/new-static-archives-for-ros-and-gazebo-answers/41346
* Simplify cloning overlay source
* Simplify use of mixin setting
* Split runner and builder stages
as example to save on image size
as well as on build time using caching
* Simplify scripting for dependencies
* Lint use of ARGs
for readability of each stage
* Simplify example cache mount for apt
and update rosdep along with apt list
to ensure package index is fresh
* Update categories for ROS
to include additional relevant entries
* Shorten derivation script
* Use ros-core tag for minimal installer
* Stage example image sizes for demos
* Simplify naming
* Omit cacher from size table
to focus on primary targets
* Modify and mount custom apt config
accounting for included docker-clean default
* Simplify RUN directive for apt config
* Stage WIP edits
* Update package cache before cloning source
to avoid running rosdep update for each source change
as docker build --no-cache can still be used to force update
* Fix use of EOF in Dockerfile
* Simply RUN directives
* Expand bullet points about optimizations
* Expand upon runner vs installer comparison
* Linting
* Fix grammar and spelling
* Linting
* Rename stage in apt get example
while keeping with uniquely spelled noun
that is self descriptive yet unmistakable
* Comment on overwriting defaults to persist minimal cache
The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it's all open source.
@@ -13,7 +13,7 @@ The Robot Operating System (ROS) is a set of software libraries and tools that h
13
13
To create your own ROS docker images and install custom packages, here's a simple example of installing the C++, Python client library demos using the official released Debian packages via apt-get.
Note: all ROS images include a default entrypoint that sources the ROS environment setup before executing the configured command, in this case the demo packages launch file. You can then build and run the Docker image like so:
29
29
30
30
```console
31
-
$ docker build -t my/ros:app.
32
-
$ docker run -it --rm my/ros:app
31
+
$ docker build -t my/ros:aptgetter.
32
+
$ docker run -it --rm my/ros:aptgetter
33
33
[INFO] [launch]: process[talker-1]: started with pid [813]
34
34
[INFO] [launch]: process[listener-2]: started with pid [814]
35
35
[INFO] [talker]: Publishing: 'Hello World: 1'
@@ -44,59 +44,85 @@ $ docker run -it --rm my/ros:app
44
44
To create your own ROS docker images and build custom packages, here's a simple example of installing a package's build dependencies, compiling it from source, and installing the resulting build artifacts into a final multi-stage image layer.
The example above starts by using [`vcstool`](https://github.com/dirk-thomas/vcstool) to clone source repos of interest into the cacher stage. One could similarly `COPY` code from the local build context into the source directory as well. Package manifest files are then cached in a temporary directory where the following builder stage may copy from to install necessary dependencies with [`rosdep`](https://github.com/ros-infrastructure/rosdep). This is done prior to copying the rest of the source files to preserve the multi-stage build cache, given unaltered manifests do not alter declared dependencies, saving time and bandwidth. The overlay is then built using [`colcon`](https://colcon.readthedocs.io/en/released/), the entrypoint updated to source the workspace, and the default command set to launch the demo.
134
+
The example above consists of three sequential stages. The `cacher` stage first updates the apt lists and ROS index, uses [`vcstool`](https://github.com/dirk-thomas/vcstool) to clone a demo repo into the workspace source directory, and derives build and runtime dependency sets using [`rosdep`](https://docs.ros.org/en/rolling/Tutorials/Intermediate/Rosdep.html). The `builder` stage installs the derived build dependencies, sources the ROS install underlay, and compiles the source in release mode using [`colcon`](https://docs.ros.org/en/rolling/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html). Finally, the `runner` stage installs only runtime dependencies, copies the compiled workspace artifacts, and sets up the environment to launch the demo. Note the example consists of several subtle optimizations:
135
+
136
+
- Multi-Stage Build
137
+
- Dependency derivation, compilation, and runtime setup are partitioned
138
+
- Maximizes cache retention despite package source or build/runtime changes
139
+
- Greater concurrency, e.g., colcon build while runtime apt installs
140
+
- Persistent Cache Propagation
141
+
- Use of [`--mount`](https://docs.docker.com/engine/reference/builder/#run---mount) to cache temp data without bloating layers
142
+
- Maintain temporally consistent apt lists between parallel stages
143
+
- Avoid needless network I/O between stages or across Docker rebuilds
144
+
- Minimal Image Size
145
+
- Final stage builds from `ros-core` for smallest runtime image
146
+
- Builds and installs only a select few packages in the workspace
147
+
- Only workspace install artifacts are copied into final layers
109
148
110
-
Note: `--from-paths` and `--packages-select` are set here as so to only install the dependencies and build for the demo C++ and Python packages, among many in the demo git repo that was cloned. To install the dependencies and build all the packages in the source workspace, merely change the scope by setting `--from-paths src/` and dropping the `--packages-select` arguments.
149
+
For comparison, the resulting `runner` image is similar in size to the earlier `aptgetter` example. This allows you to develop and distribute custom ROS packages without significantly increasing image size compared to pre-built Debian installations:
111
150
112
-
For more advance examples such as daisy chaining multiple overlay workspaces to improve caching of docker image build layers, using tools such as ccache to accelerate compilation with colcon, or using buildkit to save build time and bandwidth even when dependencies change, the project `Dockerfile`s in the ROS 2 [Navigation2](https://github.com/ros-planning/navigation2) repo are excellent resources.
151
+
```console
152
+
$ docker image ls my/ros --format "table {{.Tag}}\t{{.Size}}"
153
+
TAG SIZE
154
+
aptgetter 504MB
155
+
runner 510MB
156
+
builder 941MB
157
+
$ docker image ls ros --format "table {{.Tag}}\t{{.Size}}"
158
+
TAG SIZE
159
+
rolling-ros-core 489MB
160
+
rolling 876MB
161
+
```
162
+
163
+
For more advance examples such as daisy chaining multiple overlay workspaces to improve caching of docker image build layers, using tools such as ccache to accelerate compilation with colcon, or using buildkit to save build time and bandwidth even when dependencies change, the project `Dockerfile`s in the [Navigation2](https://github.com/ros-planning/navigation2) repo are excellent resources.
113
164
114
165
## Deployment use cases
115
166
@@ -119,19 +170,18 @@ Developing such complex systems with cutting edge implementations of newly publi
119
170
120
171
With the advancements and standardization of software containers, roboticists are primed to acquire a host of improved developer tooling for building and shipping software. To help alleviate the growing pains and technical challenges of adopting new practices, we have focused on providing an official resource for using ROS with these new technologies.
121
172
122
-
For a complete listing of supported architectures and base images for each ROS Distribution Release, please read the official REP on target platforms for either [ROS 1](https://www.ros.org/reps/rep-0003.html) or for [ROS 2](https://www.ros.org/reps/rep-2000.html).
173
+
For a complete listing of supported architectures and base images for each ROS Distribution Release, please read the official REP on target platforms [here](https://www.ros.org/reps/rep-2001.html).
123
174
124
175
## Deployment suggestions
125
176
126
177
The available tags include supported distros along with a hierarchy tags based off the most common meta-package dependencies, designed to have a small footprint and simple configuration:
127
178
128
179
-`ros-core`: minimal ROS install
129
180
-`ros-base`: basic tools and libraries (also tagged with distro name with LTS version as `latest`)
130
-
-`ros1-bridge`: tools and libraries to run hybrid ROS 1 - ROS 2 systems and bridge messages between them
131
181
132
182
In the interest of keeping `ros-core` tag minimal in image size, developer tools such as `rosdep`, `colcon` and `vcstools` are not shipped in `ros_core`, but in `ros-base` instead.
133
183
134
-
The rest of the common meta-packages such as `desktop` are hosted on repos under OSRF's Docker Hub profile [here](https://hub.docker.com/r/osrf/ros/). These meta-packages include graphical dependencies and hook a host of other large packages such as X11, X server, etc. So in the interest of keeping the official images lean and secure, the desktop packages are just being hosted with OSRF's profile. For an extensive list of available variants, please read the official REP on target platforms for either [ROS 1](https://ros.org/reps/rep-0150.html) or for [ROS 2](https://www.ros.org/reps/rep-2001.html).
184
+
The rest of the common meta-packages such as `desktop` are hosted on repos under OSRF's Docker Hub profile [here](https://hub.docker.com/r/osrf/ros/). These meta-packages include graphical dependencies and hook a host of other large packages such as X11, X server, etc. So in the interest of keeping the official images lean and secure, the desktop packages are just being hosted with OSRF's profile.
135
185
136
186
### Volumes
137
187
@@ -201,59 +251,10 @@ $ docker compose rm
201
251
202
252
> Note: the auto-generated network, `ros_demos_default`, will persist until you explicitly remove it using `docker compose down`.
203
253
204
-
### ROS 1 Bridge
205
-
206
-
To ease ROS 2 migration, [`ros1_bridge`](https://index.ros.org/p/ros1_bridge) is a ROS 2 package that provides bidirectional communication between ROS 1 and ROS 2. As a minimal example, given the ROS 2 Dockerfile above, we'll create the ROS 1 equivalent below, and name the Dockerfile appropriately.
The compose file bellow spawns services for both talker listener demos while connecting the two via a dynamic bridge. You may then view the log output from both pairs of talker and listener nodes cross talking over the `/chatter` topic.
222
-
223
-
```yaml
224
-
services:
225
-
ros1:
226
-
build:
227
-
context: ./
228
-
dockerfile: ros1.Dockerfile
229
-
230
-
ros2:
231
-
build:
232
-
context: ./
233
-
dockerfile: ros2.Dockerfile
234
-
235
-
bridge:
236
-
image: ros:foxy-ros1-bridge
237
-
environment:
238
-
- "ROS_HOSTNAME=bridge"
239
-
- "ROS_MASTER_URI=http://ros1:11311"
240
-
command: ros2 run ros1_bridge dynamic_bridge
241
-
```
242
-
243
254
# More Resources
244
255
245
-
[ROS.org](http://www.ros.org/): Main ROS website
246
-
[Q&A](https://answers.ros.org/questions/): Ask questions. Get answers
0 commit comments