Your last comment will be the one I address first, because it relates to everything else.
Yes, the Launcher runs first, you select a configuration to run, and then it starts the Robot container which will also start the RobotUI.
You can launch the Robot container directly via the docker cli (which also answers your question about how to launch the Robot container on a system boot, you could drop that into systemd like you mentioned). The drawback here is, the specific docker run
command you’d use is very specific for each version (and maybe each run). The Launcher is responsible for essentially building the parameters that are passed to the underlying docker run
command, while also being responsible for things like downloading new updates, etc.
With that background, here are two options to consider.
Option A. The easy-but-limited way. Currently, as of v3.2.2 we do not remove the RobotUI container when it is stopped. What this means is until the next run of the Launcher, you can always restart the last run config.
For example:
- Start Launcher, select a config. I used Sim to test this as I replied to you.
- After RobotUI comes up, connect to a terminal inside the container.
- Customize the container to your hearts content. I tested by installing
nano
inside the container and confirming it was still there on a restart, but you could also likely install some custom ros packages, and add a script that starts the nodes in those packages, etc.
- Exit the RobotUI (lower left).
- Restart your customized container (even after a reboot) with
docker restart ros-None-ui
.
To start over with a “fresh” Tormach container cause you hosed something, just rerun the Launcher.
If you put all your customizations into a script, you can also copy the script in with docker cp
.
Option B. If you feel you are a docker expert there are some additional things you can do. A Google search for “reverse engineer docker run from docker inspect” will give you some results that you could use to essentially rebuild the docker run
that our Launcher builds.
Having done that you can use the Dockerfile format to customize the image as much as you wanted, and then use the docker run
to correctly start your very custom image.
I’m not giving examples here because it’s a bit more advanced, if you know how to use Dockerfiles, and how to create a custom image based off a previous image, and you know your way around docker inspect
and can craft a docker run
by hand or using a tool you feel confident in, then you don’t need me to hold your hand on those steps.
If you aren’t familiar with those steps, it hopefully helps getting your Google searches off into the right direction to learn more about Docker, and I wish you happy hacking if you head in that direction!