Cybernetic AI Agents for Robots - Stafford Beer's VSM (#2)

Now let’s talk about Cybernetics

The word cyber has been stretched in every possible sci-fi direction. It gives us cybermen, cyborgs, cyberpunk, and every variety of futuristic machine mythology. In popular culture, it usually means something digital, machine-enhanced, or vaguely threatening. Cybernetics is not a science-fiction aesthetic, it is a scientific and intellectual discipline concerned with control and communication in systems, e.g. biological, mechanical, or social.

Cybernetics began with Norbert Wiener, who established it as a formal field around control, communication, and feedback. From there, the field broadened through the work of thinkers such as W. Ross Ashby, Roger Conant, Stafford Beer, William T. Powers, and, in robotics, Rodney Brooks. Each contributed a different piece to the question of how systems persist, adapt, and remain effective in a changing environment.

Stafford Beer, the management theorist and philosopher, is especially important here. Beer’s major contribution was not about machine control, but the application of cybernetics to management and organizations. He was concerned with how complex organizations—companies, factories, governments, and institutions—could remain functional, adaptive, and coherent under changing conditions. His work developed into what is commonly known as the Viable System Model (VSM).

Beer’s key question was what makes a system viable. In this context, viability means more than simply functional or productive. It means the ability of a system to continue functioning as itself: maintaining coherence, adapting to change, absorbing disruption, and preserving its purpose despite internal complexity and external pressures. For organizations, this is essential. An organization that cannot coordinate itself, regulate itself, adapt to its environment, and remain aligned with its purpose will eventually drift, fracture, or fail. Beer’s model was an attempt to describe the minimum functions required for a system to remain viable over time.

In Beer’s model, viability depends on a set of interacting systems:

• System 1 – Operations -- This is the level where the actual work gets done. These are the operational units carrying out the primary activities of the system.
• System 2 – Coordination -- This system reduces conflict and oscillation between operational units. It helps ensure that the parts of the system do not work against one another and can function together in a stable way.
• System 3 – Control / Internal Regulation -- This level provides internal oversight of the operational systems. It allocates resources, enforces constraints, and ensures that the organization is functioning as a coherent whole.
• System 3* – Audit -- This is the auditing or monitoring function. It checks what is actually happening at the operational level, rather than relying only on reported summaries. It provides a direct channel for verification.
• System 4 – Intelligence / Environmental Scanning -- This system looks outward and forward. It monitors the environment, detects change, evaluates threats and opportunities, and considers how the system must adapt in order to remain viable.
• System 5 – Policy / Identity / Purpose -- This is the highest-order level. It defines the identity of the system, its governing policy, and its reason for existing. It is what ultimately anchors the rest of the organization.

The importance of this structure of divides responsibilities is that it establishes a relationship between immediate action, internal regulation, adaptation, and purpose. Lower systems can perform their responsibilities while being guided by the overall identity and purpose of the system. A viable organization can change its operations, coordination, and even its strategic posture, but it does so without losing itself.

Autonomy, resilience and Agents

That point connects to a broader cybernetic theme. An Agent is not meaningfully autonomous simply because it can perform tasks or optimize outputs on its own. What matters is whether it can regulate itself, adapt to change, and remain coherent while pursuing its purpose. In all cases, the environment will change, and that will inevitably require internal adaptation; cybernetics is best applied here to ensure that the adaptation keeps the system aligned to its purpose.

This is why cybernetics matters for the future of AI agents. Agents have become more capable, they are able to modify workflows, generate code, restructure processes, and adapt behavior. The problem is no longer repeatable execution. The real problem is how these types of adaptations remain organized, how they remain bounded, how they avoid drift, and how they continue to serve the original purpose of the system.

Application to Autonomous Robotics

This is where my interest is heading. My goal is a truly autonomous robot: a viable system that can operate, regulate itself, maintain its own health, adapt to change, and evolve without losing its purpose. AI agent technology makes this kind of autonomy far more achievable. But capability alone is not enough. For autonomy to be complete, it needs governance. It needs internal regulation. It needs a structure that allows adaptation without collapse, change without drift, and evolution without loss of identity. That is why Beer’s cybernetic model matters.

