Currently, the only way to control the robot or alter its behavior is by a script, pretend to be a joystick, or modify the robot program itself. All of which I have done as needed. It gets pretty tedious and frustrating to do interesting things when you have to modify and recompile a "working" robot program, each and every time, to do something different.
Therefore, what is being done is to scrap the "netstick" networked joystick and move it to a more generic message passing interface. The networked joystick will still work, but it will communicate through the new interface.
The Problem with the Old Design
The original architecture had the network joystick receiver — the code that accepted UDP packets from the joysender client and translated them into motor commands — embedded directly inside the main robot process. This was fine for the initial implementation, but it created a rigid coupling that made experimentation painful.
Want to add an autonomous navigation mode? Modify the robot binary. Want to log sensor data during a run? Modify the robot binary. Want to test a new motion script format? Modify the robot binary. Every change risked breaking the motor control and PID loops that were already working correctly.
The New Architecture
The new design separates concerns cleanly:
- Robot daemon — handles only hardware I/O: reading encoders, computing PID, writing motor drive values. Exposes a message queue for incoming commands and a shared memory region for outgoing state.
- joysender / netstick — a separate process that reads joystick hardware or network UDP and writes velocity commands to the robot daemon's message queue. No longer linked to the robot binary.
- Planners and scripts — any process that wants to control the robot writes messages to the same queue. The robot daemon does not know or care who is sending commands.
This is the classic Unix philosophy applied to robotics: small programs that do one thing well, communicating through well-defined interfaces.
The completion of this rework is reported in Message Based and Shared Memory Control Interface is Mostly Complete.