Mysterious Files PH

Cutting foam with a hot wire is a common technique to shape foam in a wide variety of shapes. If you want to cut something detailed and precise, like an airfoil, you probably want to use a computer-controlled cutting tool. Here [Michael Rechtin] has been working on creating a very versatile DIY CNC hot wire cutter, with the results recently announced in a video, along with the GitHub project repository if you want to give it a shake yourself.

Key in hot wire foam cutting is getting the nickel-chromium wire hot enough to gently slice through the foam rather than annihilating it or having the wire encounter significant resistance. For an automated cutter it either needs to be able to adjust the current on the fly, or have a predetermined optimal current for the cutting speed.

The machine itself is a 4-axis system, allowing the wire to be moved just about any way in between the two sides. It uses typical NEMA 17 stepper motors, along with other components that you’d find on a 3D printer. The same is true for the control board that processes the g-code from the software.

The unique part is the pulley-based mechanism that tensions the cutting wire, along with the way that the current gets passed through the wire, which uses MIG welding tips rather than just some alligator clips, which would probably also have worked but not looked as nice.

There are a few 3D-printed parts for which the STLs are provided, and the design is such that the entire assembly can be fairly easily collapsed into a compact shape that’s much easier to store if you’re not cutting foam every single day. For [Michael] cutting airfoils is the main use, for which you got a few software packages that are mentioned in the video.

As unique the Nintendo Wii U Gamepad may appear to be, at its core it’s pretty much just a tablet with game controls stuck on it. Now that the communication between the Wii U and the Gamepad have been fully reverse-engineered and poured into easy to use software, this opens the possibility of using other tablets with suitable controls on them for Wii U Gamepad purposes, like the Windows-capable Samsung tablet that [Bringus Studios] decided to experiment on.

Originally designed to run Windows XP Tablet PC Edition, the Samsung Q1 series of ultra-mobile PCs (UMPC) was first released in 2007, featuring a 900 MHz Celeron M CPU. Amusingly [Bingus] mixes up mAh and mWh when comparing battery capacities, as the Li-ion battery pack for this UMPC is an 11.1V one, whereas a smartphone battery is 3.7V nominal.

To turn this UMPC into a Wii U Gamepad, first 32-bit Debian 12 is installed along with the Vanilla Wii U Gamepad project. The main challenge then is to find a Wi-Fi adapter that works for this purpose, as the connection uses a slightly non-standard handshake. Naturally the TP-Link USB WiFi adapter that [Bingus] used changed from its previous and better supported Mediatek chipset to a Realtek one with typical poor Linux support, requiring manual driver compiling.

After more troubleshooting, it’s unfortunately found that the 900 MHz Celeron M in this UMPC just isn’t up to the task, with the decoding of the compressed HDMI stream correspondingly pegging the CPU at 100% with all the frame dropping. It’s likely that this is due to a lack of h.264 hardware decoding support, as this would push this burden onto the CPU. The system uses the Intel 915GMS chipset with the GMA 900 iGPU, which appears to just provide hardware acceleration for MPEG 2.

Online publications sometimes work with sponsors. Over at the Autopian, they landed a sponsorship deal with eBay, but due to an unguarded comment, fulfilling the sponsor’s requirements turned out to be something of a handful. Build a brand-new, completely WW2-spec Jeep using only parts sourced from the auction site, and drive it to Moab for an event. [David Tracy] set to work, and the resulting write-up is a build of epic proportions.

Of course, many Jeeps have been built since the war, not least by Willys and its successors, but also by enthusiasts. You can even buy a modern-day visible derivative of the original made in America by the Indian company Mahindra, which has been licensed to build Jeeps since the 1940s. So his claim of making the first new WW2-spec Jeep since the war may be difficult to substantiate, but it’s certain that his attention to period detail is exceptional. For example, most people would either use a more modern engine or find a second-hand original. Instead, he sources a brand new block from France and builds a new engine from scratch. And is that the infamously flawed early Jeep steering system we spy? The vehicle uses second-hand parts for other major drive train components, but the chassis and body are made in the Philippines.

