Skip to content

Configuration

Infrastructure Banner

Jetson Xavier NX

ubuntu 24.04

Robot Setup Script Configuration#

All installer behavior is driven by a single file, robot_system.conf, which is sourced at the very start of robot_setup.sh. It defines every path, repository reference, and tunable value that the setup phases rely on, so adapting the installer to a different machine, fork, or deployment layout is mostly a matter of editing values here rather than touching the scripts themselves.

The file is organized into the same sections shown in the setup preview, making it easy to cross-reference what you're changing against what the script will print back to you for confirmation.

General#

CURRENT_USER="${SUDO_USER:-$USER}"
ROBOT_NAME="micipsa"

CURRENT_USER resolves automatically to whichever user invoked sudo, so it rarely needs to be touched. ROBOT_NAME is used to derive several install paths further down (/etc/${ROBOT_NAME}, /usr/local/lib/${ROBOT_NAME}), so renaming it will cascade through the rest of the config.

Tip

If you're adapting this installer for a different robot or a fork of Micipsa, changing ROBOT_NAME here is the single most effective way to namespace all installed files under a new name.

Workspace Setup#

ROS2_WS="${ROS2_WS:-/home/${CURRENT_USER}/ros2_ws_deploy}"
REPO_URL="${REPO_URL:-git@gitlab.com:yousriouartsi-group/micipsa/micipsa.git}"
REPO_BRANCH="${REPO_BRANCH:-main}"
REPO_ROOT="${ROS2_WS}/src/${ROBOT_NAME}"

ROS2_WS sets the location of the ROS 2 workspace on the target machine. REPO_URL and REPO_BRANCH control which repository and ref get cloned; REPO_BRANCH can also be overridden at runtime with the --branch/-b flag on robot_setup.sh.

Important

REPO_ROOT is derived from ROS2_WS and ROBOT_NAME, not set independently. If you need the repo cloned somewhere other than src/${ROBOT_NAME} inside the workspace, you'll need to edit REPO_ROOT directly rather than relying on the defaults.

INSTALLERS_SCRIPTS_DIR and UNINSTALLERS_SCRIPTS_DIR point at the same infra/scripts/installers directory inside the cloned repo, this is expected, since uninstall logic currently lives alongside the installers.

Docker#

DOCKER_OS_BASE_IMAGE_X86="ubuntu:24.04"
DOCKER_OS_BASE_IMAGE_ARM="docker.io/arm64v8/ubuntu:24.04"
DOCKER_DIR="${REPO_ROOT}/infra/docker"
FOUNDATION_DOCKERFILE="${DOCKER_DIR}/base/Dockerfile"
DOCKER_COMPOSE_FILE="${DOCKER_DIR}/docker-compose.yaml"
DOCKER_COMPOSE_DEPLOY="${DOCKER_DIR}/docker-compose.deploy.yaml"

Base images are split by architecture so the same config works on both x86 development machines and the Jetson's ARM target.

Udev Rules, Helpers, and Compose Launcher#

UDEV_RULES_DIR="${REPO_ROOT}/infra/udev"
HELPERS_SCRIPTS_DIR="${REPO_ROOT}/infra/scripts/helpers"
DOCKER_COMPOSE_LAUNCHER_DIR="${REPO_ROOT}/infra/docker/scripts"

These three simply point at source directories inside the repo. They're unlikely to need adjustment unless you restructure the repo layout, in which case updating these paths is what keeps the installers pointed at the right source files.

Config Files#

CONFIG_ITEMS=(
    "micipsa_robot/micipsa_bringup/config"
    "infra/dds"
    "infra/docker/docker-compose.yaml"
    "infra/docker/docker-compose.sim.yaml"
    "infra/docker/docker-compose.deploy.yaml"
)

CONFIG_ITEMS is the list of paths (relative to REPO_ROOT) that install_configs.sh copies into the system config location. This is the array to extend if you add a new config directory or file to the repo that needs to land on the target machine, for example a new DDS profile or an additional Compose override file.

Network#

RMEM_MAX=67108864
RMEM_DEFAULT=67108864
WMEM_MAX=67108864
WMEM_DEFAULT=67108864

SYSCTL_CONF_DIR="/etc/sysctl.d"
SYSCTL_CONF_FILE="${SYSCTL_CONF_DIR}/99-micipsa-network.conf"
RC_LOCAL="/etc/rc.local"

These control the socket buffer sizes applied for DDS traffic, currently set to 64 MB. If you're running on a network with different bandwidth characteristics or a machine with limited memory, these are the values to tune.

Note

RC_LOCAL exists specifically to work around the Jetson L4T early-boot reset issue, where sysctl values set via /etc/sysctl.d alone don't reliably persist. If you're adapting this installer for a non-Jetson target, this rc.local step may not be necessary but leaving it in place is harmless.

Utils and Install Paths#

UTILS_DIR="${REPO_ROOT}/common/utils"

UTILS_DIR_INSTALL_LOCATION="/usr/local/lib/${ROBOT_NAME}"
BIN_DIR_INSTALL_LOCATION="/usr/local/bin"
UDEV_RULES_DIR_INSTALL_LOCATION="/etc/udev/rules.d"
HELPERS_SCRIPTS_DIR_INSTALL_LOCATION="${BIN_DIR_INSTALL_LOCATION}"
CONFIG_DIR_INSTALL_LOCATION="/etc/${ROBOT_NAME}"

DOCKER_COMPOSE_LAUNCHER_INSTALL_DIR="${UTILS_DIR_INSTALL_LOCATION}/compose_launcher"
DOCKER_COMPOSE_LAUNCHER_INSTALL_FILE="${DOCKER_COMPOSE_LAUNCHER_INSTALL_DIR}/compose_launcher.py"
DOCKER_COMPOSE_LAUNCHER_WRAPPER_FILE="${BIN_DIR_INSTALL_LOCATION}/compose_launcher"

SYSTEMD_SERVICES_DIR_INSTALL_LOCATION="/etc/systemd/system"

This block defines where everything ends up on the target system, following standard Linux FHS conventions: shared libraries and Python modules under /usr/local/lib, executables under /usr/local/bin, udev rules under /etc/udev/rules.d, and application config under /etc/${ROBOT_NAME}.

Important

DOCKER_COMPOSE_LAUNCHER_INSTALL_DIR and DOCKER_COMPOSE_LAUNCHER_INSTALL_FILE are derived from UTILS_DIR_INSTALL_LOCATION, keeping the compose launcher's modular files (compose_launcher.py, compose_manager.py, env_builder.py, config_loader.py, console_utils.py) grouped together as a package rather than scattered across /usr/local/bin. If you restructure the launcher's file layout, this is the directory reference to update so the wrapper script in BIN_DIR_INSTALL_LOCATION keeps pointing at the right package.