A multi-process color generator system built around a single design principle: components that serve different purposes should live in different environments, even when that makes communication harder. A ROS 2 publisher takes RGB intensity input from the user and sends it over a custom ROS message type to a subscriber node, which then bridges the data — via ZeroMQ — to an independent OpenCV process running in its own virtual environment, isolated from the ROS 2 install.

The ZeroMQ bridge wasn't the first approach tried. An earlier version used Python's shared memory / multiprocessing to connect the two environments, but synchronization issues introduced race conditions; adding locks to fix that made the communication layer too complex to justify. Replacing it with ZeroMQ's pub-sub architecture eliminated the race condition entirely while keeping the two environments fully decoupled — the kind of trade-off that only shows up once you've built the wrong version first.

A separate launch orchestration layer (built on pexpect and pathlib) automates what would otherwise require three manually-opened terminals — one each for the publisher, the subscriber/bridge, and the OpenCV process — so the system can be started with a single command.

A ROS 2 project that programs turtlesim to draw the letters of the alphabet — one module per character. The motion of each letter is derived from coordinate geometry calculated by hand, then fed into a modular Python codebase where topics, publishers, subscribers, and the service-client pattern all work in concert.

The deliberate choice to calculate coordinates manually — rather than using a drawing library — turned a straightforward demo into a practical exercise in applying geometry to real robot motion planning. This is the kind of thinking the tutorial series is built on: understanding a concept well enough to use it, not just repeat it.