To Build More Believable Bots, Simulate The Neurochemistry

Giving machines the ability to communicate nonverbally has real value, and [Drew Smith] clearly thinks your robot deserves better than an emoji. He shared a very interesting approach with his project Kindalive.

Kindalive is a simulated dot-matrix robot face that responds believably to input text, modeling and expressing both short-term and long-term moods. It’s pure Python and modular enough to invite using it elsewhere, but that’s not the really interesting part.

What sets [Drew]’s project apart is the way he models eight key neurochemicals (including dopamine and cortisol) as the foundation from which to derive emotional states. That’s an approach we certainly haven’t seen before.

Conventional sentiment analysis uses a large language model (LLM) to apply discrete labels to communication, but Kindalive doesn’t do that. It even goes so far as to model the decay and interplay between its simulated neurochemicals to derive emotional states on the fly. It’s more fluid and organic, and reflects both short-term and long-term mood changes.

Physical representation of the emotional mix is done by altering twelve key facial movements (brow raise, lip corner pull, mouth open, and others of that nature) known as the Facial Action Coding System (FACS). These twelve elements combine to express emotion nonverbally with facial expressions. It’s what drives the simulated dot-matrix robot face seen in the image above, and could easily be used to drive a real LED matrix, or servos on an animatronic face.

Much of communication is nonverbal. Humans even weigh nonverbal higher when there’s a mismatch between the content of verbal and nonverbal communication. So, there’s clear value in having robots able to express themselves as such.

Importantly, a realistic and human-like face is entirely unnecessary — something every Star Wars fan already knows. Cartoon eyes and basic sounds are enough to make robots easier to relate to and work with, even if blinking is also important but hard to get just right.

When Changing Scale Isn’t Just More Of The Same

[Jenny] and I were talking about [Bitluni]’s experiment in scale, where he will take 65,536 cheap microcontrollers, network them all together, and give each one an RGB pixel. From there, antics will surely ensue. Right now, he’s only got 8,192 of them up and running, and already the novel problems and opportunities are rearing their heads.

We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.

Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.

On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.

So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.

A clay vase sits in the center of a circular table, with an extruder in contact with the top surface. The extruder has a tube containing clay on the right side, with a motor mounted above an auger over the main nozzle.

Clay Extruder Enables Printable Pottery

Ceramic 3D printers, despite using the same fundamental mechanism as standard FDM printers, are much harder to find. Part of this comes down to the material properties of fired ceramics versus thermoplastics, but they’re also significantly harder to build; for example, in his ceramic printer build, [Joshua Bird] had to deal with severe material shrinkage, collapsing bridges, and the surprisingly abrasive effects of clay.

The centerpiece of the printer is the clay extruder: an air compressor pushes clay along a tube into the extruder, which uses an auger to squeeze the clay through the nozzle, while a gap at the top lets trapped air escape. The extruder has enough control for successful retractions, but rheology remained a challenge: the clay needed to be soft enough to flow through the nozzle, but stiff enough to form bridges without collapsing. [Joshua] thus pressurized the clay as much as possible, making it possible to use stiffer clay mixtures. The extruder’s greatest challenge was longevity: [Joshua] tried many 3D-printed plastic augers, but the clay abraded them all much too quickly, often in under an hour of use; a 3D-printed stainless steel extruder solved this.

Printing in ceramic isn’t a simple process: for each part, [Joshua] had to mix the clay, load it into the tube, clean the extruder, actually print the object, let it dry, fire it, apply glaze, and fire it again. The clay’s shrinkage during drying and firing destroyed many prints, but [Joshua] was nevertheless able to print a double-walled cup, a decorative climbing-themed cup, and even a chain-mail mesh.

The 3D printer’s motion system is a polar design, an adaptation of his earlier non-planar 3D printer, which might eventually make it easier to print overhangs. We’ve previously seen a similar auger-based clay extruder, an approach reminiscent of direct-granule FDM printing.

A Look Inside A 1997 BBC Ceefax Generator

Ceefax was the BBC’s broadcast teletext service that ran until 2012, providing text and rudimentary graphics that were broadcast invisibly with the TV signal. In order to get this teletext data merged into the analog TV signal, special equipment was needed, of which [Nathan Dane] has a 1997-era unit on his bench to take a gander at.

Interestingly, until this time the Ceefax signal had been generated centrally in London, meaning that regional TV broadcasts might have Ceefax issues on occasion due to retransmission glitches. This makes this Ceefax Inserter  system so much more interesting, as it was one of the early examples of what these regional stations would end up installing in their racks.

At their core these units are regular PCs, running MS-DOS 6.22 on a 486-class CPU and all the typical bits and bobs that go with a PC. The speculation here is that these are essentially rebranded industrial PCs, which would make a lot of sense. As for how [Nathan] got his hands on these units, it required a deal with the company scrapping them, preventing him from showing details of the software configuration.

Following a booting demonstration, we get the teardown of a typical 1990s rackmount PC, revealing a rather interesting backplane with the mainboard being one of the cards on it. Of these, two ISA cards provide the special Ceefax sauce as well as a timing signal in the form of a PDC card featuring a Lattice CPLD or FPGA that VCRs could use to automatically start recording.

