A robot controller written directly into neural-network weights, in ROS 2 and Gazebo
A robot controller written directly into neural-network weights, in ROS 2 and Gazebo
The author implements a reactive navigation controller using a small multi-layer perceptron with directly authored weights in ROS 2 and Gazebo. The system achieves doorway crossing and completes three laps without gradient-based training or a full navigation stack. The implementation includes recorded trajectories, failures, and a configured Nav2 reference for context, currently limited to simulation.
The author demonstrates a reactive navigation controller implemented as a small multi-layer perceptron with directly authored weights in ROS 2 and Gazebo, achieving doorway crossing and three-lap completion without gradient-based training or full navigation stack components.
Source: ROS Discourse — Community updates · Read original article ↗
Article text · Original source · English
After reading Sparks of Weight-Space Programming by Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab, I wanted to try the idea on a robotics problem: could directly authored neural-network weights produce useful navigation behavior?
I set up two rooms, a doorway and a lidar-equipped robot in Gazebo. Fable 5.1 wrote and revised the weights of a small network; a ROS 2 node ran it and turned its outputs into motion.
Recorded Gazebo trajectory at 16× playback. A separate pose-based scheduler advances the three-lap mission.
The network is a 26 → 16 → 16 → 2 tanh MLP: 738 stored coefficients and biases, 78 nonzero in the final version. It takes reduced lidar readings and produces speed and steering signals, with no map, path planner or LLM call in the steering loop.
navigation-stack-vs-neural-policy1600×1430 159 KB
The crossed-out components are absent from this experiment’s steering loop. The network supplies reactive motion; it does not reproduce every capability of a full navigation stack. ROS 2, the drive interface and supporting command logic remain.
What made this interesting to debug was the connection between the weights and the resulting behavior. In one failed doorway run, a proximity unit was responding correctly, but other terms still dominated the turn. The activation trace pointed to the steering priority that needed changing.
After feedback-guided revisions, the controller crossed the doorway from several starts. With an external lane scheduler, it also completed three laps through both rooms.
Scan processing, command safeguards and that scheduler remain ordinary code outside the network. There was no gradient-based training, but there was iteration; the longer mission uses Gazebo true pose for lap closure.
I’ve published the implementation, recorded trajectories and failures, plus a configured Nav2 reference for context.
For now, this is simulation only. Over the next few days I’ll put it on the actual dum-e and see what happens. 
Suggestions, opinions and criticism are all welcome!
What the source reports
Publisher-reported claims, with original evidence. These results have not been independently verified by RoboSignal.
Reported numbers
stored coefficients and biases
738
View original evidence
on. Recorded Gazebo trajectory at 16× playback. A separate pose-based scheduler advances the three-lap mission. The network is a 26 → 16 → 16 → 2 tanh MLP : 738 stored coefficients and biases, 78 nonzero in the final version. It takes reduced lidar readings and produces speed and steering signals, with no map, path planner or LLM call in the steering loop. navigation-stack-vs-neural-policy 1600×1430 159 KB The crosse
Open source S3nonzero coefficients and biases
78
View original evidence
on. Recorded Gazebo trajectory at 16× playback. A separate pose-based scheduler advances the three-lap mission. The network is a 26 → 16 → 16 → 2 tanh MLP : 738 stored coefficients and biases, 78 nonzero in the final version. It takes reduced lidar readings and produces speed and steering signals, with no map, path planner or LLM call in the steering loop. navigation-stack-vs-neural-policy 1600×1430 159 KB The crosse
Open source S3laps
3
Reported trials
View original evidence
rms still dominated the turn. The activation trace pointed to the steering priority that needed changing. After feedback-guided revisions, the controller crossed the doorway from several starts. With an external lane scheduler, it also completed three laps through both rooms. Scan processing, command safeguards and that scheduler remain ordinary code outside the network. There was no gradient-based training, but ther
Open source S5
Dataset details reported by the source
- Modalities
- lidar Open source S3
- Tasks
- navigation Open source S2
- Embodiments
- dum-e Open source S6
- paper: not_reported
- code: Reported pending Open source S6
- dataset: not_reported
- code: not_reported
What remains unknown
Dataset licensing and commercial-use rights are not established here.
Source excerpts and review record
Automatically extracted; no manual editorial approval recorded.
After reading Sparks of Weight-Space Programming by Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab, I wanted to try the idea on a robotics problem: could directly authored neural-network weights produce useful navigation behavior? I set up two rooms, a doorway and a lidar-equipped robot in Gazebo. Fable 5.1 wrote and revised the weights of a small network; a ROS 2 node ran it and turned its outputs into moti
Open source S2
on. Recorded Gazebo trajectory at 16× playback. A separate pose-based scheduler advances the three-lap mission. The network is a 26 → 16 → 16 → 2 tanh MLP : 738 stored coefficients and biases, 78 nonzero in the final version. It takes reduced lidar readings and produces speed and steering signals, with no map, path planner or LLM call in the steering loop. navigation-stack-vs-neural-policy 1600×1430 159 KB The crosse
Open source S3
e was iteration; the longer mission uses Gazebo true pose for lap closure. I’ve published the implementation, recorded trajectories and failures, plus a configured Nav2 reference for context. For now, this is simulation only. Over the next few days I’ll put it on the actual dum-e and see what happens. Suggestions, opinions and criticism are all welcome! Article, replay and method · Code and evidence
Open source S6
rms still dominated the turn. The activation trace pointed to the steering priority that needed changing. After feedback-guided revisions, the controller crossed the doorway from several starts. With an external lane scheduler, it also completed three laps through both rooms. Scan processing, command safeguards and that scheduler remain ordinary code outside the network. There was no gradient-based training, but ther
Open source S5
Implications for data suppliers
RoboSignal interpretation and collection questions, not statements of buyer demand.
- Confirm the required data type and collection setting with the buyer; this source does not establish a complete collection specification.
- Compare the reported units and scope before using these quantities in a budget. Recording hours, sensor-hours and trajectories are different measures.
- Check the exact dataset version, license, modalities and task coverage against the intended use.
- Validate demand and acceptance criteria with a buyer before scaling. Publication, popularity and a research result do not establish a purchase commitment.
Source：ROS Discourse — Community updates · discourse.openrobotics.org