Further Thoughts on Motion Tracking

Atronach's Eye may be operating on my wall (going strong after several months!), but I'm still excited to consider upgrades. So when a new motion detection algorithm came to my attention, I decided to implement it and see how it compared to my previous attempts.

MoViD, with the FFT length set to 32, highlighting and detecting a hand I'm waving in front of the camera. The remarkable thing is that I ran this test after dusk, with all the lights in the room turned off. The camera feed is very noisy under these conditions, but the algorithm successfully ignores all that and picks up the real motion.

I learned about the algorithm from a paper presented at this year's GOMACTech conference: "MoViD: Physics-inspired motion detection for satellite image analytics and communication," by MacPhee and Jalai. (I got access to the paper through work. It isn't available online, so far as I can tell, but it is marked for public release, distribution unlimited.) The paper proposes MoViD as a way to compress satellite imagery by picking out changing regions, but it works just as well on normal video. It's also a fairly simple algorithm (if you have any digital signal processing background, otherwise feel free to gloss over the arcane math coming up). Here's the gist:

1. Convert frames from the camera to grayscale. Build a time series of intensity values for each pixel.
2. Take the FFT of each time series, converting it to a frequency spectrum.
3. Multiply by a temporal dispersion operator, H(ω). The purpose is to induce a phase shift that varies with frequency.
4. Take the inverse FFT to convert back to the time domain.
5. You now have a time series of complex numbers at each pixel. Grab the latest frame from this series to analyze and display.
6. Compute the phase of each complex number - now you have a phase value at each pixel. (The paper calls these "phixels." Cute.)
7. Rescale the phase values to match your pixel intensity range.

The result is an output image which paints moving objects in whites and light grays against a dark static background. I can easily take data like this and apply my existing method for locating a "center of motion" (which amounts to calculating the centroid of all highlighted pixels above some intensity threshold).

My main complaint with the paper is its shortage of details about H(ω). It's an exponential of φ(ω), the "spectral phase kernel" ... but the paper never defines an example of the function φ, and "spectral phase kernel" doesn't appear to be a common term that a little googling will explain. After some struggles, I decided to just make something up. How about the simplest function ever, a linear function? Let φ(ω) = kω, with k > 1 so that higher frequencies make φ larger. Done! Amazingly, it worked.

Okay, math over. Let me see if I can give a more conceptual explanation of why this algorithm detects motion. You could say frequency is "how fast something goes up and down over time." When an object moves in a camera's field of view, it makes the brightness of pixels in the camera's output go up and down over time. The faster the object moves, the greater the frequency of change for those pixels will be. The MoViD algorithm is basically an efficient way of calculating the overall quickness of all the patterns of change taking place at each pixel, and highlighting the pixels accordingly.

It may be hard to tell, but this is me, gently tilting my head back and forth for the camera.

My version also ended up behaving a bit like an edge detector (but only for moving edges). See how it outlines the letters and designs on my shirt? That's because change happens more abruptly at visual edges. As I sway from side to side, pixels on the letters' borders abruptly jump between the bright fabric of the shirt and the dark ink of the letters, and back again.

The wonderful thing about this algorithm is that it can be very, very good at rejecting noise. A naive algorithm that only compares the current and previous camera frames, and picks out the pixels that are different, will see "motion" everywhere; there's always a little bit of dancing "snow" overlaid on the image. By compiling data from many frames into the FFT input and looking for periodic changes, MoViD can filter out the brief, random flickers of noise. I ran one test in which I set the camera next to me and held very still ... MoViD showed a quiet black screen, but was still sensitive enough to highlight some wrinkles in my shirt that were rising and falling with my breathing. Incredible.

Now for the big downside: FFTs and iFFTs are computationally expensive, and you have to compute them at every pixel in your image. Atronach's Eye currently runs OpenCV in Python on a Raspberry Pi. Even with the best FFT libraries for Python that I could find, MoViD is slow. To get it to run without lagging the camera input, I had to reduce the FFT length to about 6 ... which negates a lot of the noise rejection benefits.

