Allostasis for machines
When a robot's load, charge or temperature changes, a familiar route can make very different demands. We explore how HDC memory could help it prepare for the journey ahead.
On this page
Imagine a delivery robot approaching a ramp it crossed earlier in the day, when its carrier was empty and its battery was full. This time, it has a heavy parcel on board, its motors are already warm, and it still needs enough charge to make it home after the delivery. It already knows the route, but what it knows may be a poor guide to what the climb will demand now.
The robot’s longer route would give it a gentler climb, though the delivery is already running late. As its operator, you’d probably want it to weigh those demands together: how much harder the motors will have to work under load, how much heat they can tolerate, and how much charge to leave for the journey home. By the time a temperature alarm sounds halfway up the ramp, the chance to choose the easier route may already have passed.
In nature, our bodies prepare for upcoming demands through a process biologists call allostasis. The robot’s predicament gives us a way to think about what that might mean for a machine. Could a robot use allostasis to draw on earlier trips to judge what it is about to take on, even when its load or charge has changed? In this post, we look at how Hyperdimensional computing (HDC) could help a robot find past experiences that are useful for the journey it faces now.
Think ahead while there is still a choice
Peter Sterling’s account of allostasis describes how an organism uses prior knowledge to anticipate its needs. The robot has a practical problem along these lines. It needs to estimate how much charge the climb would use and how warm the motors would get. Finishing the delivery is only part of the trip. It must get home too.
The temperature alarm stays. Any prediction can be wrong, so the robot needs to keep checking its motors as it moves. Looking ahead serves an earlier purpose: it gives the robot time to take another route. Engineers already use predictions to guide machines. Allostasis encourages us to consider how multiple demands, such as charge and cooling, should be managed together.
Someone has to define what the robot should protect. Battery charge and motor temperature have physical limits. The delivery deadline is a promise people make. The machine needs to consider both and have a clear way to ask for help if the safe route means arriving late.
What researchers have tried
Machine allostasis has a research history. Sánchez-Fibla and colleagues examined how interacting control systems shape behavior in allostatic control in a comparative rodent-robot study. A related path-planning paper connects the idea to navigation. The ramp example builds on a question roboticists have already been asking.
Guerrero Rosado and colleagues distinguish deciding which need takes priority from anticipating what will be needed later and using context. They test a computer model in which groups of simulated neurons compete to guide a virtual agent. For the robot, hot motors might take priority now. It would still need to work out what a climb would demand next.
Memory plays a part in CogSis, developed by Stovold, O’Keefe, and Timmis. The robot learns which cues in its surroundings to seek or avoid, then recalls them as needed. Some tests use a physical robot balancing charge and temperature requirements. They also simulate charge and temperature. Its memory is called a correlation matrix memory. The study gives us a precedent for needs guiding recall, although it does not test HDC.
Laurençon and colleagues study how an agent can learn to seek resources while its internal condition changes over time. Khan and Lowe’s active-inference preprint investigates regulation in a simulated agent with an artificial physiology. These approaches give us several ways to think about the problem. None tests our proposed use of HDC.
Remember the trip that helps now
Imagine reading the robot’s record of the morning trip. What was it carrying? How much charge did it have? What happened to the motors? HDC could help retrieve records from clues like these. Kanerva’s foundational treatment describes how information can be combined into patterns called hypervectors and compared with stored patterns. We propose using that kind of memory for robot encounters, where usefulness depends on resource conditions.
The pattern needs to distinguish each detail. A load description should be associated with the load, and a temperature reading with the temperature. HDC can combine those associations into a pattern to compare with others. A match would point back to the original trip record, where you can still inspect the measurements.
Now consider the morning trip again. It shows the same ramp, but the robot was empty. A record from another ramp, crossed with a heavy parcel, might be more useful for predicting motor heating. The important match depends on the decision the robot faces today.
In A category is something a system does, we describe a lens that changes which details matter. The ramp can keep its familiar physical description. The robot’s available actions change with its condition: climb, inspect the longer route, or seek help. Cooling or recharging could make the climb worth considering again.
For such a lens to work, it must affect the comparison. Load or temperature might get more attention, or the robot might search memory for conditions that match. Some HDC transformations leave the ranking unchanged when applied to both the query and every stored candidate. Bipolar and XOR binding have this property. The design needs a way to change which details are compared or how much they count.
A memory can also be a poor guide. The robot may have no record of a loaded climb. Its latest temperature reading may already be out of date. We should make those gaps visible. A close match doesn’t guarantee a safe journey: the robot needs to forecast resource use and check against its current limits before proceeding.
Give the onboard computer a budget
The onboard computer has work to do, too. A local HDC lookup could be an inexpensive place to start. Suppose it finds that grip mattered on earlier trips. The robot might then inspect the surface more closely before calculating a route. The extra processing would have a purpose: helping it avoid a bad choice at the ramp.
Existing HDC work offers some useful tools. HDCC turns HDC task descriptions into C programs for classification. MicroHD looks for smaller HDC models that use fewer computing resources while limiting accuracy loss. Its runtime analysis includes Cortex-M4 hardware. Neither study measures the robot system proposed here. We would need to account for the cost of sensing, processing, and moving data, as well as memory recall.
Memory updates can wait in the background while the robot checks for obstacles. Asking a remote model may be impossible if the connection drops. Even with a connection, the answer has to arrive in time to be useful. The robot needs an approved fallback when it cannot get an answer. These are practical choices about what must run now and what can wait.
Switching to a smaller model also needs testing. Can it still use the stored memories correctly? What does the switch itself cost? MicroHD’s optimization work does not establish that an arbitrary live memory can be safely cut down. We would need to validate each operating mode before relying on it during a trip.
Allostasis beyond the delivery robot
Whether the robot is choosing a route or deciding which computations can wait, it needs to prepare for what comes next with the resources it has left. Allostasis connects those choices through a common goal: anticipating demands early enough to adjust. HDC could help by recalling experience that fits the robot’s current condition, while forecasts and current safety checks determine which actions it can afford.
The same approach could work in other scenarios too:
- Inspection drones. Another camera pass might reveal a defect, but a stronger headwind could leave too little charge for the return trip. HDC could help recall earlier flights with similar wind, route and battery conditions, giving a flight-energy model relevant experience to draw on. The model would still need to check whether another pass leaves enough charge to get home.
- Stationary edge cameras. A camera may need to keep detecting movement while also reviewing footage or preparing summaries. HDC could help recall operating conditions in which that extra work caused the processor to overheat, informing a decision to postpone it. The aim would be to keep required detection running while less urgent analysis waits for cooler conditions or a lighter workload.
At HDC Labs, our other experiments give us reason to think HDC could help devices manage limited energy budgets. We are already testing ideas on small robots and circuit boards, and planning further experiments to see how past experience can help a device prepare for changing demands on its energy supply. We will publish what we learn as this work progresses.
If your machines repeatedly face a choice like this, bring an example to HDC Labs. What condition was the machine in, what did it choose, and what happened next? A record of that decision would give us a starting point for discussing whether memory could help it prepare earlier.