Next, I want to look at a modern adaptation of these ideas, and how to build a much better Totally Not Evil Robot Army.

Cybernetic AI Agents for Robots (#1)

 "The Future's So Bright, I Gotta Wear Shades"

[editor's note:  I have returned after a hiatus due to life, jobs, and other distractions (Factorio!! this is why we don't have my robots everywhere!). AI is everywhere now, but for my blog/writings I will still struggle to produce for you my thought content. I may use AI to shape it up and improve the clarity. But the thoughts written are mine.]

A new world of AI Agents

A great deal has changed in the world since 2025. AI has advanced significantly, and agent technology has taken a major step forward. It is becoming evident that AI systems are moving toward a higher level of intelligent capability, with important implications for robotics.

The core concept is straightforward. Instead of robots being purely deterministic systems—fixed sets of code that either follow predefined instructions or simply receive commands about what to do next—a robot could have the ability to analyze how to achieve a given result on its own. In other words, the system would be given a purpose or goal, but it would be allowed to determine its own approach. It could assess options, simulate possibilities, decide what to do, and then take action accordingly.

A key part of this shift is that AI agents today are beginning to show the ability to write quality code, rewrite code, adjust code, and modify their operating processes to better fit the goals they are trying to achieve. This is more than just using a Agent Planner with a set of Skills. It is the ability to build the Skills needed to accomplish an objective.

Oddly enough, much of this is still very linguistic and centered around the LLM. Large language models do not directly drive real-time operations well, but they do have the ability to write the code that can drive those real-time operations. That is where I think this begins to apply to robotics.

You could imagine a robotic system that has the ability to adapt to its sensors and reconfigure how those sensors are used. It could adjust how motion is implemented, or even how control systems are tuned, in order to achieve the result it is aiming for. This higher-level function would have to operate on a completely different layer than the real-time operating system, motion control, or sensor loop.

That difference in timescale is important. This higher level of operation would run on a different sequence of events than real-time sensing, actuation, and low-level control. But that does not mean it cannot exist. It simply means that the architecture must separate high-level adaptive reasoning from low-level real-time execution.

Such a system would likely require some connection to a large language model. Today, we have powerful models in the cloud, but AI and LLM technologies are rapidly being compressed into smaller footprints. Capabilities are increasingly moving toward deployment on smaller devices, to the point where something like this could eventually be embedded directly within a robotic platform.

This may also change how humans interact with machines. This is how we may begin to talk to robots. It is how you might talk to your car and ask what is wrong with it. It is how you might tell your dishwasher what you want it to do and have it respond conversationally, including explaining the likely impact of your command.

But that is only the first step. Talking to machines is one thing. The deeper shift is that the robot itself could have the ability to rewrite the code it uses to perform the functions it needs to do. That is a much more significant capability.

A robot like this could evolve over time. It could even reach the point where it can work with modular sensors or drive mechanisms, and when presented with new hardware, it could update its own operating parameters and implement new functionality on its own. In that sense, it would not merely execute control. It would adapt its own control.

And that leads naturally into Cybernetics...

