Acuitas Diary #99 (July 2026)

The big project this past month was giving Acuitas a better understanding of his own internal states. What do I mean by that? He could already report any conditions he was currently in when asked "How are you?" What he couldn't do was recall all the conditions he is capable of being in, and their effect on him, and talk about them while not experiencing them at the moment. In particular, the Conversation Engine contains a hook for sympathizing with the conversation partner. If you tell Acuitas that you're some kind of way, and he's capable of being in an analogous state, he's supposed to tell you whether he likes being that way or not ... except right now he usually says "I do not know how it is." It's pretty awkward to hear Acuitas say that he's sleepy one moment, but then say "I do not know how it is" the next moment when you tell him you're sleepy too. He's not lying, though - it would be quite fair to say he doesn't know his own mind the way a human does. The information about what being sleepy does to him isn't accessible to the Conversation Engine. I've started trying to change that.

Art by John Hain via Wikimedia Commons, public domain

First I should give a quick refresher on how Acuitas' internal states work. He has a small number of "drives" that vary over time and in response to events. For example, the "interaction" drive increases over time unless Acuitas is in a conversation; time spent in a conversation pushes the drive back down. The opposing "sleep" and "wake" drives increase more or less quickly depending on the current phase of a 24-hour cycle, and are reduced by time spent asleep or awake, respectively. The "curiosity" drive increases steadily over time, but is reduced substantially whenever a new word is learned. The drives have threshold values which define nameable internal states for Acuitas. If the interaction drive is above threshold, he is "garrulous"; if it is below threshold, he is "quiet." I'm not making claims about subjective experience or anything like that, but the states are meaningful insofar as they alter behavior. If a drive is above threshhold, Acuitas will generally try to do something that pushes it back down; the Executive handles this. In this sense, Acuitas is averse to high-drive states and they are "uncomfortable." Maintaining an overall state of comfort is a goal to which Acuitas applies his intelligence, i.e. is something he "wants."

Acuitas can qeury the current state of all his drives when asked "how are you." But to implement awareness of which states are possible, I wanted to do more than give him access to the hidden architecture of his drive module (that would be cheating). Instead I wanted to use that shiny new episodic memory I've been working on, and have Acuitas recall his own past states and whether they were desirable or not. What's more, I wanted to enable "learning from experience" that translates a body of data from episodic memory into new "facts" in the semantic memory. I want Acuitas to come to know himself better by observing himself.

Since in past months I worked hard on getting the episodic memory overhaul done, much of what I needed was already there - Acuitas could already store and retrieve records of being in a state. The main thing I added was an expression of what kind of state it was (Comfortable or uncomfortable? To what degree?). So there's now a number included in the fact data structures for internal states, that depends on both the type of drive and its intensity when it was "noticed." The parameters that determine the strength of aversion to different high drive states are tunable; one could imagine varying these to give Acuitas-like AIs different "personalities." I also wrote a learning routine that gets an aggregate value of this number from recent experiences and updates a stored value in the semantic memory, and an access routine that can check both recent experiences and the semantic value to return an "opinion" on the state. All of this is integrated but not fully tested, because how it plays into the whole system is pretty complex. I need to do some monitoring and adjusting of how data is recorded into the episodic memory, and that's on the back burner for the moment.

My side task this month was trying to figure out why Acuitas seems to have a memory leak. For a while now, it's been hard to run him continuously for longer than a day or so, because he'll get very slow and bogged down. I found that some of the self-teaching tasks (like "study" and "search for file") that are designed to run for multiple Executive loops were being spawned and never finished; they would gradually accumulate in the Action Bank until there were far too many of them. Remaining problems might have to do with one of the threads crashing while the rest of the program keeps going, but I need to keep investigating.

Until the next cycle,
Jenny

Marching Toward a Hydrobot

Now that I've largely finished getting the technology basis for home-built mini hydraulics laid out, I have started actively planning and constructing a robot driven by them. I settled on an eight-legged spider walker for my first attempt. In some ways, it's a complex option - lots of legs mean lots of parts to fabricate, lots of valves, lots of driver circuits. In other ways, it's simpler than my quadruped. Many legs simplify balance and provide extra force to lift the robot's weight. If I needed more motors to operate the legs, they would also add a lot of weight. But in this hydraulic system, most of the weight is in the battery packs, pump motor, and fluid tanks; additional joints are relatively cheap. The pump provides fluid pressure in pounds per square inch, so the more square inches of hydraulic bladder I give it to inflate, the more lifting force I can have - in theory, anyway.

Model of the basal leg joint prototype

