The message based control path is complete. The network joystick implementation is completely in the joysender program and out of the robot proper. The "planner" concept is obsolete. There is now simply a motor planner that responds to commands. All planning and control is assumed to operate in a separate process on or off the robot system.
This is the culmination of the architectural rework described in Changing Plumbing on Robot. The old tightly-coupled design, where the network joystick code lived inside the main robot process, has been fully replaced. The robot control daemon now exposes a clean message interface; anything that can write to that interface can drive the robot.
What Changed
Previously, adding a new control source meant modifying, recompiling, and redeploying the robot binary. That was impractical — the robot program was a "working" system, and touching it to add a script or experiment meant risking breaking something that already worked.
Under the new architecture:
- The robot daemon handles only motor control and hardware I/O.
- A message queue accepts velocity commands from any external process.
- A shared memory region exports robot state (encoder positions, power levels, timing stats) for monitoring without IPC overhead.
- The joysender network joystick client is now a standalone process that writes to the message interface — it does not link to the robot binary at all.
- Scripts, autonomous planners, or test programs run as separate processes and communicate the same way.
Status
"Mostly complete" means the core infrastructure works end-to-end: joysender drives the robot through the message interface, the shared memory region is populated correctly, and the motor planner responds to commands. Remaining work includes cleanup, error handling edge cases, and documentation of the message protocol for anyone wanting to write their own control client.
Source code available at Mohawksoft.Org.