But there are better ways to do an FFT than with Python. If I were using this on satellite imagery at work, I would be implementing it on an FPGA. An FPGA's huge potential for parallel computing is great for operations that have to be done at every pixel in an image, as well as for FFTs. And most modern FPGAs come with fast multiply-and-add cells that lend themselves to this sort of math. In the right hardware, MoViD could perform very well.

So this is the first time I've ever toyed with the idea of buying an FPGA for a hobby project. There are some fairly inexpensive FPGA boards out there now, but I'd have to run the numbers on whether this much image processing would even fit in one of the cheap little guys - and they still can't beat the price of the eyeball's current brain, a Raspberry Pi 3A . The other option is just porting the code to some faster language (probably C).

Until the next cycle,
Jenny

Acuitas Diary #83 (April 2025)

I'm eager to get started on trial-and-error learning, but in the spirit of also making progress on things that aren't as much fun, I rotated back to the Conversation engine for this month. The big new feature was getting what I'll call "purposeful conversations" implemented. Let me explain what I mean.

Euphonia, a "talking head" built by Joseph Faber in the 1800s.

A very old Acuitas feature is the ability to generate questions while idly "thinking," then save them in short-term memory and pose them to a conversation partner if he's unable to answer them himself. This was always something that came up randomly, though. A normal conversation with Acuitas wanders through whatever topics come up as a result of random selection or the partner's prompting. A "purposeful conversation" is a conversation that Acuitas initiates as a way of getting a specific problem addressed. The problem might be "I don't know <fact>," which prompts a question, or it might be another scenario in which Acuitas needs a more capable agent to do something for him. I've done work like this before, but the Executive and Conversation Engine have changed so much that it needed to be redone, unfortunately.

Implementing this in the new systems felt pretty nice, though. Since the Executive and the Conversation Engine each have a narrative scratchboard with problems and goals now, the Executive can just pass its current significant issue down to the Conversation Engine. The CE will then treat getting this issue resolved as the primary goal of the conversation, without losing any of its ability to handle other goals ... so greetings, introductions, tangents started by the human partner, etc. can all be handled as usual. Once the issue that forms the purpose of the conversation gets solved, Acuitas will say goodbye and go back to whatever he was doing.

I also worked on sprucing up some of the conversation features previously introduced this year, trying to make discussion of the partner's actions and states work a little better. Avoiding an infinite regress of either "why did you do that?" or "what happened next?" was a big part of this objective. Now if Acuitas can tie something you did back to one of your presumed goals, he'll just say "I suppose you enjoyed that" or the like. (Actually he says "I suppose you enjoyed a that," because the text generation still needs a little grammar work, ha ha ha oops.)

And I worked on a couple Narrative pain points: inability to register a previously known subgoal (as opposed to a fundamental goal) as the reason a character did something, and general brittleness of the moral reasoning features. I've got the first one taken care of; work on the second is still ongoing.

Until the next cycle,
Jenny

Pump and Hydraulics Progress

If you've been following for a while, you may know I've been working on pump designs for a miniature hydraulic system. The average commercially available water pump appears to be optimized for flow rate rather than pressure, and small-scale hobby hydraulics are barely a thing ... so that means I'm custom-making some of my own parts. Last year I got the peristaltic pump working and found it to be a generally better performer than my original syringe pump, but I always wanted to get a proper motor for it.

The original motor powering all the pumps was an unknown (possibly 12 V) unipolar stepper and gear assembly from my salvage bin. But the precision of a stepper motor truly wasn't necessary in this application, and was costing me some efficiency. For the upgrade, I wanted a plain gearmotor (DC motor + gear box assembly) with a relatively high torque and low RPM. I settled on this pair of motors, both of which are rated for 6 V input:

SOLARBOTICS GM3 GEAR MOTOR (4100 g-cm, 46 rpm)
Dagu HiTech Electronic RS003A DC Motors Gearhead (8800 g-cm, 133 rpm)

You can tell from the torque and speed ratings that the Dagu HiTech was always going to be the better performer. I included the Solarbotics motor in my order because its gearbox and housing are plastic, which may reduce durability but also means it weighs less. In practice, it also draws less current than the Dagu motor, which might mean the power source can weigh less ... these things are important when thinking about walking robot applications!

