Virtualbox as format for sharing workspaces?

I’m interested in the potential for Microros in an educational context.

Users would install a virtualbox image on their laptops, this would contain a 22.04/ROS2 install.

They could then connect this to a Microcontroller using Wifi transport.

The ROS2 Virtualbox would be configured using a common script.

Then three workspaces would be set up

  1. Linorobot2 rover.

  2. Learn by doing robot arm

  3. Zuko quadruped

The XRP open hardware robot kit with the addition of an open hardware PCA9685 could then support all three use cases.

1 Like

@samuk
First of all, I would like to introduce myself. I was in charge of early mechanical design for Tuerlebot3.
I like the design of XRP you introduced.
I am happy to confirm that there are friends who are working together on an open platform for education and research.

Hello,

I would first recommend to make a image for available Raspberry Pi versions to flash the ROS2 / Ubuntu 22.0 image. This would be a good direction…

why not use docker? you can use it with network=host to connect to network and there are already images with ubuntu and ros2. if you want anything with display it can be done too.

2 Likes

A pi version is a good idea.

To turn the question about Docker on it’s head, why use Docker? What does it offer that Virtualbox doesn’t?

why use Docker? What does it offer that Virtualbox doesn’t?

OpenGL hardware acceleration (useful for Gazebo 11 Classic camera plugins). By using Podman/Docker on Linux, you can use podman run -e DISPLAY=$DISPLAY --device=/dev/dri (without sudo) or sudo docker run -e DISPLAY=$DISPLAY --device=/dev/dri to bind GPU into container.

1 Like

Docker is much lighter than VirtualBox. Modifying the Docker image is also very convenient. You can create images for specific features/hardwares based on the same base image. Docker is also easier to manage and maintain. It is often used with CI/CD. That is, when you commit the code, the Docker image will be automatically compiled and the test will be run. Therefore, Docker is also used for deployment in many robotic products. If it is for educational use, you should not only teach students how to use ROS, but also teach them modern development tools and scientific practices.

2 Likes

I would also recommend docker, and more specifically using devcontainers to set up the environment for development. It lets you add a GUI desktop for any rviz / gazebo visualization using standard available features (desktop-lite) that makes the desktop GUI available through noVNC and you can set it up on cloud workstations as well if needed like github codespaces. Heres the repo if interested.

1 Like

That looks interesting. However I got this error using your files. What should I do next?

sam@debian:~/Downloads/ros2-devcontainer-main/.devcontainer$ sh installation-script.sh
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Oh I think I should change the name of that script. The installation-sh script is run automatically as a part of the process that sets up the devcontainer environemnt. To get started using the devcontainer environment, it usually requires vscode and the devcontainer extension. You would have to then open the repo in vscode and then Ctrl+shift+p then click “Reopen in devcontainer” to build the environment and start.

To test the repo you can start a workspace on github codespaces instead to verify that you can get it running. You would need to use the no-GPU branch to get started though. Here is an article for some additional info.

Ah that makes more sense!

Building it now. For Linorobot2 you’d likely be using VScode anyway for Platformio

Now run into this


[167917 ms]     at async jeA (/home/sam/.vscode/extensions/ms-vscode-remote.remote-containers-0.304.0/dist/spec-node/devContainersSpecCLI.js:611:12219)
[167917 ms]     at async _eA (/home/sam/.vscode/extensions/ms-vscode-remote.remote-containers-0.304.0/dist/spec-node/devContainersSpecCLI.js:611:11960)
[167923 ms] Exit code 1
[167929 ms] Command failed: /usr/share/code/code --ms-enable-electron-run-as-node /home/sam/.vscode/extensions/ms-vscode-remote.remote-containers-0.304.0/dist/spec-node/devContainersSpecCLI.js up --user-data-folder /home/sam/.config/Code/User/globalStorage/ms-vscode-remote.remote-containers/data --container-session-data-folder /tmp/devcontainers-17987d06-ccdb-44ff-8fae-a3edfb25f68a1692629396583 --workspace-folder /home/sam/Downloads/ros2-devcontainer-main --workspace-mount-consistency cached --id-label devcontainer.local_folder=/home/sam/Downloads/ros2-devcontainer-main --id-label devcontainer.config_file=/home/sam/Downloads/ros2-devcontainer-main/.devcontainer/devcontainer.json --log-level debug --log-format json --config /home/sam/Downloads/ros2-devcontainer-main/.devcontainer/devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root true

There is usually a devcontainer build log after failure that opens up in vscode if the building process fails. Can you go provide that here ? also just for the sake of verification did you try building the main-noGPU branch on github codespaces to test ?

1 Like

I ran this https://sturdy-fishstick-46v795jprf7vpp.github.dev/ and it ran OK

I have the latest from Install Docker Engine on Debian | Docker Documentation

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
docker-ce is already the newest version (5:24.0.5-1~debian.12~bookworm).
docker-ce-cli is already the newest version (5:24.0.5-1~debian.12~bookworm).
containerd.io is already the newest version (1.6.22-1).
docker-buildx-plugin is already the newest version (0.11.2-1~debian.12~bookworm).
docker-compose-plugin is already the newest version (2.20.2-1~debian.12~bookworm).
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.

The excerpt above is from the terminal build log. Full log here: [102 ms] Dev Containers 0.304.0 in VS Code 1.81.1 (6c3e3dba23e8fadc360aed75ce363 - Pastebin.com

Just got an empty email yesterday. Will take a look when i get back

1 Like

If anyone wanted to try my virtualbox .OVA you could download it here

It’s currently Ubuntu 22.04 with Linorobot2 installed. Some more info is here

My hope is to use it with this XRP PCB on a 4x4 platform once Microros-Platformio supports wifi transport on the pico as well as ESP32

I’m currently struggling to re-size the virtualbox OVA to make more space, if anyone can help with that then please re-upload a larger version.

Oh okay I see the issue, I’ll add this info to the repo as well. The system is trying to mount cache/humble/build and the install + log directories to a folder inside the container. You don’t have these directories on your system before you try to build it. Or you could just comment this out from the devcontainer.json file and try to build again. it should be successful then.

1 Like

Nice that complies now with a few warnings

WARNING: The script isympy is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The script pygmentize is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The script pyflakes is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The script pydocstyle is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The script pycodestyle is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The script pylama is installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The scripts jupyter, jupyter-migrate and jupyter-troubleshoot are installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The scripts jupyter-kernel, jupyter-kernelspec and jupyter-run are installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The scripts ipython and ipython3 are installed in '/home/uazam/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

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