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.
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 
and classrooms. 
