Hydraulic Heaven?

Since getting my custom pump to work well earlier this year, I've been pushing ahead on hydraulic actuator designs. There isn't a lot of miniature hydraulic equipment available for hobbyists, at least not at a good price, so I'm trying to make my own. I've settled on inflatable bladders as a fruitful direction to investigate - they don't have the same friction and seal wear issues as cylinders (syringes especially), and they can be customized in all manner of ways. In parallel, I've been working on moving parts designed to contain the bladders and be actuated by them.

Bladder Geometry

In the hydraulic demo from last year, I showcased my very first working bladder, which was a simple "pillow" - two rectangles of plastic film, with a valve stem inserted through the center of one rectangle, sealed together at their four edges. The problem with a bladder like this is that you can't get much range of motion out of it. When filled with fluid, it bulges a little - maybe a centimeter or so, at the small scales where I'm working. That wasn't enough for everything I wanted to do. I needed bladders with more complex geometries that could expand further, while still collapsing flat when fully deflated.

First of all I bought a heat-sealer, so I could melt plastic films together the professional way. (My first bladders were sealed with a soldering iron. The thought of going back to that method gives me the horrors.) This greatly improved the ease of making "pillows." Then I started trying for three-dimensional pouches with accordion folds. Getting all the little pieces of plastic lined up in the heat-sealer before they were attached to each other was too difficult, so I hit on the idea of sewing them together before sealing the seams. I even bought some plastic thread so that it could melt and be incorporated into the seal.

In short, I gave it a good try, but it was such a struggle. Sewing the little bladders together was a lot of work, and I never got one that was leak-free. It was particularly hard to get good seals where three seams met at a corner; no matter how much I might practice and refine the process, trying to make that on the heat-sealer was just plain awkward. Given how little success I had making wedge-shaped bladders with just one fold, I shuddered to think about my dreams of piston drivers with five or more. Manufacturing the bladders this way simply wasn't realistic.

 

So I found a better way. You can make accordion folds by sealing the sides of two pillows together at the center, cutting a tiny hole in the middle of the seal, and then sealing the edges of both pillows. This avoids a lot of fiddly cutting and sewing, and more importantly, there are zero three-seam corners. All the seals are two-dimensional even if the bladder as a whole is not!

Methods of creating central seals 

I made my first center seals by folding the plastic around a strip of cardboard and putting it in the end of the heat-sealer, once on each side. This was non-ideal; it created a very small sealed area, the crease where the film bent around the cardboard got melted too much and could develop holes, etc. A better method is to shield all but the circular region you want to want to seal together, then blast that area with a heat gun. You might think I should be using an insulator (like cardboard) for the shielding, but from my experience so far, metallic objects that will soak up the heat actually work better! So you can fuse your two pillows in the middle, then snip the very center of the sealed area with scissors to allow fluid through.

Bladder Materials

Throughout the process of figuring this out, I had lots of general quality problems. I seemed to need a double seal at each edge (seal once, fold the edge over, seal again) to have decent chances of a working bladder, and they still sometimes leaked. Well ... I think the printed layer on one side of my film was interfering with a good seal. You may recall that I was using plastic cut from salvaged Thriftbooks poly mailers. I started noticing that the green side with the company logos didn't seal as well. In fact, when I'm doing center seals with the heat gun, those must be made silver side to silver side; the printed sides simply won't fuse (though I can get them to fuse, somewhat poorly, on the heat sealer). And then the pillow edges have to be sealed green side to green side, which doesn't work so well! I also lost at least one bladder because a tiny flaw or strain in the plastic popped open the first time I put it under pressure. These flaws are present because the plastic has already been wrapped around a book and beaten up in transport.

So I finally bit the bullet and got some pristine plastic films to try out. When you buy materials, you have more control over what you're getting, so I sampled two different thicknesses: a 2 mil painter's dropcloth (transparent) and a 4 mil plant bed cover (black). Neither has any coating or printing on it, and they both heat-seal wonderfully. Now I can get good edge seals on the first try, without folding the edge over and doubling the seal.

Bladder Inlets