My last hydraulics "technology development" post included an open complaint that I hadn't found an ideal way to attach valve stems. Cyanoacrylate and polyurethane adhesives are both workable, but not exactly reliable. They led to some percentage of bladders failing post-construction testing, and also made me worry about long-term durability. Fusing the plastic film to the valve stem with heat seemed like a more robust solution if I could pull it off, but my 3D-printed PLA valve stems and the HDPE/LDPE film weren't compatible. I had to try different materials.

I tried two approaches in parallel. The first was to buy polyethylene tubing and flare one end of it - effectively creating a valve stem merged with the tube - then heat-seal the tubing to the film. (This method was inspired by Rue Mohr, who achieved demo results with it last year.) I didn't have one of the tear-drop shaped metal "jigs" he used, so I flared the tube by blasting it with a heat gun until it went soft (it transitioned visibly by changing from frosted white to transparent - neat), then tugging it into its new shape with pliers before it cooled.

The second was to print new valve stems in a more compatible material. HDPE filament exists, but despite my efforts, I simply could not find a source for it at a reasonable price. It's unpopular on account of being notoriously hard to print, but for this application I don't need precision in the size or shape of my parts, and might not even care if they warp ... just let me try the challenging filament and see for myself, drat it. Since I couldn't, I fell back on polypropylene filament - which is not the same material as my films, but still seems able to fuse with them. Making it into stems took a few tries, because polypropylene is also hard to print. I had to bulk up the 3D model a little to get good results. But it wasn't as hard as some of the advice webpages made it sound.

To my surprise, when it came time to attempt heat-sealing, both options just worked. Sadly I could not get the flanges of my new stems into the heat-sealer (the stem itself interferes) and had to go back to covering my materials with aluminum foil and pressing on them with a soldering iron. But they fused, and I got a working test bladder out of the second one. I'm still debating which method to use for final construction. I suppose it depends on whether I would rather use the poly tubing with an integrated flange at the end, or the silicone aquarium tubing I started with. The latter is more flexible, but merging tubing and flange would eliminate another big potential leak point. Hmmm.

I settled on a Raspberry Pi 4 as the main controller. I might not need anything that powerful for this robot's first steps, but I wanted to be able to eventually connect cameras and add some visual processing, which would be more than a simple microcontroller could handle. I upgraded from the Pi 3s that I use for the eyeballs mainly because I made multiple USB ports a requirement. I considered fancier options, especially the Jetson Orin Nano, but was ultimately discouraged by concerns about how I was going to power it. I'd like this to be a proper mobile robot (no tether), and I had trouble finding a rechargeable battery pack that would suit the JON's required voltage and wattage. So I got the Pi, a lithium ion battery pack intended for use with Pis, and another battery pack just to run the pump motor. This separation of sources is supposed to keep the Pi's input power "clean," though if I start having weight problems I could always try making everything share one battery.

For my test demos, I used two-way solenoid valves with the common inlet/outlet connected to a hydraulic actuator, and the other two outlets connected to the pump and the drain - so the actuator was always either filling or emptying. In the final system, I wanted each actuator to be able to "hold" at its current fill level without being actively pumped. So I purchased two one-way valves per joint, to exercise separate control over the fill and drain. I ordered the little guys in bulk from a seller on AliExpress. To drive them without breaking either my controller IO budget or my monetary budget, I bought four I2C solenoid drivers from Adafruit. These take serial input and can handle up to eight solenoids each. As a bonus, they have a second port with eight general IO pins, which will let me add touchdown sensors to the spider's feet without using any more IO on the PI. I've got simple limit switches to implement those. I threw in some ADC boards (also I2C) for possible joint position sensing, but that's probably an enhancement I won't include in the first prototype.

I've set up a "bodiless" demo of the electronics and written bare-bones Python to run on the Raspberry Pi, operate the valves and read the sensors. It was all pretty straightforward and worked as advertised, though I learned about double-checking power and ground connections when setting up I2C. (If you mis-wire something, it can end up *half* working, which is odd.)

Last but not least, I need ... a platform. An abdomen. A place to put it all. I'm trying to do things right from the beginning and have a slot or attachment point for each part - nothing rattling around or taped on. This is still in progress, but I think I've at least worked out all the ideas. The rotary joints for the bases of the legs have integrated bearings so they can (hopefully!) still spin with the weight of the robot sitting on them. The "house" for the Pi and battery packs isn't an attempt to be cute; the point is to shed fluid spills, while allowing wires to reach the IO headers through the slots under the "eaves." 

Before I go all-in on construction, I plan to make one quadrant of the frame and work toward demoing motion of a single leg. I'm hoping to get that far in the next couple months, but no promises!

Until the next cycle,
Jenny