PolyMap & MinOne - MinOne gets Log-Odds (#5)

Improving Minone and PolyMap with Log-Odds

I have recently upgraded Minone and the PolyMap mapping system, focusing particularly on enhancing our use of a Single Ultrasonic Sensor. While the sensor hardware remains unchanged, introducing the concept of "log-odds" has significantly reduced the impact of noise and false readings, making our maps clearer and more accurate.

What are Log-Odds? (Explained Simply)

Imagine you're guessing whether it will rain today. You might say there's a 50/50 chance—that's "even odds." Now, suppose new clouds roll in, and your chances become "likely" rain, maybe 75%. Each time you get new information, your confidence about rain happening or not happening changes.

Log-odds is just a special way of keeping track of these changing guesses. It turns probability—the chance something is true—into a number that's easier to update quickly. Positive log-odds numbers mean "more likely," negative log-odds numbers mean "less likely," and zero means completely uncertain.

Occupancy Grids - Binary vs Log-Odds

Applying Log-Odds in PolyMap's Occupancy Grids

In mapping, especially with sensors like the ultrasonic sensor used in Minone, each measurement tells us something about whether space is empty or occupied. However, sensors aren't perfect; sometimes they say there's something there when there isn't (false positive) or fail to detect something that really is there (false negative).

Using log-odds, The system doesn't just accept each measurement blindly. Instead, it builds confidence over multiple readings. Every time the ultrasonic sensor scans an area:

• A positive reading increases the log-odds, suggesting the area might be occupied.

• A negative reading decreases the log-odds, suggesting the area is likely empty.

Over time, genuine obstacles build a strong positive score, clearly marking them as occupied on our map. Meanwhile, random noise, causing occasional false readings, doesn't build enough consistent evidence, so these points eventually fade away, staying neutral or negative.

This approach makes the PolyMap occupancy grids more reliable and accurate, greatly improving how robots navigate and interact with their surroundings.

A Deeper Look into the Math of Log-Odds

Log-odds translate probabilities from their natural scale (0 to 1) into a 'logarithmic space,' which makes it easier and computationally more efficient to combine multiple pieces of evidence. In probability space, values close to 0 or 1 become increasingly difficult to update because small incremental changes can have disproportionate effects. By shifting to log-space, updating becomes straightforward additions and subtractions, maintaining precision across multiple sensor updates.

When updating log-odds:

• Positive evidence: If our sensor indicates an obstacle, we add a fixed positive log-odds increment, quickly shifting the belief towards occupied.

• Negative evidence: If the sensor suggests no obstacle, we subtract a smaller fixed increment, slowly shifting back towards uncertainty or free space.

To prevent numerical instability, clamps are applied to the log-odds values. These clamps set upper and lower bounds, ensuring values remain within practical limits, preventing overruns that could result in overly confident (extreme) occupancy or vacancy assertions.

This additive and controlled adjustment property allows for quick, stable, and efficient updating, even with multiple sensor readings, greatly enhancing computational efficiency and clarity in interpreting sensor data.

Practical Results from PolyMap

Since implementing log-odds in PolyMap, there are substantial improvements:

• Reduction of False Negatives: Previously, true obstacles were sometimes overlooked due to sensor noise and rapid changes in sensor readings. By quickly reinforcing log-odds with positive detections and slowly decreasing with negative readings, our system now reliably maintains the presence of real obstacles, significantly reducing false negatives.

• Clearer Obstacle Identification: True obstacles are now distinctly recognized after several confirmations, making navigation decisions safer and more confident.

These practical outcomes directly enhance robot efficiency, reducing navigation errors and improving path planning capabilities.

Future Improvements and Considerations

Moving forward, I will be exploring additional enhancements to further refine occupancy grid accuracy:

A key challenge is tackling the ultrasonic sensor's tendency to miss obstacles when pulses reflect at oblique angles, effectively making these obstacles invisible. This issue arises because the sensor’s sound pulse can deflect away, failing to return the echo needed for detection. To address this, I am considering several options:

• Sensor Fusion: Integrating data from multiple sensor types, such as infrared, alongside our ultrasonic sensor to build an even more accurate picture.

• Multi-Angle Sensors: Using multiple ultrasonic sensors at different angles to ensure obstacles are detected from various perspectives.

• Adaptive Orientation: Dynamically adjusting the sensor's orientation or positioning to better capture reflections from challenging angles.

• Enhanced Signal Processing: Implementing advanced signal analysis techniques to better distinguish weak echoes or indirect reflections.

I believe these improvements will further strengthen PolyMap's reliability, making the robot even smarter and more autonomous. 

PolyMap & Minone: First Test Results (#4)

Simple SLAM Robot: Initial Tests with PolyMap and Minone

Both the PolyMap mapping platform and the Minone robot have reached a level of functionality sufficient for their initial tests together. The early results are exciting, though clearly revealing room for improvement—exactly as anticipated!

Here's a video capturing these very first tests. Having this visual documentation will greatly help us track the robot's progression as we refine and improve the SLAM capabilities.

Overview of the First SLAM Tests

These initial tests show how well the mapping system, PolyMap, works together with Minone, a very minimal robot platform that is built around an ESP32 microcontroller. Minone, equipped with only a single ultrasonic sensor, navigated a confined hallway environment. All communication between the robot and the mapping software was successfully managed via MQTT, demonstrating effective real-time integration.

Minone, alone in the hallway.

In this test setup, Minone was in a hallway out of my vision. My phone was recording its movement. I sat in an adjacent room behind the door and was instructing the robot through the visualization. Commands were sent using MQTT to the robot and telemetry and map data was returned as previously discussed. In this test, I did have the reassurance that it was working, as I could hear the motor movement down the hallway.

Mapping Process and Key Observations

The PolyMap visualization provided live feedback during the tests with telemetry and maps. On the map you can see:

• Robot position was clearly indicated in orange.

• Obstacles detected by the ultrasonic sensor appeared in red.

• Unexplored areas remained marked in black.

• Telemetry shows the Pose (X, Y, Θ) and state: Manual

PolyMap Viz April 2025 (Totally Not Evil Robot Army)

The visualization effectively demonstrated the system's ability to build a cohesive map from successive sensor readings. However, the tests quickly highlighted significant limitations associated with relying on a single ultrasonic sensor:

• False negatives: The sensor occasionally failed to detect obstacles, particularly when encountering oblique angles. The pulsed ultrasonic signal reflects off the surface and does not return to the sensor, the device times out waiting, and returns a long distance (in this case greater than 170cm)

• False positives: There were numerous instances of the sensor incorrectly registering obstacles due to noise and sensor inaccuracies. This could be due to echos, but otherwise indeterminate (for me at this time).

Minone, False Neg due to Reflection in corner.

These limitations underscore a common challenge when using ultrasonic distance sensors. In simple SLAM test, there were no special filter applied or sensor data management used. This is a clear direction for improvement in the next code iteration.

Initial Conclusions and Immediate Next Steps

The primary next step is addressing the significant number of false positive and negative readings produced by the ultrasonic sensor. To tackle this challenge, the mapping algorithm will transition from a basic binary representation (occupied/free) to a probabilistic occupancy grid, employing the log-odds methodology. This approach should significantly reduce the influence of sensor inaccuracies by statistically weighting sensor readings over time.

Looking Ahead: Introducing Mintwo and Exploring Swarms

Future development plans include building an upgraded version of Minone: the Mintwo robot (?!?). This iteration will be enhanced by incorporating multiple IR time-of-flight sensors, dramatically enriching the data quality and robustness. The improved sensory capability of Mintwo will not only enhance individual robot performance but also lay the foundational work for exploring coordinated behaviors and swarm robotics, leveraging PolyMap’s scalable and distributed architecture.

Stay tuned as we continue to iterate and enhance both the PolyMap platform and our expanding army, ehr.. family of robots!

Minone – Getting the MV#Robot to Stable (#3)

Minone – Getting the MV#Robot to Stable (#3)

It's been a busy stretch since the last update! Many improvements, refactoring, debugging, and learning sessions have pushed the Minone MV#Robot toward a more stable and robust platform.

Code: Structure and States

Most of the recent effort has been dedicated to fleshing out software needed for remote operation. The robot's codebase has significantly expanded, particularly around the command structure. I've implemented a state model to handle essential high-level states:

• Standby: Robot awaits commands—especially useful after a reboot, allowing manual verification before resuming tasks.

• Manual: Direct control, crucial for immediate testing and remote operations.

• Autonomous: Fully independent operation. Future enhancements will include advanced exploration strategies, frontier search, and swarm coordination.

• Pause: Temporary halt; currently, the robot resumes directly into Autonomous mode.

• Error: Safety state activated by unexpected issues.

High-level state changes are now managed via an MQTT subscriber, enabling remote state-level commands. In Manual mode, the MQTT listener also accepts individual task commands for immediate execution.

To efficiently handle robot actions ("tasks"), I developed wrapper code that allows manual triggering for debugging flexibility. Additionally, during Autonomous mode, the Robot's Agent autonomously generates tasks, utilizing the same task infrastructure.

Precise Movement Challenges

One aspect differentiating a true robot from a toy or simple remote-controlled device is the ability to move precisely. For mapping and SLAM purposes, it is crucial to know exactly where the robot is and its pose. To understand how much a motor has turned, an encoder is used to 'count' the amount of rotation. Minone uses encoders that are built into recycled Roomba wheel modules I am using. Knowing the number of pulses per rotation and wheel dimensions allows precise odometry calculations—determining how far the robot moves or rotates.

Initially, Minone exhibited incorrect odometry during turns. Calculations seemed accurate—asking to move 10cm resulted in software reports of 10cm—but the physical movement was actually 20cm. This discrepancy first appeared in rotation measurements, which were exactly half the physical result. At first, I assumed calculation errors were related to the complexity of the turn calcuation. The wheels are rotating in opposite directions and you must factor in wheelbase dimensions. A quick patch improved turn precision slightly, but the underlying movement issues remained.

Digging deeper revealed encoder pulse counts were half the expected values. Although the very specific 508.5 pulses per rotation was correct, I initially misunderstood that this value included both rising and falling edges of the encoder's square-wave pulse. A small adjustment resolved this completely:

// --- Encoder Setup ---
void setupEncoders() {
  pinMode(LEFT_ENCODER_PIN, INPUT_PULLUP);
  pinMode(RIGHT_ENCODER_PIN, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(LEFT_ENCODER_PIN), leftEncoderISR, CHANGE);
  attachInterrupt(digitalPinToInterrupt(RIGHT_ENCODER_PIN), rightEncoderISR, CHANGE);
}

Switching the interrupt trigger from 'RISE' to 'CHANGE' allowed counting both edges. Problem solved! Recognizing this resolved earlier incorrect adjustments, making robot turns and movements significantly more accurate—not perfect yet, but sufficient for this prototype stage.

A cautionary note on AI-assisted coding: Unfortunately, my AI coding companion missed this nuance, underscoring the continued need to have some knowledge of what you are working with, both in code and hardware. The AI repeatedly suggested using 'RISE,' which cost significant debugging time. Only through examining code from other experienced developers—a big shout out to Bill at DroneBot Workshop—did I discover the proper approach.

Coordinate Systems & Rotational Model

Choosing a coordinate system for your robot is critical, impacting navigation, mapping, and visualization. Coordinate systems aren't always the simple math we learned in high school (traditional X/Y axes). You must consider the Z-axis for rotation and eventually 3D mapping, plus how your robot’s "frame of reference" relates to mapping standards reference. Surprisingly, industry standards differ significantly from basic Cartesian assumptions.

I selected a right-handed system (X-forward, Y-left, Z-up) for the robot frame, aligning with robotics conventions used in platforms like ROS. Positive yaw indicates counterclockwise (left) rotation, while negative yaw indicates clockwise (right) rotation. Though initially counter-intuitive, maintaining consistency across code and system interfaces is very important.

Downstream, the Map Manager and visualization components must translate these standards, especially when interfacing with game engines like Godot, which often uses a different convention.

Minone 11 APR 2025 - MV#Robot

Hardware Improvements

The prototype hardware has also been improved in this iteration. Adding a level shifter stabilized communication between components with different voltage domains. To safely power the ESP32 independently, I now directly use a clean 5V source from a power bank rather than the L298N's regulator.

Currently, the robot remains on a breadboard— a big messy rats nest of jumper wires. Future builds will transition to a safer proto-board with robust connectors for stability and better cable management, reducing risk of havoc from loose connections.

Demos: Seeing the Progress!

Here are short videos captured during the build process. The first demonstrates basic movement and scanning routines without intelligent decision-making:

The second video shows progress after foundational movements were implemented but before odometry corrections—movements rely on timing rather than accurate angle calculations. Since filming, accuracy has significantly improved!

Thanks for following along! The Minone MV#Robot journey continues—iterate, iterate, iterate!