The last element I need to talk about is the attachment of the valve stems. After some early experiments with silicone gel that didn't have much success, I used cyanoacrylate (Super Glue) for my first working bladders. Eventually I also tried a polyurethane sealer intended for use on nylon tents and such. The brand I got is Gear Aid Seam Grip+WP. The cyanoacrylate works okay, but in my tests (sample size = 3 each), the polyurethane proved more likely to make a good seal. It is necessary to respect its long cure time; I actually consider that a positive, since I cannot seem to use Super Glue without getting it on my fingers and possibly other things nearby. One thing I have NOT tried yet is two-part epoxy.

So, okay, the glues are tolerable. But for real quality and durability, I would love to melt the valve stem and the plastic film together. So far all my attempts to heat-seal this part have been unsuccessful; they are two different materials and don't want to adhere. The option that remains is some sort of chemical weld. But it's hard to find anything that is safe and available for in-home use that will dissolve HDPE/LDPE film. I tried acetone on the off chance that it might work. It did smooth the surface of my PLA valve stems, but it never seemed to get them to a tacky or gooey state, and it did absolutely nothing to the films. So this may be a non-starter, unless I hear tell of a magical solvent that can do it.

Hydraulic Actuators

So how can we use all these bladders, exactly? After pondering how I might get one of them to operate my existing quadruped joint designs, I decided it would make more sense to come up with a new joint that was optimized to hold a bladder. Meet my hydraulic spade joint. A wedge-shaped bladder fits into one side of the backshell and pushes the spade upward (or forward, depending on the joint's orientation) when inflated. There are attachment holes for a tension element to return the spade to its original position when the bladder is depressurized. The spade's edge is constrained to remain in contact with the center of the backshell by a string tied through a hole in the spade and the backshell.

 

The other actuator I tried out was this simple cylinder. To produce its relatively large linear motion, I made a bladder with five accordion folds, my most ambitious one to date. I hadn't worked out the quality problems yet at that time, so this bladder leaked in multiple places ... but if I inflated it quickly enough, I could still practice driving the cylinder. So it worked as a proof-of-concept.

Conclusion

I think I have all the components I need now: the pump, the valves, and the actuators are working well enough that it's about time to see how things play in an integrated system. I might be ready to start the process of designing and budgeting full projects that use these parts. Look out for more of my hydraulics work next year (if not sooner).

Until the next cycle,
Jenny

Acuitas Diary #87 (August 2025, Allergic Cliffs demo)

It's ready! Acuitas can play the text version of Allergic Cliffs and is often able to determine one of the secret rules by which the cliffs operate. Watch the video watch the video

In a previous blog I discussed how Acuitas chooses moves based on a simple heuristic that tries to replicate successes and avoid repeating failures. The part I haven't fully discussed yet is the final version of rule formation. Acuitas attempts to generalize from the results of past moves to derive rules of cause and effect that indicate when the cliffs sneeze. At this time all possible move results are reduced to the two goal-relevant outcomes (succeed or fail), and generalizations are made by looking at commonalities among all actions that share the same result. I started by just comparing pairs of actions, then upgraded the algorithm to look at the entire pool of past actions for feature combinations common across two or more of them.

For the moment, all rules are given in positive form. So, supposing the rules for the current game round divide the zoombinis onto the lefthand bridge if they have a blue nose or the righthand bridge if they do not, you'll never hear Acuitas say, "If a guide puts a zoombini who does not have a blue nose on a lefthand bridge, a guide fails," or "If a guide puts a zoombini does not have a blue nose on a righthand bridge, a guide succeeds." Instead you would get "If a guide puts a zoombini who has a blue nose on a righthand bridge, a guide fails," or any of "If a guide puts a zoombini who has a [red, orange, green, purple] nose on a lefthand bridge, a guide succeeds."

I ended up not having time (in my completely self-imposed schedule) to implement experiments (purposely choosing moves that will falsify or confirm tentative rules) or rule-following (informing moves by rules to increase chances of success). So Acuitas still plays the whole game using the "similar to previous move" heuristic. At the end of the game, he scores all tentative rules that have not yet been falsified and selects the one with the highest score to announce out loud. The scoring system is of interest.

Rules with more evidence behind them (more moves which had those combinations of features in common) score higher, naturally. But I found that I needed another trick to more successfully pick out which tentative rule was among THE rules of the current round. Any action which is the cause in one of THE rules tends to have a counterpart which differs by one feature and produces a different effect. So if you have a rule like "Put a zoombini with an orange nose on the lefthand bridge and you will succeed," then if THE rules are about orange noses, there ought to be opposing rules such as "Put a zoombini with an orange nose on the righthand bridge and you will fail," or "Put a zoombini with a blue nose on the lefthand bridge and you will fail." If these opposite counterparts don't exist, then the orange nose + lefthand bridge = success association is probably incidental; some other feature is driving the cliffs' behavior, and it just *happened* that all the zoombinis allowed to cross the lefthand bridge also had orange noses.

There's a lot more fun I could have with this and many directions to extend it, obviously, but for now I'm finished. I'm toying with the idea of possibly sharing the Allergic Cliffs text adventure (not any part of Acuitas, just the independent game script) for others to use. I would want to polish it first, add documentation, and possibly implement the higher difficulty levels, so I can't say when that might happen.

Until the next cycle,
Jenny

ACE the Quadruped 2025

It's about time I blog about ACE (Ambulatory Canine Emulator). This project got neglected while I focused on completing Atronach and getting started with hydraulics, but I've been poking at it every now and then. My most recent conclusion is that I do, in fact, need to replace the PF35T-48 motors. Those bargain-basement unipolar steppers are just not good enough.

My last major overhaul of ACE was - gulp - three years ago. The quick summary is that I solved enough rigidity and tolerance problems that the skeleton could be posed standing at its full height, and repositioned the motors so that none of their weight had to be carried on the legs. Since then, I've been doing motion tests and refining the design of the ankle/hock joint.

Once I started trying to make parts of ACE *move*, it quickly became obvious that, out of the box, the PF35Ts didn't have enough torque to accomplish much. It was difficult for one of them to even swing the upper leg back and forth when it was hanging free - a relatively easy motion, since the only load was the weight of the leg itself. So I detoured into designing gearboxes, taking my motor cradle as a starting point and adding mounting tubes for additional drive shafts. A single gear designed to mesh with the little one that comes attached to the motor was good enough to enable upper leg motion (see the first video, above). But there was still no way that was going to be enough to operate the hock joints. My efforts to *really* gear these motors down led to the creation of the little beauty in the video below, with three gear pairs. I'm still quite proud of it.

I also fiddled with the hock joint design and some of the tendon routing, trying to optimize the mechanical advantage and reduce the strain on the motors as much as possible. In this new version, the tendons are more exposed, but I think I get better leverage out of the deal. So I tried the new joint prototype with the new gearbox, and no gravity loading the leg - it's just moving in a horizontal plane. How did it go? Not well.

It only managed to do as well as it did for that demo because I was over-volting the motor (I typically operate these at 5-6V.) Careful study of this test setup convinced me that the main problem was with the tendons binding against various corners they have to go around. But they're made of nylon fishing line, which presents a very low-friction surface, so they shouldn't be binding that *hard*. I think the latest joint design is about as good as it can get, and the gearbox is doing fine as well - I saw no evidence of the gears jamming or anything like that.

So with no weight on the leg, and the motor geared down so much that it's moving miserably slow, it's still stymied by a little friction. My guess is that I'm not getting the higher torque I expected because losses in the gearbox are consuming it; the amount available was so low to start with that I might not be able to make the situation much better, no matter how many gear pairs I add. Although there are some small adjustments I could make to reduce how tightly the tendons are bent around corners, I'm taking this test result as a sign that the motors are just not right for this project.

Fortunately, there are options with a much better torque-to-weight ratio out there. They do cost a little more, but I'm not budgeting as tightly as I was back in my college days. I've already selected some new models to try, and redesigned the motor cradles to hold them. (It's so nice to have a somewhat modular design.) Here's hoping for somewhat more progress when I get a chance to try them.

Until the next cycle,
Jenny

Acuitas Diary #86 (July 2025)

This month I continued work on trial-and-error learning for playing Allergic Cliffs. If you haven't read my introduction to this Acuitas sub-project and the subsequent progress report, I recommend taking a look at those. What I've done since has been debugging and enhancing the "feedback-informed actions" and "rule formation" features discussed in the progress report, and getting them to actually work. It turned out to be a fairly big job!

Now that "feedback-informed actions" is functional, though, I'm a little surprised by how well it works. Its essence is that, in the event of a success, Acuitas tries to make his next move as similar as possible; in the event of a failure, he makes certain his next move is different. This heuristic only considers feedback from the move immediately previous, so it's a reactive, barely intelligent behavior. It still enables Acuitas to win the game about 90% of the time! Granted, he is playing on the easiest difficulty level, and at higher levels it is quite possible this would not work. It's still a huge improvement over purely random move selection.

Candidate cause-and-effect rules are also being formed successfully, and marked invalid when violated by an example. What I need to do next is implement higher levels of generalization. Right now rule formation only looks at positive commonalities between pairs of examples, and I need to also consider commonalities across larger groups, and commonalities based on the absence of a feature rather than its presence. In some cases I can see the algorithm *reaching* toward discovery of the hidden rule that defines the Allergic Cliffs' behavior, but we're not quite there yet.

After getting that far, I decided to walk away for a bit to look at game-playing with fresh eyes later, and worked on narrative understanding some more. What I wanted to add was the concept of a role or job. It's important for Acuitas to be aware of character goals, but those goals aren't always explicitly stated. If I told you somebody was a detective, you would automatically assume that this person wants to solve crimes, right? You wouldn't need to be told.

Acuitas had an existing system that allowed the semantic memory for a concept (like "detective") to contain goals that override parts of the default "agent" goal model. But here's the tricky part: the goal model specifies *intrinsic* goals, and goals associated with a role aren't necessarily intrinsic! Adoption of a role is often derived from some instrumental goal, like "get money," which eventually ties back to an intrinsic goal like survival or altruism. The meaning of anything a character does in a role is shaded by how invested they are in performing that role, and why. So it became evident to me that role-related goals need to be nested under a goal that encompasses the role as a whole, which can then be tied to an intrinsic goal.

So I tweaked the semantic memory's goal definition format a bit, to include a way to distinguish role-related goals from intrinsic goals, and provided the Narrative engine with a way to pull those into the scratchboard when a character is said to have a role. For now, all roles have to be sub-categories of the concept "professional," but I can imagine other types of roles in the future.

Until the next cycle,
Jenny

A New Project?

I've been wanting to add some kind of physics experiment to my rotation of hobby projects, and I think I've picked one out. But I don't want to go into that just yet, because I'll be concentrating on the equipment prerequisites first. The most interesting thing I'll need is a way to measure tiny amounts of force - on the order of mN (milliNewtons) or even μN (microNewtons). Weighing scales are the most common force-measuring tools out there, so it makes sense to convert this force to a weight or mass. The amount of mass that produces a μN of force under standard Earth gravity is 0.000102 grams, or 0.102 milligrams.

Representation of a black hole, courtesy NASA.

Digital postal scales tend to have a resolution of 0.1 oz (2.8 g), which simply won't do. But there are also cheap digital scales intended for weighing jewelry, powders, etc. which claim resolution of up to 0.001 g (1 mg). Scales like this are all over sites like Alibaba and Amazon for less than $25 ... but they're short of the sensitivity I might need to see the effect. Going up an order of magnitude in price will get me an order of magnitude more precision, from this laboratory scale for example. For the really serious scales with a resolution of 1 μg, I would have to lay out over $10K. Technically that's within my grasp, but I'm not that invested in this experiment ... and I don't think I could claim to operate this blog on a "shoestring budget" anymore if I made such a purchase!

But wait! There's one more option: "build your own." Dig around a bit, and you can find some how-tos for building a scale that "is easily able to get around 10 microgram precision out of a couple of bucks in parts." The crux of the idea is to repurpose an old analog meter movement, adding circuitry that measures the electric current needed to return the needle to a neutral position after a weight is placed on it. The author of that Hackaday article "can’t really come up with a good reason to weigh an eyelash," but I can ... so now I'm really tempted by this build. It seems challenging but doable for someone with electronics knowledge. I don't really believe the budget would be 2 bucks ... any Digikey order costs more than that ... so let's figure $25.

To sum up, my options are as follows:

Consumer jewelry scale (Resolution = 0.001 g): ~$25
Laboratory scale (Resolution = 0.0001 g): ~$250
Home-built needle scale (Resolution = 0.00001 g): ~$25 + blood/sweat/tears
Professional microbalance (Resolution = 0.000001 g): ~$12000

Ideally, I'm thinking I should make the needle scale and buy the laboratory scale, so I can cross-check them against each other. As a home-made piece of equipment prone to all sorts of unexpected errors, the needle scale will benefit from some degree of corroboration, even if it can technically achieve a higher resolution than the lab scale. And either of these would put me in the right range to measure effects of a few μN, without breaking the bank. I really don't need the microbalance, thank goodness.

I'm not sure where I'll fit this into my schedule, but I've already got some analog meter movements, courtesy of my dad's extensive junk collection. So stay tuned to see if I can weigh an eyelash.

Until the next cycle,
Jenny

Peacemaker's First Strike

My short story of the above title will be LIVE and free to read in the 3rd Quarter 2025 issue of Abyss & Apex tomorrow! It's about a professional curse-remover who gets in a little over her head on an unconventional case; it's got mystery, magic, barbarians, and something to say about the consequences when defense of one's own goes too far. Ef Deal (at that time the Assistant Fiction Editor) was kind enough to tell me, "It has been a very long time since I read a sword & sorcery I enjoyed as much as this tale." So don't miss it!

I put something of myself in all my stories, but this one is more personal than most. It would be impossible for me to explain where it came from without airing some things that are better kept private, but in a roundabout and strange way, it reflects something I went through. So it feels particularly fitting that "Peacemaker's First Strike" should be my first paying publication credit. Turning this story loose means healing for me as well as the characters.

Abyss & Apex has been great to work with, so I'd love it if you would check out my writing and the rest of the issue, and support the zine with a donation if you are so inclined.

Until the next cycle,
Jenny

Acuitas Diary #85 (June 2025)

This month I have a quick demo for you, showcasing Acuitas' upgraded semantic memory visualization. My goal for this was always to "show him thinking" as it were, and I think I've finally gotten there. Nodes (concepts) and links (relationships between concepts) are shown as dots and lines in a graph structure. Whenever any process in Acuitas accesses one of the concepts, its node will enlarge and turn bright green in the display. The node then gradually decays back to its default color and size over the next few seconds. This provides a live view of how Acuitas is using his semantic memory for narrative understanding, conversations, and more.

You can see a previous iteration of my memory access visualization work in Developer Diary #4. Wow, that's ancient. The original access animations were only activated by "research" behavior (ruminating on a concept to generate questions about it), and were often hard to see; if the concept being accessed was one of the "smaller" ones, it was impossible to detect the color change at a reasonable level of zoom. The upgraded version of the animation is called from the semantic memory access functions, such that it will be activated if a concept's information is retrieved for any reason. And it enlarges the node by an amount proportional to its default size and the display's current level of zoom, such that it will always become visible.

I would have liked to make the links highlight when used as well. The problem is that links in Acuitas' memory storage aren't really distinct things anymore. A link is indirectly defined by endpoints included in the data structures for all the concepts it connects to. So there isn't a low-level function that determines when a particular link is being accessed; a node gets accessed, and then the calling function does whatever it pleases with the returned data structure, which might include following a link to another node. Keeping track of every time that happens and connecting those events with the correct lines on the display would have become very messy, so I opted not to. I think just highlighting the concept nodes yields an adequate picture of what's happening.

I haven't showcased the memory display in a long time because it's been a mess for a long time. The node placement is generated by a custom algorithm of my own. As more concepts were added to the graph and certain important concepts got "larger" (i.e. acquired more links), the original algorithm started to generate spindly, ugly graphs in which the largest nodes were surrounded by excess empty space, and the smallest nodes crowded too close together. I managed to work out a new placement method that generates attractive, proportional clusters without blowing up the computation time. Creating a new layout is still computation-intensive enough that the visualization can't be updated to add new nodes and links as soon as they are created; it must be regenerated by me or (eventually) by Acuitas during his sleep cycle.

And that's about the size of it. I'll be on vacation for the second half of this month, which means there probably won't be much Acuitas development happening until I get back. Enjoy the video, and I'll see you all later.

Until the next cycle,
Jenny