Announce 2025 06 30

.github/workflows/build.yml

@@ -0,0 +1,24 @@
+name: Test Build
+
+on:
+  pull_request:
+    branches:
+      - main
+    # Review gh actions docs if you want to further define triggers, paths, etc
+    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on
+
+jobs:
+  build:
+    name: Build Site
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: yarn
+
+      - name: Install dependencies
+        run: yarn install --frozen-lockfile
+      - name: Build website
+        run: yarn build

README.md

@@ -39,3 +39,4 @@ $ GIT_USER=<Your GitHub username> yarn deploy
 ```
 
 If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
+

blog/2024-09-25-florian-pokorny-cloudgripper/index.md

@@ -0,0 +1,24 @@
+---
+title: "Florian Pokorny presents CloudGripper"
+slug: florian-pokorny-cloudgripper
+authors: michaelhart
+tags: [ros, cloudgripper, guest]
+---
+
+[Florian Pokorny](https://www.csc.kth.se/~fpokorny/), Associate Professor of Machine Learning at [KTH Royal Institute Technology](https://www.kth.se/) and Co-Founder of [Scaleup Robotics](https://scaleuprobotics.com/), joined our meeting on 2024-09-23. He gave a talk on [CloudGripper, An Open Source Cloud Robotics Testbed for Robotic Manipulation Research, Benchmarking and Data Collection at Scale](https://cloudgripper.org/). He then answered questions on the talk, along with [Muhammed Zahid](https://www.linkedin.com/in/zahid-muhammad/), who led the development work on the CloudGripper system and also co-founded Scaleup Robotics with Florian.
+
+Take a look at the recording of the talk using the link below:
+
+<iframe class="youtube-video" src="https://www.youtube.com/embed/-j5eGF11vKk?si=Vs5oRn_PiM97Efuf" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+
+<!-- truncate -->
+
+Florian explained the necessity of large quantities of data when training models for robotics, along with using simulations to generate that data. He then went on to describe how simulation wasn't always useful for training models for the real world, hence building a setup of 32 simple grippers for gathering data on deformable objects.
+
+This fleet of 32 robots is open to the public for experimentation - check the [CloudGripper](https://cloudgripper.org/) link for more information on how to access the robots. Access is free, as long as you are willing to share the data you collect!
+
+Scaleup Robotics, the startup founded by Florian and Zahid, is focusing on educiation use cases of cloud robotics and has now designed a commercial version of the robot. This will allow the team to deploy more  robots. The team is also still developing the robot design, such as providing ROS interfaces and automating access to the robots.
+
+:::info
+The Cloud Robotics Working Group is always on the lookout for more guest speakers. If you have a talk you would like to give or a suggestion of another speaker who may be interested, please [let us know](/meetings)!
+:::

blog/2024-10-09-eric-chen-fogros2/index.md

@@ -0,0 +1,32 @@
+---
+title: "Kaiyuan Eric Chen presents FogROS2"
+slug: eric-chen-fogros2
+authors: michaelhart
+tags: [ros, fogros2, guest]
+---
+
+## Enabling Usable and Reliable Cloud Robotics with FogROS2
+
+[Kaiyuan Eric Chen](https://keplerc.github.io/), a PhD student in the Department of Computer Sciences at UC Berkeley and a member of Berkeley Automation Lab working closely with Ken Goldberg and Jeffrey Ichnowski, joined our meeting on 2024-10-07. He gave a talk titled "Enabling Usable and Reliable Cloud Robotics with FogROS2". He then answered questions on the talk and on [FogROS2](https://berkeleyautomation.github.io/FogROS2), a state-of-the-art open source cloud robotics framework that offloads unmodified ROS2 applications to the cloud.
+
+Take a look at the recording of the talk using the link below:
+
+<iframe class="youtube-video" src="https://www.youtube.com/embed/OISBgMuVWf4?si=ZoMrmwUkDlM-GInS" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+
+<!-- truncate -->
+
+Eric started by defining Cloud Robotics, pointing out that many applications we don't consider to be Cloud Robotics do actually involve the cloud. He then explained how the cloud helped his research team by speeding up tasks such as planning, and that provisioning the cloud resources led to FogROS, a framework that helped with provisioning the resources. Eric explained the iterations of FogROS and FogROS2, including case studies of their use and improvements in performance over local operation.
+
+The talk then went on to the reliability aspect of the title. Cloud connections have many points of failure, any one of which causes the application to fail. Eric explained his team's work on proving that multiple simultaneous connections improved the usability and reliability of Cloud Robotics, showing his work and several key examples.
+
+Finally, Eric answered questions from the group, such as whether to handle transmission failures at the Operating System layer or the application layer, the different models used for comparing responses between simultaneous connections, and how to handle lack of all connection, known as the concert hall problem.
+
+These links are provided from the presentation and directly from Eric:
+
+- [FogROS2 repository](https://github.com/BerkeleyAutomation/FogROS2): contains the source code and description of FogROS2.
+- [Fog-RTC x CloudGripper Dataset Visualizer](https://berkeleyautomation.github.io/CloudRobotics_tutorial/): shows the CloudGripper visualization using FogROS2, and collected at ICRA 2024. For more information about CloudGripper, take a look at [Florian Pokorny's presentation](/blog/florian-pokorny-cloudgripper).
+- [Leveraging Cloud Computing to Make Autonomous Vehicles Safer](https://arxiv.org/abs/2308.03204): shows work in executing a workload both locally and in the cloud, and comparing the response, for the best safety in autonomous vehicles.
+
+:::info
+The Cloud Robotics Working Group is always on the lookout for more guest speakers. If you have a talk you would like to give or a suggestion of another speaker who may be interested, please [let us know](/meetings)!
+:::

blog/2024-11-04-julien-enoch-zenoh/index.md

@@ -0,0 +1,25 @@
+---
+title: "Julien Enoch presents Eclipse Zenoh"
+slug: julien-enoch-zenoh
+authors: michaelhart
+tags: [ros, zenoh, guest]
+---
+
+[Julien Enoch](https://www.linkedin.com/in/julienenoch/), a Senior Solutions Architect at [ZettaScale Technology](https://www.zettascale.tech/) and [Eclipse Zenoh](https://github.com/eclipse-zenoh/zenoh) committer, joined our meeting on 4th November 2024. He gave a talk on Eclipse Zenoh, a protocol which can run everywhere, from micro-controllers to the Cloud; over TCP, UDP, QUIC, and Websockets. Zenoh provides a software router that can be deployed in any Cloud instance such as AWS EC2, and that can route the protocol between different subsystems.
+
+<iframe class="youtube-video" src="https://www.youtube.com/embed/ANBG_O0fQwQ?si=X3zJtsKlXY6e-3HM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+
+<!-- truncate -->
+
+Julien started by talking about how the Zenoh protocol works, including the software router and example network diagrams. Zenoh is written in Rust, is available in many languages, comes with built-in messaging features like fragmentation and batching, and can operate over any data link, including TCP, Serial, Bluetooth, and so on.
+
+Julien showed how fast the protocol can perform compared to other solutions, and how it's possible to extend the protocol using plugins. He also demonstrated using RViz to control a Turtlebot 4 via Zenoh, where one machine was in France and another in California, United States.
+
+The talk then went on to where the protocol could run, how it could discover other nodes, and how to update network configuration without making code changes. This also includes TLS encryption on the link.
+
+Finally, Julien answered questions from the group, including the maturity of JavaScript language support, how multi-router discovery works, and access control options for Zenoh. For more detail on any of these points, watch the recording above for the full talk!
+
+:::info
+The Cloud Robotics Working Group is always on the lookout for more guest speakers. If you have a talk you would like to give or a suggestion of another speaker who may be interested, please [let us know](/meetings)!
+:::
+

blog/2024-12-09-phil-roan-zenoh-and-turtlebot/index.md

@@ -0,0 +1,111 @@
+---
+title: "Switching to Zenoh"
+slug: phil-roan-zenoh-and-turtlebot
+authors: philiproan
+tags: [guest, ros, zenoh, turtlebot]
+---
+
+Inspired by Julien Enoch's presentation on Eclipse Zenoh ([meeting on 2024-11-04](/meetings)) and our attempts two weeks later to test Zenoh as a ROS 2 middleware ([meeting on 2024-12-02](/meetings)), I decided to upgrade my Turtlebot2 reference platform to use Zenoh. In particular, I wanted to duplicate the existing ability to control the robot using RViz from a separate computer.
+
+## tl;dr
+All files can be found at [https://github.com/ingotrobotics/turtlebot2_ros2/tree/feature/zenoh](https://github.com/ingotrobotics/turtlebot2_ros2/tree/feature/zenoh). Issues, pull requests, and all other commentary are encouraged.
+
+## Background
+Before I jump in, let me provide some background on my reference platform. I use a Turtlebot2 (built on the [Kobuki platform](https://github.com/kobuki-base/kobuki_core)) with a [Hokuyo URG](https://www.hokuyo-aut.jp/search/single.php?serial=166) planar laser scanner for navigation. An [Intel RealSense D435](https://www.intelrealsense.com/depth-camera-d435/) camera provides RGB and depth images, and an Intel NUC provides the compute. The robot runs ROS 2 Humble, Iron, or Jazzy from a Docker container. There is no ROS installed natively on the robot. Not all of the Turtlebot2 packages are available as `apt` packages, so part of the container building process involves building those packages from source. Containers are built by a Jenkins instance and hosted on a private Docker registry. More details can be found in the [Dockerfile](https://github.com/ingotrobotics/turtlebot2_ros2/blob/main/turtlebot2_ros2.dockerfile).
+
+## Add Zenoh to Container
+To add Zenoh support to the container, I added the following lines to my Dockerfile:
+```
+# Install Zenoh
+RUN mkdir -p "$ROBOT_WORKSPACE/src" && \
+    git clone https://github.com/ros2/rmw_zenoh.git "$ROBOT_WORKSPACE/src/rmw_zenoh"
+RUN apt-get update && \
+    rosdep install --from-paths ./src -y --ignore-src && \
+    rm -rf /var/lib/apt/lists/*
+RUN source "/opt/ros/$ROS_DISTRO/setup.bash" && \
+    colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release
+
+# Set ROS to use Zenoh as the middleware 
+RUN echo "export RMW_IMPLEMENTATION=rmw_zenoh_cpp" >> /root/.bashrc && \
+    echo "export RUST_LOG=info" >> /root/.bashrc
+```
+
+Like in the [meeting on 2024-12-02](/meetings), I am referencing the [Zenoh ROSCon workshop materials](https://github.com/ZettaScaleLabs/roscon2024_workshop). As you see in that meeting, I was able to get communication working between three containers on the same machine, but I was not able to get communication to work between two separate machines. So after building Zenoh support into the Turtlebot container, I started at [Exercise 2](https://github.com/ZettaScaleLabs/roscon2024_workshop/blob/main/exercises/ex-2.md). The key step here is copying and editing the router configuration file. 
+
+I spent a lot of time sorting out why the config file in the workshop materials was not running before I realized it had been updated recently and the update introduced a [bug](https://github.com/ZettaScaleLabs/roscon2024_workshop/issues/12) for the version of Zenoh I installed. This is a nice reminder that while version 1.0.0 has been released, `rmw_zenoh` is still under quite a bit of active development.
+
+If you've never switched away from the default ROS2 DDS middleware, it can be easy to forget to set the `RMW_IMPLEMENTATION` environment variable, which is what actually makes the switch happen. This has to be done in every Bash instance if changing away from the default. `ros2 doctor --report` will show the active ROS middleware. Common alternatives to `rmw_zenoh_cpp` are `rmw_fastrtps_cpp`, `rmw_fastrtps_dynamic_cpp`, or `rmw_cyclonedds_cpp`.
+
+## Network Topology
+For my reference platform, the topology of a router running on each device (robot and developer computer) is a great setup and is shown in this diagram: [![Diagram from ROSCon workshop showing two containers, each with a Zenoh router](https://raw.githubusercontent.com/ZettaScaleLabs/roscon2024_workshop/0ccbaa88f32c47eb9f1d19b203dac27a15e794e2/exercises/pictures/talker-listener-2-containers.png)](https://raw.githubusercontent.com/ZettaScaleLabs/roscon2024_workshop/0ccbaa88f32c47eb9f1d19b203dac27a15e794e2/exercises/pictures/talker-listener-2-containers.png). Not every system will need or benfit from this topology, but in my case, the configuration is very simple and it also simplifies the ROS 2 network traffic between my two devices.
+
+For this topology, only one device needs to use the customized config file that provides the address of the other device. With my reference platform, I typically use one robot but multiple development devices or containers, which means I should have the config file on the development devices providing the address of the robot. I mentioned earlier that the robot does not have a native ROS installation, and neither do my development devices; they run container images built using the same Dockerfile as the robot only they are based on the `-desktop` [images provided by OSRF](https://hub.docker.com/r/osrf/ros/tags). This means that I'll have the default config file copied to the appropriate location in the Dockerfile, and setting the necessary environment variable (`ZENOH_ROUTER_CONFIG_URI`) for Zenoh to use it will happen in the command to launch the development container.
+
+Copying the router config file adds one more line to the Dockerfile:
+```
+RUN mkdir -p "$ROBOT_WORKSPACE/zenoh_confs" && \
+    cp "$ROBOT_WORKSPACE/src/rmw_zenoh/rmw_zenoh_cpp/config/DEFAULT_RMW_ZENOH_ROUTER_CONFIG.json5" "$ROBOT_WORKSPACE/zenoh_confs/ROUTER_CONFIG.json5"
+```
+
+It would not be good practice for me to publish the IP address of my robot on GitHub, even for a reference implementation, so I have replaced it with an environment variable, `ZENOH_TARGET` that is specified as part of the `docker run` command. Since I don't know enough about how Zenoh parses the config file, I use `sed` to replace the value in the config file rather than leaving the Bash environment variable:
+```
+sed -i "s|// \"<proto>/<address>\"|\"$ZENOH_TARGET\"|" "$ROBOT_WORKSPACE/zenoh_confs/ROUTER_CONFIG.json5"
+```
+This is brittle because the default config file is likely to change as Zenoh develops and as more ROS users migrate to it. If you have a better way to accomplish this, I'd be interested in seeing it.
+
+## Launching Zenoh Router and ROS Nodes
+One last challenge is that I am launching the Zenoh router separately from my other launch files, which requires running two processes in the container. It looks like there is on-going work to simplify this in the `rmw_zenoh` repos.
+
+To accomplish launching the router and my other ROS processes in a "quick and dirty" manner, I have written a [little script](https://github.com/ingotrobotics/turtlebot2_ros2/blob/feature/zenoh/background_zenoh_router.sh) to run the router in the background. This script also handles the address replacement from the environment variable passed in when starting the container. These commands should probably be incorporated into the robot's launch file, and I should write a launch file incorporating these commands for launching RViz as well. Look for that improvement soon.
+
+## So does it work?
+Mostly. Here's a screenshot of RViz showing the robot, laser scans, map, and RGB camera output. ![Screenshot of RViz showing Turtlebot2 exploring a room with laser scan points in yellow.](rviz_screenshot.png)
+I was able to drive the robot using `teleop_twist_keyboard`, but I was not able to use RViz to successfully send a goal point.
+
+There are some issues starting up the Nav2 stack, and relaunching will sometimes produce different errors. Here are two samples:
+```
+[lifecycle_manager-17] [INFO] [1733773169.631170992] [lifecycle_manager_navigation]: Waiting for service bt_navigator/get_state...
+[lifecycle_manager-17] [INFO] [1733773171.631518706] [lifecycle_manager_navigation]: Waiting for service bt_navigator/get_state...
+```
+```
+[opennav_docking-16] [ERROR] [1733772743.456351127] [rmw_zenoh_cpp]: topic name /tf_static not found in topic_map. Report this.
+[opennav_docking-16] [ERROR] [1733772743.457680837] [rmw_zenoh_cpp]: topic name /tf_static not found in topic_map. Report this.
+```
+I need to look into these and see if the issue can be solved in my launch file and configuration or if there are deeper bugs that should be reported to the package maintainers.
+
+## Do I get any benefits?
+Yes, I get one really big benefit, but it comes with some drawbacks. First, the big benefit is that I can remove `--network=host` from the `docker run` commands and replace with `-p 7447:7447`. Restricting the accesible ports (and devices) to the minimum required reduces the potential security attack surface, so this is good. Explicitly calling out the necessary ports also makes it easier to run multiple containers on the same host, which is also good.
+
+The biggest drawback is that Nav2 doesn't run out-of-the-box any more. I expect this to be resolved fairly quickly, since there is plenty of attention and momentum on using Zenoh for ROS.
+
+The other major drawback is that the docker images are much larger now: A Zenoh-enabled image is 11 GB, which is around 6 GB larger than the image without Zenoh. Disk space isn't the constraint is used to be, but this is a significant increase and a barrier for adoption in low-cost, mass-market robots.
+
+Another small personal benefit is that as a part of this work, I updated the Jenkinsfile to include Git branch names in the container tags. This was an open issue, and it feels good to close it.
+
+## Commands and Files
+All files can be found at [https://github.com/ingotrobotics/turtlebot2_ros2/tree/feature/zenoh](https://github.com/ingotrobotics/turtlebot2_ros2/tree/feature/zenoh). Issues, pull requests, and all other commentary are encouraged.
+
+To run the container on my robot, I use a command like
+```
+$> docker run -it --rm -p 7447:7447 --device=<robot_hardware> $CONTAINER_NAME
+```
+And once inside the container:
+```
+$> ./background_zenoh_router.sh
+$> source install/setup.bash
+$> ros2 launch turtlebot2_bringup turtlebot2_bringup.launch.py
+```
+
+On the developer device, I use rocker to run RViz in the container, so the container commands look like
+```
+$> rocker --x11 --device=/dev/dri/card0 --port=7447:7447 --volume="$HOME"/.rviz2:/root/.rviz2 --env='ZENOH_TARGET="tcp/<robot address>:7447"' $CONTAINER_NAME
+```
+and then
+```
+$> ./background_zenoh_router.sh
+$> source install/setup.bash
+```
+Followed by either `rviz2` or `ros2 run teleop_twist_keyboard teleop_twist_keyboard`.
+
+## Future Work
+In the future, I would like to setup a Zenoh cloud router that can be used to demo the platform when I don't want to bring my robot (and separate wifi router) with me. I also plan on switching to an NVidia Jetson Nano for the on-robot compute.