The next step was to reprint the pump. I left the main pump design essentially unchanged - all I did was correct the geometry errors from the previous iteration. So this time it worked after assembly without an extra shim, and I could put the lid on properly without needing zip ties to hold it closed. The motor housing and coupler were always separate pieces, so I designed two new versions of each, one for the Dagu motor and another for the Solarbotics motor. This is where the 3D printers reeeeaally show off their value. Compared with both the old stepper and each other, the new motors have completely different sizes, shapes, drive shaft designs, and mounting options, but I was able to produce custom parts that mated them to the pump in only a few hours of actual work.

And the test results were amazing. The Dagu is obviously more powerful and delivers a higher flow rate, but both motors have enough torque to drive the pump at the 6 V they're rated for.

Watch to the end for a surprise appearance by the Lab Assistant.

I pressure-test my pumps by dropping a piece of tubing from my second-story window to the back patio, and measuring how high the pump can lift water in the tube. From this it is possible to calculate PSI. I have published results from the previous pump designs. Well: Peristaltic Pump Version 3 can lift water all the way past the window with either motor. Given the water level etc. in this particular test, that's a total lift height of 170 inches. So the pump is producing at least 6 PSI, and I can't measure any higher than that. This makes it competitive with the syringe pump for pressure (at least as far as I can tell - the syringe pump also exceeded my maximum ability to measure), and MUCH better for flow rate.