The Ceefax main event comes in the form of the inSERT Teletext Encoder card. This is pretty much its own computer system, featuring a TI TMS34010 CPU and its own RAM as well as IO. Compared to modern takes on teletext generators, this card appears to directly mix the analog signals, without any kind of conversion.

Although teletext systems have been largely shutdown now at this point due to the transition to digital TV broadcasting, there’s still a lot to be said for having such a service available for basic news and information.

Continue reading “A Look Inside A 1997 BBC Ceefax Generator”

Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture

After previously fixing an overly bright picture from a Voodoo graphics card with a simple resistor on one of the RAMDAC’s pins to correct its faulty internal Vref, [Bits und Bolts] got called out for not taking component drift into account. Thus in an update video he shows how instead to use an adjustable AMS1117 voltage regulator to hopefully prevent either the original issue or something new and exciting from cropping up later.

The basic idea here is to use the external voltage reference (Vref) pin for this ICS5342 RAMDAC and supply it with a constant 1.235V. If unused – as on this Orchid-branded Voodoo card – it is connected via an 0.1 microFarad capacitor to ground. This fortunately means that the pin is routed to easily accessible pads that make this modification relatively straightforward.

Basically this is where the AMS1117-ADJ chip comes into the picture, as a widely available adjustable LDO option, even if the 0.8A current rating is very much overkill for this application. With the supplied voltage the lowest voltage this LDO can output is around 1.25V, which is within the 1.10 – 1.35 V range of the datasheet.

Of course, with the PCB never having had a provision for this part, much of the rest of the video is about planning out where to place and route the components. After that tedious work and testing that nothing explodes, the new voltage is used for the RAMDAC’s Vref pin, fixing the brightness issue.

While one could argue that this RAMDAC is likely simply defective and already beginning to break down inside, this should at least give it a bit longer on what seems to be a little used card anyway.

Continue reading “Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture”

Reject Modernity, Return To 80s, Learn C.

We’re not exactly sure how old [SnailMail] is, but he’s probably a member of Generation Alpha considering that to our wizened eyes the lad looks only slightly older than a fetus– which makes it all the more impressive that he’s written his own text editor, from scratch, in C– on a 386. See, [SnailMail] tried to learn the modern way, with IDEs that have code completion and AI integration, but his thoughts couldn’t gel in the modern environment. So he went online and bought an old IBM-compatible complete with monochrome amber monitor, and a whole 4MB of RAM. Big spender that he is, [SnailMail] upgraded that to 8MB.

Rather than fall victim to the siren song of Wolfenstien 3D or SimCity, he set out to learn to code: C, specifically, since that language bridges four decades between [SnailMail] and his new PC. Even more specifically, he got ahold of disks for Borland Turbo C and Turbo C++, which brings back memories for some of us. Of course the lad also had to learn how to use a DOS PC at the same time, but a teen in the 80s with a fresh box would have climbed the same steep learning curve. Some of you probably remember doing so yourselves. Just like you–or the hypothetical teen in the 80s–[SnailMail] did it not by googling or begging Claude for answers, but by digging into books. Many books.

After all the reading, he started with a text editor, something we remember being a pretty big project not given to first year students. Video evidence suggests he pulled it off. He describes how his solution works from about 8:00 in the video, so you greybeards in the audience can judge his work for yourself.

If you’re a member of Gen Alpha reading this and looking to learn to program, we cannot recommend this technique highly enough– [SnailMail] is going to have a better understanding of the underlying logic of computer science than a lot of CS grads being frocked today. Especially when you consider he ends by promising to learn assembly, something we heartily endorse.

Continue reading “Reject Modernity, Return To 80s, Learn C.”

Documenting The IR Protocol Of The PumpSaver Plus Device

Having a pump in a remote location where you aren’t constantly monitoring it is a common scenario, which can be unfortunate when said pump runs into problems like a dry well, jammed impeller or power issues. This is where pump monitors like the older SymCom (now Littelfuse) PumpSaver Plus 233P will protect the pump if such conditions are detected. Of course, the infrared communication port on it uses an undocumented protocol that was meant to be used with a long-since discontinued handheld device. Ergo [Elizabeth Camporeale] saw fit to reverse-engineer this protocol.

In the installation manual for this device this Informer unit is briefly mentioned along with the information it will display on its screen, making it clear that it’s quite literally just there to act as a display for the information that’s constantly generated on this interface. Naturally, this is incredibly useful if you wish to tie the system into a wider monitoring and automation system.

Somewhat unusual, this IR interface on the used 233P-1.5 unit turned out to be use a 5,000 baud NRZ, MSB-first protocol, with the juicy details fully documented and a Python-based decoder implementation provided.

Naturally [Elizabeth] didn’t just reverse-engineer this for the fun of it, but also for ESPHome integration. This uses a setup as can be seen in the top image, with an ESP32-C6 module providing the processing power and Wi-Fi, with a standard phototransistor recording the data pumped out by the pump monitor.