Mini Workshop: Developing and Teaching ROS from a Web browser using Dev Containers and PWAs

Just a reminder that I’ll be giving a mini workshop during Thursday’s Navigation WG meeting, on this:

Update: You can join us 2023-05-25T19:00:00Z You can now watch the video recording here:

We’ll also be recording to update this post with the uploaded video for folks who can’t make it. Although, to foster a lively discussion, I’d recommend skimming beforehand my dev blogs, interwoven in the PRs:

Pull requests · ros-planning/navigation2 · GitHub

While the commit logs may resemble a laboratory notebook :notebook_with_decorative_cover: more than a concise diff, the context provided through the messages and summarizing comments should offer ample insight for others to replicate this template for their own projects :wrench: and classrooms. :school:

For example, this PR documents a few missing puzzle pieces when self-hosting installable PWAs:

Aside from that, with everything working on the main branch from the Nav2 repo, feel free to try it out yourself before the workshop, bringing any questions or feedback. Prebuilt Codespaces are working! :tada:

Note: For students experimenting with this using GitHub Codespaces instead of building the Dev Container locally, remember to delete your Codespaces when you are done to avoid unnecessary consumption of your free CPU and storage credits. Additionally, while the demos can run using the default machine type with 2 cores and 4GB RAM, you may consider increasing this if you plan to run more than Nav2, gzserver, gzweb bridge, foxglove bridge, and VS Code server simultaneously.

While I’ve been thinking of how to generalize this beyond just Nav2, this domain of web development is still quite new to me, so we could really benefit from some wider multidisciplinary collaboration.



I’m looking forward to it!

Hey folks! Looks like we got cutoff by the free google meet session. We could try again later, but in the meantime, feel free to post your unanswered questions, or ones I didn’t have time to get to here!

Also, here is a link to the minimal viable example I showed that was external of the Nav2 repo:

1 Like

Thanks so much for the workshop! I have some questions (I’m including the things you already answered but sharing here for visibility):

  • What’s the name of the setup you made? rplayground?
  • Is this nav2 dependent → No.
  • Is this setup VSCode dependent? → No.
  • You mentioned rocker (which I love and use a lot). IIUC functionalities in b/w may be orthogonal (but I might be mistaken). What for did you mention rocker?

I hope expanding the use of thin client in robotics dev to be part of the future. This definitely seems to help that direction.

Hi. Is the recorded meeting of the workshop available online?
Thank you.

Hey, I missed the event. +1 on request for meeting recordings available online? Thank you!

Absolutely! Find it attached.

Luis_Bracamontes_H.pdf (101 KB)

Alright, I’ve updated the original post at the top with the recording of the mini workshop. Pardon the delay, but our (SSV) research group here in Venice was hosting the 2023 Symposium on “Challenges of Software Verification”, so with the overlap I didn’t get a chance to finish this until today.

As mentioned, we ran rather short on time, and so I couldn’t explain everything. It would be great if we had a corporate sponsor for ROS WGs to enable automated recording/uploading for Google Meets longer than an hour (wink-wink, nudge-nudge). Realizing this would be the case, I didn’t walk through the entire demo. However, I’ll try and put out a detailed walkthrough next week or so.

Before I start recording a longer tutorial, feel free to ask any other questions, and I’ll address them later. In the meantime, I’ll answer the questions that have been posted so far:

Q: What’s the name of the setup you made? rplayground?
During my experimentation, I had to create several downstream forks to make progress in prototyping for this project. These forks were either to fix issues from the upstream or add necessary features for basic viability. I have submitted pull requests for all these changes upstream. However, to facilitate collaboration and scale up the project, I decided to create a proper organization instead of hosting repositories from my personal account. This organization provides a shared staging ground where we can iterate on pull requests before pushing them upstream.

As for naming the github org “rplayground,” it is a reference to the category of runtime environments commonly used for developing and experimenting with software projects and frameworks. The name invokes a sense of a fun, forgiving, and whimsical space to learn and explore robotics. Similar initiatives can be found in other programming communities and ecosystems, such as:

Currently, this “playground” only has a sandbox, but could be easily extrapolated in theme for future subprojects, e.g. a jungle gym, or football pitch, etc, providing dev container templates to teach other robotic related projects, such as:

Lastly, if you’ve never noticed from my userhandle, avatar, and personal titles, I have a funny affinity for the letter “R”, so that also played into the name as well! (:P)

Q: Is this setup dependent on Nav2?
No, this setup does not have an inherent dependency on Nav2. As mentioned during the mini workshop, Nav2 was used here as an example to demonstrate how this approach could be applied in practice. Perhaps the ultimate goal is to develop this initiative into its own project that can be packaged and distributed for other downstream projects to use. It could be a docker image that others could COPY layers from or even a Debian package; I’m still unsure. Yet, Nav2 provides a demanding real-world project that helps test ideas and validate the approach thus far.

Q: Is this setup dependent on VS Code?
No, this setup is not specific to VS Code, aside from the use of tasks as mentioned during the mini workshop. Dev Containers is an open specification that is not tied exclusively to VS Code, although its origins can be traced back to VS Code. There is a growing ecosystem of supporting tools and services, including Jetbrains-based products and simple Command Line Interfaces, that work with Dev Containers.

Q: You mentioned rocker. Why?
I mentioned rocker because it can achieve similar effects, particularly in automating setup for proxying user groups, X11 display forwarding, or GPU configuration to enable the use of GUIs and hardware acceleration. However, when advanced Docker-specific features or options are needed, such as remote debugging or shared memory access, it becomes more convenient to have a configuration file rather than maintaining another semi-portable script in bash or bat. For example, one can leverage VS Code to setup display forwarding, even when using WSL, or leverage an official ecosystem of features, to say: enable CUDA support:

In short, dev containers allow you to codify the creation of containers you could’ve launched using rocker, as well as standardize what you could have codified using ADE.


I’m working on the longer than an hour bit :smiling_face_with_tear:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.