An early Jeep is a simple vehicle, but following his build, you realise the power of the manufacturing industry, as so many individual parts and assemblies must come together to make the finished machine. Some of us have had old cars in our lives, so we appreciate this very well. The moment of completion comes with very little testing time to spare, and he’s off on the long drive from LA to Moab. That in itself could make an epic write-up, and yet again, we recognise the combination of willpower and worry. All of this has made us idly want one of these wildly impractical but seductive vehicles, but we know it will pass. If you aren’t interested in authenticity, you can always meld a Jeep with a Prius.

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their leage in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [FabianKuebler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at  3.58 MHz, and after that you can watch some sprites be bounced at a blistering 0.8 fps on the simulated PPU. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port– if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense– the kind of micros you run MicroPython on can emulate the SNES.

Thanks to [Fabian] for the tip!

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.

If you’re not aware, there is such a thing as adorable little three digit LCD 7-segment displays. They come in a ten-pin DIP package and are just begging to be integrated into a project. The catch is they are just a tiny bit weird. Luckily for us all, [Nagy Krisztián] spells out exactly how to use them.

The first odd thing about these ten-pin LCD displays have a footprint that doesn’t quite mesh with standard 0.1 inch spacing, meaning they will not cleanly fit into a breadboard. Luckily, one can solve this with a bit of force. It’s a small part, and the pins don’t seem to mind.

The second odd thing is wrapping one’s head around the pin mapping. Figuring out which pins activate which segments in the digits is easier if one keeps in mind that each segment of each digit is the product of two different pins. For example, “2A” is digit two, segment A, and is the product of pins 3 and COM4.

That’s not all. Electrically speaking, driving this LCD isn’t nearly as straightforward as an LED.

With an LED display, the COM pins are either common anode or common cathode, which tells one whether lighting up a segment means holding the COM pin at GND with voltage applied to the segment pin, or the other way around. But in the case of this LCD display, the polarity applied is swapped every cycle. Oh, and inactive COM pins need to held at half-voltage. Neat!

[Nagy] drives the whole thing with little more than an ATtiny84 microcontroller and a few resistors. A switchable half-voltage signal is cleverly created by combining a simple voltage divider and taking advantage of the fact that the ATtiny84’s pins can be in one of three different states depending on how they are configured: high, low, or high-impedance (pin configured as an input). Each COM pin on the display gets connected to both an ATtiny84 pin, and to the supply voltage via two resistors forming a voltage divider. When the ATtiny drives the pin high, the LCD pin sees about 3 V. When the pin is driven LOW, the LCD pin sees 0 V. When the ATtiny configures the pin as an input, the LCD pin receives about 1.5 V.

The bulk of the software is defining which pins and states equal which digits, and cycling the LCD at a rate of vaguely 60 Hz which delivers flicker-free results.

We appreciate the clever combination of voltage divider with pin configuration to create three switchable voltage levels. If you liked that and want to see more serious leveraging of pin configuration on a microcontroller, check out how to drive seven LEDs with only two pins.

You’ve doubtlessly seen the current crop of robot dogs and, if you are like us, thought about getting one to play with. The problem is that the cheap ones are toys, and the serious ones cost serious money. But now you can experiment with a mid-range cost one for free in your browser. The sponsor will be happy to sell you a robot in kit or assembled form, although it is the OpenCat robot (we’ve covered it before), so you could simply build a real one yourself if you wanted to.

The code is all in a Web-based IDE, and the main file is deceptively simple. However, the real work is in read_serial (in the src/moduleManager.h file, for some reason) and reaction in the aptly-named src/reaction.h file. If you just want to play, you can use the buttons in the simulator or enter serial commands (documented elsewhere). For example, ksit will make the dog sit down.

You can change as much code as you like. You might consider starting simple and just sending commands programmatically, but you can dive as deep as you like. Press compile up at the top right, and it will load and run your code in the virtual robot. If you run it off the desk (of course, we did), you can reset and try again.

Here’s a quick example to get you started:

//***********************
#define BITTLE // Petoi 9 DOF robot dog: 1 on head + 8 on leg

#define BiBoard_V1_0
//***********************

#include "src/OpenCat.h"

void setup() {
Serial.begin(115200); // USB serial
Serial.setTimeout(SERIAL_TIMEOUT);

while (Serial.available() && Serial.read())
; // empty buffer

Serial.println("Hello Hackaday!");
initRobot();
}

unsigned int loopct=0;
unsigned int phase=0;

#define cmdtokenEOF 0xFFFF

// commands (token + argument)
char *cmd[] =
{
"sit", // good boy
"up", // stand up
"bf", // back flip
"ff", // forward flip
"EOF" // string doesn't matter here
};

unsigned int cmdtoken[] = {
T_SKILL,
T_SKILL,
T_SKILL,
T_SKILL,
cmdtokenEOF
};

#define LOOPDELAY 1000 // number of loops between actions

void loop() {
// This code runs repeatedly
// Put any change here if you want to change behaviors
if (loopct % 1000 == 0 )
{
loopct=0;
if (cmdtoken[phase]==cmdtokenEOF) phase=0;
strcpy(newCmd,cmd[phase]);
token=cmdtoken[phase++];
newCmdIdx=1;
}
loopct++;

reaction();
}

The robot is better than the cheap toys, but it still lacks many sensors. You can add on a few simple sensors that appear to mount in the dog’s mouth, or you can replace its head with an arm if you opt for beefy enough servos.

Of course, we’ve seen plenty of robot dogs. We want one, but we don’t know what we’d do with it. Any ideas?