Add devcontainer configuration files

[mjyc]

Description

This PR adds devcontainer configuration files that enable developers to open a ready-to-develop/installation-completed Mushr project in VSCode running on a local linux machine. For more details, see #108.

Steps to Test

via GitHub Action

Run "CI" workflow here

Manually

Before start, make sure you have VSCode, docker, and Dev Containers VSCode extension installed on your machine.

1. Clone mjyc/mushr repository to your local filesystem and switch to noetic-devcontainer branch
2. Open VSCode, open Command Palette, and select "Dev Containers: Open Folder in Container..."
3. Select the cloned repository root folder, and wait. It takes about ~15min to build on my machine.
   • (Optional) Click "Starting Dev Container (show log)" link in the alert to see the logs. It's helpful to understand what'd going on.
4. When 4. is done, your mushr project should be ready! Try things like:
   • Select "Tasks: Run Task" and select "Roslaunch teleop.launch" to launch the teleop launch file.
   • Select "Tasks: Run Task" and select "Start Foxglove Studio server" to start a self-hosted foxglove studio server. You can open a browser and visit localhost:8080 to open the foxglove studio webapp where you can import the foxglove_layout.json, tweak your visualization panels, etc.

NOTE The dev container setup in this PR--more specifically docker-in-docker--does not work on mac machines with apple silicon. Checkout these two links for details:

• docker-in-docker fail to start with amd64 image on macOS M1 devcontainers/features#219
• Docker Desktop 4.16.0 Run x86_64 dind image fails to pull images docker/for-mac#6678

Two thoughts on this issue:

1. We shouldn't need docker-in-docker. I intentionally preserved the existing installation steps as shown in the tutorial, which runs docker-compose up (while running $ ./mushr/mushr_utils/install/mushr_install.bash), but the container image specified in docker-compose-xxx.yaml can be directly specified .devcontainer. But taking this approach will require bigger changes (and confuse the users, etc.), so I took a more incremental approach that requires docker-in-docker.
2. I expect Apple (and Docker?) will fix this issue eventually.

[schmittlema]

