A robot controller,
written in weights.
What happens when a language model writes the numbers inside a small neural network, then you let that network drive?
Two rooms, one doorway, a lidar and a tiny network. No map, SLAM or path planner in the steering loop. Could weights written by an AI produce useful navigation?
Two rooms. Three laps.
Recorded positions, interpolated for playback. The dashed line is the full route. Lap changes are scheduled by ordinary code using Gazebo true pose. Open static figure ↗
Watch the original Gazebo door run
Original screen recording, run 003.17. The trajectory comparisons use the separate recorded pose data.
parameter slots / nonzero in v04
fixed tanh network
retained development episodes
language-model calls during a run
Can the weights be
the program?
The prompt for this experiment came from Takehi et al.’s work on weight-space programming: language models reading and writing neural-network parameters directly. The initial task was concrete: get the simulated robot through the doorway without hitting the walls, using directly authored network weights for control.
Fable 5.1 wrote and revised the network’s weights: explicit coefficients encoding distance thresholds, steering priorities and their combinations. Fable used the ROS 2 / Gazebo runs and activation traces to diagnose failures and choose the numerical changes.
There was no training optimizer and no language model driving at runtime. There was iterative development, with the same simulated layout used to design and evaluate the controller. This is not a zero-shot or held-out generalization result.
My direct input to the policy development was a behavioral suggestion: after seeing the robot circle without approaching the doorway, I told Fable to head toward a wall. Fable worked out how to express that behavior in the weights and evaluated the revisions. The later three-lap mission extended the original doorway task with a separate scheduler.
A little network.
A visible boundary.
Each scan becomes 24 sector minima. Add a constant and a lane offset: 26 inputs. Two layers of 16 units turn those into a forward-speed signal and a turn-rate signal.
Most coefficients are zero. In v04, only 78 of 738 stored entries are nonzero. Their structure is deliberate: some units respond to a distant left wall, others to a close obstacle or an opening. The next layer combines those signals into steering priorities.
h = tanh(40 × (dleft − 0.35) / 6)At 0.35 m from the wall, the response is zero. Farther away, it becomes positive; closer, negative. The coefficient gives that response its slope.
The steering pass has no map or pose input. The three-lap mission does use pose: a scheduler detects lap closure using Gazebo ground truth, then changes the lane-offset input. That dependency matters when moving toward the real robot.
It could follow a wall.
First, it had to find one.
Version two worked near the wall. Starting in the middle of the room, it kept circling. After my suggestion to approach a wall, Fable used the recorded evidence to diagnose the persistent turn: “wall far” and “left side open” held the steering channel active without bringing the robot to a wall.
Fable’s revision for version three suppresses that turn when the left wall is lost and compares proximity on either side to search for a wall. From the same start, the recorded run crossed the door in an episode lasting 37.78 s, instead of timing out.
The analysis and weight adjustment were Fable’s work. Fable inspected the recorded behavior and activations, identified the competing steering terms, and used that evidence to decide what to change. My suggestion supplied a behavioral direction, not coefficients or a trace-based diagnosis.
What changed across the versions?
- v01 → v02 / Doorway priority. A sharper left-front proximity signal reduces the turn into the jamb. Run 003.04 stalled; 003.05 crossed.
- v02 → v03 / Search and side-aware steering. Suppress persistent circling in open space; turn toward an open left-front region when the front is blocked.
- v03 → v04 / Adjustable wall offset. A scalar input shifts wall-distance targets. The scheduler advances it after each lap.
The surrounding safety behavior also changed during development. These runs are not a controlled ablation of weights alone.
A small controller.
A surprisingly useful result.
The question was whether directly authored weights could do useful navigation without the usual mapping and planning machinery. In the recorded tests, they could. Nav2 gives that observation a familiar reference: a mature navigation stack tackling the same doorway, starts and obstacles.
In seven paired door cases, both approaches crossed. One uses a map and a planned route; the other reacts to lidar through a few explicitly written coefficients. Both also failed to complete the tested 0.5 m zig-zag passage under their respective stop rules. For this experiment, getting meaningful behavior from such a small policy is the interesting comparison.
There is no navigation goal input, map-building component or path planner in the network’s steering loop. There is still supporting code: scan reduction, command scaling, a frontal stop and, for the three-lap mission, a pose-based scheduler.
The scope is deliberately narrow. The network does not inherit Nav2’s ability to navigate to arbitrary goals, plan around a map or coordinate recoveries. That makes this a promising controller experiment, with its own next questions.
Inspect the paired measurements and the exceptions
The seven common crossings span v02 and v03 development runs, not a frozen-policy success-rate trial. Nav2 follows shorter, faster routes in those recordings. Those numbers describe the observed behavior; they are not the objective this experiment was designed to optimize.
| Case | Authored policy | Configured Nav2 |
|---|---|---|
| Zig-zag, 0.5 m exit | Stalled · 28.08 s | Failed · 42.42 s |
| Room centre, facing south | Timeout · 60.64 s | Crossed · 12.26 s |
The common failed passage does not establish identical failure mechanisms: the policy’s frontal stop and Nav2’s configured planning / control constraints differ. The south-facing start also shows that their outcomes do not match in every case.
The exploration end times have different meanings: 320.64 s for three scheduled policy laps, 31.54 s until explore_lite’s frontier criterion is met. They do not form an exploration-speed comparison.
What was configured in the Nav2 reference?
slam_toolbox, NavFn and Regulated Pure Pursuit at 10 Hz; 0.12 m robot radius; 0.25 m/s target speed; 1.0 rad/s angular limits; a rolling global costmap; 0.30 m inflation radius. True odometry is supplied by a simulation helper. Nav2 receives a destination; the policy does not. The policy cannot reverse. See the method and parameter patch for the full context.
What I can claim.
What I still need to test.
Directly authored weights produced useful closed-loop behavior in this small simulated world. That is the result. General navigation, complete area coverage and real-robot transfer need their own measurements.
- One layout, used during development. New rooms, sensor noise and held-out starts are the next test.
- A scheduler with privileged pose. Real odometry must replace Gazebo truth for lap closure.
- A frontal stop, not a safety certificate. Rotation remains possible; physical clearance and stale-data handling need validation.
- Development runs, not a success-rate estimate. Revisions, failed attempts and a discarded contaminated recording are documented.
A conventional coded wall follower under the same conditions remains a useful next comparison, to evaluate the value of expressing this controller in weights.
Follow the numbers.
The code, trajectories and development records are available to inspect. The page is the short route through them.
Browse the run ledger here
Times are stored wall-clock episode durations. “Explored” is the original harness label; its meaning differs between the lane mission and frontier exploration.
| Run / JSON | Policy | Outcome | Episode (s) | Path (m) | Video |
|---|
Sparks of Weight-Space Programming
Rikiya Takehi, Jayden Teoh, Alex Zhang & Omar Khattab · November 2026.
This experiment adapts their idea to a ROS 2 / Gazebo development workflow. The original work already includes control tasks; no priority claim is made here.