Multi-Process Code Execution in RoboticsAcademy

This week’s goal was proving that RAM can manage two independent agent processes from a single exercise session — the foundation needed for the Drone Cat-Mouse exercise.

Why the browser sends the zip

One design decision worth noting: the exercise code — including processB/ — is bundled and sent from the browser, not fetched from a database on the RAM side (which was one option considered).

Keeping code in the browser payload means RAM stays decoupled from any storage backend — code lives with the client and gets pushed to RAM at run time. The mentor flagged this as a clean design point for RoboticsAcademy’s architecture.

How the Play flow works now

The browser doesn’t just send the student’s code — it builds a finalZip by merging three sources:

1. userZip — the student’s academy.py from the browser editor (cat code, autosaved)
2. helperZip — fetched from the filesystem: HAL.py, WebGUI.py, and the entire processB/ folder (pre-programmed mouse + its own HAL.py)
3. The two zips are merged client-side into finalZip and sent to RAM

RAM receives the merged payload, extracts everything to /workspace/code/:

/workspace/code/
├── academy.py              ← student code (cat, drone0)
├── HAL.py                  ← drone0 interface
├── hal_interfaces/
├── gui_interfaces/
├── console_interfaces/
└── processB/
    ├── academy.py          ← pre-programmed mouse
    └── HAL.py              ← drone1 interface

RAM then launches both:

python3 /workspace/code/academy.py           ← agentA (cat, drone0)
python3 /workspace/code/processB/academy.py  ← agentB (mouse, drone1)

Both go into the application_processes dict. Pause sends SIGSTOP to both. Resume sends SIGCONT. Stop kills both.

Verified both running simultaneously from their extracted paths:

11255  python3 /workspace/code/academy.py
11256  python3 /workspace/code/processB/academy.py

One process for the cat, one for the mouse — confirmed live. Each HAL resolves to a different drone namespace — same import name, different process context, different physical drone.

Slowly heading towards the goal.

What this means for the project

The pattern is exercise-agnostic. Any future exercise needing N agents follows the same structure: add a processB/, processC/ folder to the exercise template. RAM detects and launches them. The application_processes dict handles lifecycle for all uniformly.

Pull Requests

Also drafted and opened PRs this week consolidating all previous work:

• RoboticsApplicationManager #284
• RoboticsInfrastructure #742

Under review.