Thanks for submitting this, we will test on our end. This review is just looking over the code as a first step. In regards to the mac support I am much more in favor of 2 because that allows us to not be tied to vscode which not everyone uses (if I'm understanding correctly).

[schmittlema]

This line assumes vscode is setup in the /home directory. Is that a reasonable assumption?

[mjyc]

Added a comment explaining how the required folder will be created beforehand.

[schmittlema]

What is the difference between trivial and non-trivial?

[mjyc]

By trivial, I answering "no" to all prompted questions. The use of word "trivial" was inspired by how apt uses that word. See https://linux.die.net/man/8/apt-get

--trivial-only
Only perform operations that are "trivial". Logically this can be considered related to --assume-yes. Where --assume-yes will answer yes to any prompt, --trivial-only will answer no.

I was tempted to use --assume-no but I haven't seen any other linux command using such wording, but happy to be wrong here and use something else.

[schmittlema]

assume-no or no-to-all seems more informative. Trivial to me seems vague

[mjyc]

Thanks @schmittlema to starting the review.

In regards to the mac support I am much more in favor of 2 because that allows us to not be tied to vscode which not everyone uses (if I'm understanding correctly).

I don't follow. Would you elaborate which "2" are you referring to?

About VS Code, while I believe it is possible to use other IDEs, I don't think they integrate with devcontainer well, e.g., you might need to start devcontainer container yourself using cli and then try to connect to an ide server from your ide running on the host. So DX benefits you get is not as good, i.e., no more few-click devenv setup.

I'm open for a quick chat if you think that can help us communicate better. I just sent you an email about this using your cs address found from your website. If MuSHR team isn't too familiar with devcontainer, I also found this Nav2 doc handy.

[MarkusSchiffer]

Hey Mike,
Another Member of the MuSHR team here. I'm just going through everything before we merge. I have a few questions as I'm working through this. I don't have any experience with dev containers, but I don't think many of the users will either so that's probably a good thing in order to test this. I ran through the manual steps to set everything up. Here's some of the issues I ran into/questions I had:

1. How do we rerun catkin build, in case users are writing their own code? From what I see, the terminal that VS Code launches when the dev container starts does not have access to any ROS tools via the command line. Somehow the build gets automatically executed when the container is built, how do we do it after?
2. Similarly, how do we run any other nodes, such as the planner or RHC, etc? Would users need to create more tasks in the tasks.json file? I tried adding one for the GP similar to how the teleop.launch task was created, but this complained that port 9090 was still in use.

I'm sure both of the above are possible, we just need to carefully document how to do this for our users.

3. I could not get the browser version of foxglove to connect to the ROS instance, but was able to do so with the desktop app (running on MacOS). Are the changes in pull request Update devcontainer config to support Foxglove Studio on Codespace #110 needed in order for this to work or should it work with only the changes in this PR?

Thanks for the clarifications on these. Happy to report that building the image and running teleop do seem to work well and without any hiccups, at least on MacOS.

[schmittlema]

I meant
2. I expect Apple (and Docker?) will fix this issue eventually.
As in I'm ok with not fixing the docker in docker issue in favor of maintaining support for other IDEs. Unless I'm not understanding correctly, removing the docker in docker would break support for other IDEs and may not work on the robot?

[mjyc]

Nice to meet you @MarkusSchiffer and thanks for taking look.

Re. 1. This devcontainer config is following the exact steps mentioned in this Mushr tutorial; see this .devcontainer/build.sh which is being invoked in "postCreateCommand" field in .devcontainer/devcontainer.json. This is how the "builds gets automatically executed". So to rebuild, you will need to run mushr_noetic run 'cd catkin_ws && catkin build'.

Re. 2. Funny to see this as this is the same question I had for Mushr team when I was playing with the Mushr project :) You don't need to create a new task.json file since that's just to run "command" using a VSCode IDE feature. So running the command manually was the right thing to do. About the port 9090 still in use problem, that's most likely because there's another previously executed mushr_noetic command which is essentially calling docker-compose up ... -p 9090 ... and occupying 9090 so 2nd mushr_noetic (yours) is cannot use 9090 and output that message. How do we fix this setup? I think that's a question for the Mushr team. My first question is: how are the mushr developers developing new ros node today? Do they develop and run new ROS nodes in the host or in a docker container? cc . I can help with adjusting the devconfig to meet Mushr team's workflow. cc @schmittlema

Re 3. Hmm.. using foxglove in local browser should work. Did you select "Open connection" => "rosbridge" => and type in "ws://localhost:9090"? I just realized that I didn't mention that in the description.

Re. regarding docker-in-docker (@schmittlema). The issue with docker-in-docker not properly working in Apple Silicon machine is irrelevant to other IDE support. One would still need to use VSCode to leverage the noinstall expereince you get from using devcontainer. I was pointing out the incompatibility with M1/M2 assuming many potential users are using M1/M2. Supporting more IDEs than VSCode is ... another topic ... I'm happy to chat about that in another place (maybe in the parent discussion?) but in this PR, I'd like to see if using devcontainer + vscode would dramatically improve onboarding experience of new mushr devs (e.g., capstone class ugrads being able to get started in few clicks/no need to support installation steps from the mushr team). If not, what's missing?

[MarkusSchiffer]

Hey Mike,
Regarding item 2, the way that the we currently run multiple nodes is by separately roslaunching all the nodes needed, either from one docker terminal using TMUX, or I by creating multiple terminal sessions within the same container, using docker exec -it <container> bash. Usually, this isn't a problem because our docker image has access to all ROS utilities (roslaunch, catkin build, etc.) out of the box. As far as I can see, the terminal which opens in the VSCode dev container does not have any of the ROS tools available, so currently, the only way I know of to run roslaunch is with the mushr_noetic run command, which complains about the port being in use. This is likely because we're running a container within a container. So if I were to rephrase the original question I had, it should be how do we call roslaunch an arbitrary number of times within the inner container?

[mjyc]

If you run docker exec -it <container> bash within the terminal running in VSCode (that is connected to the running devcontainer) after running your first mushr_noetic run (aka docker-compose up ... -p 9090:9090 ...), you should be able to have access to ROS tools, tmux, etc. See the video above (using tmux is not demoed but you can do it).

Btw, if you want to customize the VSCode bash (or other shells) settings (the shell accessible in devcontainer and not the mushr container), you could use dev container extension feature:

If you are trying to connect to the running devcontainer from an external terminal, you can use install devcontainer-cli (e.g., via npm install -g @devcontainers/cli) devcontainer exec <cmd> [args..] (see devcontainer-cli for more info).

Initially, I've tried both approaches and have been using more of the 1st approach lately[^1]. I didn't like the feel of using terminal within vscode[^2] but the convenience of having all dev tooling (including ide) managed as code/portable across different environment, e.g., cross platform, works on local & remote/browser, (in expense of getting stuck in vscode & devcontainer, similar to how I'm already stuck with other tools like docker) made that awkwardness go away. That's just me, I'm curious to see how it works for the mushr team & its users.

[^1] I may change my mind down the road
[^2] I was worrying a lot about potential keyboard shortcut conflict between vscode and my shell setup but surprisingly that didn't bother me much

[mjyc]

Hello @MarkusSchiffer Is there anything else you want me to address? Btw, I cannot merge my own since I don't have write access.

[MarkusSchiffer]

Hey Mike,

Sorry for the delayed response, I've been away for a little while. Again, it seems to me that everything works. However, I personally find that this doesn't greatly simplify things for users since there's still a learning curve with the GitHub devcontainers. Additionally, I feel our official tutorial and docker image is pretty easy to set up and get going in sim for both MacOS and Linux users. Logistically, the MuSHR team is currently a bit understaffed and cannot maintain/create tutorials for this code change at this time (I've graduated and thus don't have lots of time anymore). I think how we'll proceed is somehow acknowledging your fork as some kind of official MuSHR fork for the time being, and point users toward it if they're interested. Hopefully in the near future, we can hire a new group of undergrads who might be able to look into supporting this.
Feel free to follow up if you think I'm wrong in my assessment. Sidharth is now the main person in charge, so maybe he'll have time to take another look at this in the future.

[mjyc]

... I think how we'll proceed is somehow acknowledging your fork as some kind of official MuSHR fork for the time being, and point users toward it if they're interested. ...

Ok.

Regarding the ease-of-installation, the devcontainer-based installation should be easier if a developer is using VSCode. Based on interacting w/ you in this thread, I noticed the current devcontainer setup--ie of running mushr container within devcontainer--confuses how to run things (e.g., needing to use mushr noetic run ... to run things). I think updating the current devcontainer setup to use the source install (instead of docker install) will help as developers can develop & run things in devcontainer directly and not having to go into another container (e.g., via mushr noetic run ...). But we can discuss more if there's needs / resources in the future, so wrapping up as suggested is fine by me.