Building and testing

Each component builds and tests on its own. Run the commands on this page from the repository root unless a step says otherwise. Install the toolchains first: see Install the toolchain.

A quick check of the controller and two of its consumers, on Linux or WSL:

export TMPDIR=/dev/shm/rosie-tests && mkdir -p "$TMPDIR"
make -C rt-core control sim test
make -C motion-server/joint-trajectory/v1 all test BIN_DIR="$PWD/rt-core/build/dense"
(cd offline-programming/v1 && go test -race -count=1 ./...)

Test environment#

The rt-core tests start real processes and bind Unix sockets, and some assert real locked-memory behaviour.

• Keep TMPDIR on a Linux tmpfs, such as /dev/shm/.... On WSL, sockets cannot bind under /mnt/c.
• Allow unlimited locked memory for the test shell. CI runs sudo prlimit --pid $$ --memlock=unlimited:unlimited and checks ulimit -l prints unlimited. Do the same, or raise memlock in /etc/security/limits.conf.
• Node 22.13.1 is used by the generator golden tests. They look for it at ~/.rosie/node-22.13.1/bin/node or in NODE. CI symlinks its Node there.
• To keep Go caches inside the checkout, set GOCACHE, GOMODCACHE and GOTMPDIR under rt-core/build/, and GOFLAGS=-mod=mod.

cd rt-core
export GOCACHE=$PWD/build/go-cache GOMODCACHE=$PWD/build/go-mod-cache GOTMPDIR=$PWD/build/go-tmp GOFLAGS=-mod=mod
mkdir -p "$GOCACHE" "$GOMODCACHE" "$GOTMPDIR"

rt-core#

cd rt-core
make control sim     # rt-control, rtctl, benchdrive, rt-natspublisher, rosie-rt-core-sim
make test

To build the live daemon without hardware, build the pinned IgH userspace library first:

cd rt-core
bash tools/build-igh-userlib.sh          # IgH 1.6.9 by default; 1.6.10 to 1.6.12 are also pinned
export PKG_CONFIG_PATH="$PWD/build/deps/igh-prefix/lib/pkgconfig"
make live control
build/rtctl validate --backend live --config config/machines/a6ec-bench.example.json

The script downloads the IgH source archive and checks its SHA-256 before building.

Robot descriptions#

python3 robot_description/tools/manifest.py --check
(cd robot_description/go && go test ./...)

Motion servers#

Both build against rt-core's C++ client and test against the simulated core, so build rt-core first.

make -C rt-core control sim
make -C motion-server/v1 all test test-composed \
  BIN_DIR="$PWD/rt-core/build/cartesian" OBJECT_CACHE_DIR="$PWD/rt-core/build/cartesian-cache"
make -C motion-server/joint-trajectory/v1 all test \
  BIN_DIR="$PWD/rt-core/build/dense" TEST_BUILD_DIR="$PWD/rt-core/build/dense-tests"

The dense daemon also has test-go and test-sanitize. make -C motion-server/joint-trajectory/v1 print-bin-dir prints its default output directory. The Cartesian server's default BIN_DIR is outside the repository, which is why these commands set it.

Offline programming#

make -C rt-core control sim
(cd offline-programming/v1 && go test -race -count=1 ./...)
(cd offline-programming/v1/ui && npm ci && npm run lint && npm test)

Simulation stack and virtual pendant#

make -C rt-core control sim
(cd steamdeck/virtual && go test -race -count=1 ./bridge ./stack ./v1)
DEV_STACK_BACKEND=rt_core DEV_STACK_FIREWALL=0 DEV_STACK_UI_HOST=127.0.0.1 \
  bash motion-server/v1/tests/dev-stack-smoke.sh
(cd steamdeck/virtual/v1/ui && npm ci && npm test && npm run build)

DEV_STACK_FIREWALL=0 stops the dev stack from changing firewall rules. See Ports, sockets and environment variables.

Weld planner#

cd weld_planner/v1
pixi install -e default
pixi run -e default pytest -q tests/programmer/test_dense_joint_trajectory.py
pixi install -e motion                          # Linux, NVIDIA GPU with CUDA 12
pixi run -e motion pytest -q tests/motion_planner

Always pass -e. Several tasks exist in more than one environment, and the motion tests need the CUDA motion environment. Run the weld planner covers the environments.

Pendants and deploy module#

(cd steamdeck/real/v4 && go build ./... && go vet ./... && go test -race -count=1 -p=1 ./...)
make -C steamdeck/real/v4/steamdeck all
(cd offline-programming/v1/ui && npm ci) && make -C steamdeck/real/v5 -j4 all check

The v5 pendant needs Qt 5.15 and Assimp. No CI workflow builds it. See Build and install the pendant.

Quality checks#

Formatting and lint runners live in quality/. See Code style and quality.

CI#

All workflows run on GitHub-hosted Ubuntu runners, on pull requests and pushes that touch their paths.

What CI does not cover: the v5 pendant, mujoco-sim, the Tesseract environment's self-test, the full weld planner suite (only the contract tests above run, on CPU), and anything on real hardware. A green CI run says nothing about powered motion.