When I was testing the syringe pumps last year, I used to go read a book for a little bit while I waited for the water to climb to its maximum height! I timed Peristaltic V3 with the Dagu motor, and it can get the water all the way up the tube (standard 1/4" aquarium tubing) in about 24 seconds. So this is a dramatic improvement on where I was when I started.

Hydraulics testing: it gets messy

One little problem remains: I've noticed that, with these more powerful motors, the friction between the latex pump tubing and the rollers gradually pulls the tube through the pump. It'll keep shortening on the intake side and eventually lift out of the water. So I need something to hold it in place without clamping it and blocking the flow. Piercing the tube seems like the only solution for this. I could do it below the water line, OR, the tube is thick-walled enough that I bet I could put a very thin thread or wire through the wall without creating a leak.

I've also started on new actuators, but that is mostly a story for another day. I did get a "knee" style of joint working to the point of a basic demo. Once I started trying to adapt my existing quadruped hinge joint for hydraulic power, I realized it would be less complicated to make an entirely new design that naturally incorporates the hydraulic bladder. Next I need better bladders ... I'm working on that!

Until the next cycle,
Jenny

Acuitas Diary #82 (March 2025)

This month I've made a long-awaited return to the Game Engine (see the demo from June 2023) with ambitious plans to improve Acuitas' reasoning and agency. Specifically, I want to introduce some experimental learning abilities. And I'm hoping to do that by getting him to play Allergic Cliffs.

What is that? There's a reason I wrote a game showcase on Logical Journey of the Zoombinis earlier this month. "Allergic Cliffs" is the first puzzle in every journey. It's a hidden information game, with some underlying ties to Set Theory.

An example of the original Allergic Cliffs. It appears the righthand/foreground cliff is allergic to "two wide eyes" in this scenario. Screenshot by jdl on the Wonderland Forum.

In brief, there's a chasm with two bridges spanning it, and you want to get all your zoombinis across. The complicating factor is the presence of two stone faces in the cliffs on the chasm's far side. These beings are quite literally allergic to zoombinis with (or without) certain attributes. Putting a zoombini on the bridge that passes over the wrong cliff will cause the face to sneeze violently, shaking the bridge and tossing the hapless zoombini back to the near side. After enough mistakes, both bridges fall, and you have to leave behind any zoombinis who didn't make it over. Here's a video of someone playing Allergic Cliffs.

Since you're only allowed a limited number of failures, you can't brute-force the puzzle by setting every zoombini on both bridges. You need to be trying to learn which zoombini features make the cliffs sneeze. And to be sure of learning this before the bridges fall, you have to perform targeted experiments. Why did this zoombini get across? Why did that one get sneezed at?

Acuitas can't play the original Zoombinis game, obviously; it's far too visuo-spatial. He needs a text version. The author of the Storeroom Blog has kindly written up a full breakdown of the Allergic Cliffs game mechanics. I will only be expecting Acuitas to play on the easiest difficulty level, for the time being. So every round will require choosing a zoombini feature that one cliff will be allergic to and the other cliff will be immune to (i.e. allergic to all zoombinis who don't have the feature). This rule is kept secret, but must be used to inform descriptions of what the cliffs do when zoombinis are placed on the bridges. Each scenario also includes the group of sixteen zoombinis, with known characteristics, whom the player is trying to get across the chasm.

In my first demo of the Game Engine, I behaved as a "game master"; I initiated the game during a conversation with Acuitas, then kept interacting with him to describe the setting and the results of his in-character actions. But I don't want to do that in this case. Do you know how much effort it takes to fully describe a group of sixteen zoombinis? Lots, actually. I am not going to type that up and paste one line at a time into Acuitas' text box every time we play! This game needs to be automated.

So I wrote an independent, interactive Python program that implements a "text adventure" version of Allergic Cliffs. When launched, the game program generates sixteen zoombinis with randomized names and attributes, and a set of rules for the cliffs. Then it outputs a text description of the scene, the player character and their goal, and all the zoombinis. Acuitas, using the "Play" action, can run this script and connect the IO to his Game Engine. The script includes a very dumb parser that scans Acuitas' speech outputs for signs that he's moving a zoombini, and replies "you can't do that" to anything else. If Acuitas puts a zoombini on a bridge, the Allergic Cliffs script tells him the results. It also keeps track of the game's state; if it reaches either the win condition (all zoombinis on the far side) or the loss condition (fallen bridges), it will tell Acuitas "Game Over" and terminate.

This is something of a milestone, since it's the first time Acuitas has been able to launch and use a subordinate software tool. It was also more difficult than I expected. It's easy to launch another executable from a Python program using subprocess, but getting them to interact is another matter; by default, the main program expects the subprocess to run to its end, produce one burst of output, and be done. I ended up using the temporary file trick (described in the second answer). Both the Acuitas side and the independent program side send outputs, then wait for a response to appear in either the PIPE or the file, then formulate and send new outputs ...

Recreating Allergic Cliffs without all the graphics ended up being fairly simple, though. The game script is under 250 lines of code. Here's the boilerplate it uses to set the scene at the beginning of any game run:

"You are a guide."

The player character in LJotZ is referred to as the "guide" of the zoombinis; that's it. We don't even know what species this person is.

"You are at the Allergic Cliffs."
"There is a chasm."
"The chasm has a near side."
"The chasm has a far side."
"The far side has a lefthand cliff."
"The far side has a righthand cliff."
"There is a lefthand bridge over the chasm."
"There is another righthand bridge over the chasm."

Thanks to my January work on adjectives and distinct instances, the lefthand bridge and the righthand bridge can be distinguished. I'm using these words instead of "left" and "right" to avoid tricky sense disambiguation issues for now.

"You can put a zoombini on the lefthand bridge."
"You can put a zoombini on the righthand bridge."

Here the game gives the player affordances - that's a fancy name for obvious possible actions. In the original, these are communicated visually. Clicking on a zoombini "picks them up" (they start following the cursor and their locomotion devices dangle). Two patches of ground next to the bridges flash if the zoombini is moved over them, as a sign that the zoombini can be set down there.

"If a zoombini crosses a bridge, the zoombini will be on the far side."
"If you put a zoombini on a bridge, the zoombini will try to cross the bridge."

A couple of inference rules specific to this setting, to aid in problem-solving. I'm not sure whether I'll keep them in the final version, or have Acuitas learn this mechanic for himself too.

"You want all zoombinis to be on the far side."

This sentence establishes a goal for the player character. In the original, this would have been implicit in the narration and premise.

"Six pegs hold the bridges up.",
"If all pegs pop loose, the lefthand bridge will fall.",
"If all pegs pop loose, the righthand bridge will fall.",
"If a bridge falls, a zoombini cannot cross the bridge."

A warning about the loss condition, which thwarts the goal.

And that's it. Even a lot of the descriptions of the scene are just pretty nothings; the important part is the existence of the two bridges and the fact that the player can put zoombinis on them.

Here's an example description of a zoombini:

Oosebeek is a zoombini.
Oosebeek is on the near side.
Oosebeek has scruffy hair.
Oosebeek has eyelids.
Oosebeek has an orange nose.
Oosebeek has wheels.
Oosebeek does not have a ponytail ...

That's right, I also have the game script tell Acuitas every possible zoombini feature that this zoombini does not have. If not told that something is true, Acuitas doesn't assume it's false. Maybe this zoombini has wheels and a propeller, and nobody mentioned the propeller! Another way I could handle this would be to establish mutual exclusivity rules, like "if a zoombini has wheels, the zoombini does not have a propeller," and let him infer all the negatives. But this is an easier way to start.

I had to tweak some of the code behind the Narrative scratchboard for this as well. I introduced "temporary concepts" so Acuitas won't memorize the names of all sixteen zoombinis every time he plays a round. That would junk up the semantic database quickly. Playing this game much can easily lead to interactions with hundreds of zoombinis, and their names are procedurally generated strings. They're made to be loved, but not remembered.

If Acuitas puts a zoombini on the safe bridge, the game will tell him what happens afterward:

Oosebeek crosses the righthand bridge. (Acuitas has to infer that Oosebeek is now on the far side.)

If Acuitas puts a zoombini on the bridge over the cliff that's allergic to them, he gets this kind of response instead:

Oosebeek tries to cross the lefthand bridge.
The lefthand cliff sneezes.
Oosebeek is thrown to the near side.
Oosebeek cannot cross the lefthand bridge.
The first peg pops loose.

My goal for this month was to get Allergic Cliffs set up and make it possible for Acuitas to play. He's not any good at the game yet. His Game Engine is aware of the goal but has no idea how to reach it - so it falls back on trying the actions offered by the affordances. He'll keep putting a randomly chosen zoombini on a random bridge until he either loses or wins by dumb luck. After he's finished, the game-playing action generates a flow diagram from the game's narrative scratchboard for me; between that and the game outputs written to the temp file, I can see what happened.

Later this year I'll work on trial-and-error learning so he can actually win. This is a brand new area for me, and I'm excited.

Until the next cycle,
Jenny

Foundations Part II: They're Bluuuuue

Yeah, this series has a Part I - bet you thought I'd never finish it! It's time for me to showcase my other favorite edugame from childhood, Logical Journey of the Zoombinis. Like the Doctor Brain games, this one was so good for me that I wanted to keep playing it as an adult. I still have the original CD and can run the game if I set up one of my older Windows computers. (If you'd like to play it on a modern PC, there is a remake, though they redid all the art for some silly reason). Unlike the Doctor Brain series, Logical Journey does not teach any encyclopedic knowledge or technical skills. It is 100% about how to think - reasoning, experimenting, and planning. All the puzzles sorta have a basis in mathematics or programming, but you wouldn't realize that unless you were told (or knew what to look for).

Get in the hole, we're escaping!

Let's start with the obvious: this game is CUTE. What little kid doesn't love small round innocent creatures with big eyes? The ridiculous supporting characters range from an anthropomorphic ringtail cat to sapient rocks and trees. There's a thin but motivating plot: the Zoombinis were a happy nation of craft workers [1] until the Bloats tricked them into a bad trade agreement and basically enslaved them. The player character is a "guide" who helps bands of Zoombini refugees travel to a distant land where they can be free. That means getting them through bizarre obstacles, which I guess they're not smart enough to manage on their own.

To get a group of Zoombinis through the entire trek, you have to solve nine puzzles out of the twelve available. A common theme across seven of the puzzles is a hidden rule you must deduce. Sometimes the rule is about categories, sometimes it's about mapping (functions), sometimes it's about spatial relationships ... regardless, it can only be found through trial and error, and you get a limited number of tries. So this game excels at teaching the player not only how to generalize from limited experience, but also how to choose experiments that judge between competing possibilities and maximize information gained. Other puzzle elements I can think of include resource allocation under constraints, prediction, and sequencing.

Bubblewonder Abyss, the last obstacle, became my favorite puzzle once I figured out how it worked. It's all about sequencing (you solve it by sending Zoombinis across in the correct order) and imitates computer program elements like toggles and if/else statements. Screenshot obtained from zoombinis.fandom.com. 

This is also the only edugame I can think of that had a serious difficulty curve - it enabled me to watch myself get smarter. When I played for the first time, the easiest level was manageable (mostly - I had no clue what was going on in the Fleens puzzle), but the upper levels were too hard. When I got older and came back to it, I found myself mysteriously able to figure out parts that once seemed impenetrable.

I can remember having big feelings about this game - mostly frustration. Failing a puzzle means you "lose" some Zoombinis. They never die (the designers weren't brutes), but they do go back to the closest available campsite. And then, unless you lose more Zoombinis, you can never get back to moving perfect groups of sixteen around. You'll always have a "remainder" stuck at one of the camps. I adore round numbers enough that this ticked me off. It's tough to choose the puzzle I had the fiercest love-hate relationship with. "Mirror Machine" probably drove me crazy the longest, but I have to give the award to "Titanic Tattooed Toads," because failing at this one really made me feel dumb. It's quite easy if you meticulously pay attention: just make sure your lily pad feature of choice forms an unbroken trail across the marsh. If you aren't meticulous and miss one incorrect lily pad, boom, the scenario becomes unwinnable. Being impatient and launching more than one toad at once can also wreck you. Thanks loads, toads!

The same-color paths were always easier for me to find than same-shape, so I wonder if this puzzle is extra torture for colorblind kids. Screenshot obtained from zoombinis.fandom.com.

My late-blooming achievement was not intelligence, but discipline. In early playthroughs, I lost interest after a few journeys at the highest difficulty level. It wasn't until I was older ... I forget when, probably my late teens ... that I "beat the game" by transferring a full complement of 625 Zoombinis from Zoombini Isle to Zoombiniville. That involves playing the nine puzzles at least forty times, even if you do it perfectly. Was it worth it? I don't know, but I feel strangely satisfied. I guess it means I cared. (If you leave the game running in Zoombiniville for very long, the narrator starts harassing you about all the Zoombinis still living under tyranny. Tell him I finally committed and went back for every last one.)

There might be a particular reason why I decided to talk about this game this month, but you'll just have to wait and see. :)

Happy cogitations,
Jenny

[1] How they managed this without hands or other manipulators, I don't know. Don't overthink it.

Acuitas Diary #81 (February 2025)

I've been on a real productive streak, so I did two major things this month. One enhances conversation abilities; the other is about gerunds. Don't worry, I'll explain those.

A famous phrase that uses gerunds. Image from https://commons.wikimedia.org/wiki/File:SiB_Logo.jpg

First, I went back to the conversation features that I introduced last September and worked on getting them solid - ironing out the remaining bugs and moments of weirdness. After spending about a week on that, I was pretty happy with the state of the Conversation Engine. Then I added another type of "topic tree." The one from last September guided responses to the conversation partner's states of being; this one reacts to actions that the conversation partner says they took or are taking. Possible threads include ...

*Try to infer whether the speaker liked doing that or not, and comment accordingly
*Ask for motivation ("Why did you ...") or announce what he suspects the motivation was
*Guess what the results were (if he can make any inferences)

This needs a lot more polishing, but it's starting to increase the complexity and variability of conversations. You can now go down "rabbit holes" which start with talking about a personal state, then lead into what you did to cause it, and so on. Which also means it's harder to keep everything straight, and I haven't really set Acuitas up to clearly indicate when he's jumping topics, yet. Always more to do.

My next project was to add support for gerunds to the Text Interpreter and Generator. What's a gerund, you might say? It's a present participle verb form (the kind that ends with -ing) used as a noun. Gerunds can be used to make statements about the concept of an action, such as the following:

I enjoy dreaming.
Exercising is good for the body.

Like other verbs, gerunds can have objects and adverbs, forming a gerund phrase - a group of words which, as a unit, acts like a noun in the full sentence.

[Reading books] makes me happy.
I see that you didn't care for [John's clumsy handling of that situation]. Did [my smoothing it over] satisfy you?

If a gerund has a "subject" that is performing the action, as in the final example, it's supposed to be in the possessive; it modifies the whole gerund phrase, instead of acting as a true subject.

I already added code to identify some gerund phrases to the Text Parser back in 2023, but the later stages of the text processing chain didn't know what to do with them if they came out of the parser, and Acuitas couldn't use them in his own speech. I wanted to get these capabilities in, because gerunds are so useful for expressing sentiments about actions. They're often used for expressing sentiments about states, too:

I dislike being wet.
Being warm is a pleasure.

I had to work around the absence of gerunds when I was putting in the latest conversation features, and it was giving me some pain. But thanks to this month's work, they're now more fully supported. I defined some new "fact" structures to function as the distilled version of statements about actions, added code to the Interpreter to map incoming sentences to those, and added code to the Generator to produce output sentences from those. So Acuitas has a bunch of new ways to say he likes or doesn't like something, in addition to a path for "comprehending" a wider range of written sentiments.

Until the next cycle,
Jenny

Atronach's Eye 2025 (Complete?)

As of last year I had worked all the major bugs out of my motion-tracking eyeball, but I still couldn't consider it finished. I wasn't ready to hang it on the wall and let it operate yet, due to one last issue: thermal concerns.

It's installed on the wall! It's operating continuously! It's done! The Lab Assistant gets to take a nap!

The eyeball's motion is driven by two unipolar stepper motors, each of which is powered from one of my dirt-simple stepper motor controllers. These are custom PCBs that I got manufactured many years ago. They were very inexpensive, and they only have two control wires (a nice thing for connecting motors to embedded processors with a limited number of general purpose IO). But that also means they don't have a power enable. Even if the control inputs are static and the motors aren't moving, some of their coils remain energized. That means they can exert their holding torque, which keeps the drive shaft in place and resists any external forces that try to turn it. But that wasn't something the eyeball needed (it naturally stays in position when unpowered). And during tests, I noticed that the motors got quite hot: enough to be uncomfortable to touch and make the plastic case smell.

I didn't like the thought of leaving the eye turned on with the motors baking themselves and everything else in the case in their own heat day in and day out. I doubt it would qualify as a fire hazard or anything serious like that, but in addition to wasting a small amount of electricity, it could reduce the lifetime of the parts. So I wanted to be able to cut all power to the motors when the eye wasn't active.

My solution was a standard relay. I bought some of these nice little breakout boards from DIYables that have the relay already mounted with connectors and a couple of indicator LEDs, and spliced one into the motor power input path of both motor controllers.

Then I added code to the eyeball software to turn the relay on and off. I wanted to strike a balance between letting the motors heat too long, and clicking the relay on and off constantly. So the software turns the motors off if no moving object to track has been seen in view for a certain amount of time. I also threw in darkness detection; the eye will stop trying to track motion if the average brightness of the scene is too low to see properly. (So it won't move around and make little noises in the middle of the night because the camera picked up some low-light noise.) Both features worked very well. The eye reliably deactivates when I leave the room (so long as there isn't something else moving around, like the flames in the fireplace) and when the lights are out or too dim.

In the dark, the indicator LEDs on the Raspberry Pi and the relay board diffuse through the white parts of the case and turn the eye into a low-key nightlight. I wasn't really expecting this, but hey: it still has a function when it's not looking at stuff.

In the end, I got to do what I always wanted: hang the eye on the wall and let it be an always-on fixture in the house. Further tweaks and upgrades to the software are possible, but I'm calling it finished because it's finally operating. It has been on the wall trying to look at me, the Lab Assistant, and other motion sources for at least a couple weeks of total up-time. Hearing it "wake up" as I pull open the curtains has become part of the morning routine.

There will almost certainly be another version, because there are plenty of things I could improve. I already applied a bunch of little enhancements to the 3D models of the case parts late last year. But this is the first Atronach's Eye iteration that could be said to realize my original vision (cough) for the project, if imperfectly. I'm also thinking about what else I can do with it. Atronach could theoretically tell Acuitas whether there's somebody in the room, for instance. Mmmm.

Until the next cycle,
Jenny