We’re on a sort of vacation in Tanzania at the moment and staying in a modest hotel away from the tourist and government district. It’s a district of small shops selling the same things and guys repairing washing machines out on the sidewalk. The guys repairing washing machines are more than happy to talk. Everybody’s amazingly friendly here, the hotel guy grilled us for an hour about our home state. But I really didn’t expect to end up in a conversation about computer vision.

In search of some yogurt and maybe something cooler to wear, we went on a little walk away from the hotel. With incredible luck we found a robotics shop a few blocks away. Mecktonix is a shop about two meters each way, stuffed full of Arduinos, robots, electronics components, servos, and random computer gear, overseen by [Yohanna “Joe” Harembo]. Nearby is another space with a laser engraver and 3D printer. The tiny space doesn’t stop them from being busy. A constant stream of automotive tech students from the nearby National Institute of Transport shuffle in for advice and parts for class assigned projects.

In between students, Joe demos an autonomous car he’s working on. In classic hacker fashion, he first has to reattach the motor driver board and various sensors, but then he demos the car and its problem –  the video frame rate is very slow. We dive in with him and try to get some profiling using time.monotonic_ns(). He’s never done profiling before, so this is a big eye opener. He’s only processing one video frame every 4.3 seconds, using YOLO on a Pi 3, and yup, that’s the problem.  I suggest he change to gamut detection or a Pi 4.

Gamut Detection

If you’re not familiar with gamut detection, it’s one of the simplest of all computer vision techniques, so it’s easy to implement on slow processors and almost trivial to code. Basically, it’s “look for a color”.  If you want your robot to follow you, wear a lime green T shirt. Now the robot just has to look for lime green. Same for catching a ball or following a line. The algorithm is simple – convert each pixel to HSV, where hue corresponds to the direction around the color wheel,  saturation corresponds to how concentrated the color is, and value how bright. Brightness depends on the lighting, so you can throw value away and just set limits for H and S. Anything within those limits is part of our target. The box formed by those limits is our “gamut”.

There are a couple speedups you can apply as well. First, ask yourself how much resolution you need from the camera. If you only want to track a green T shirt that’s never less than 24 pixels on screen, turn the resolution down by a factor of six each way and look for four-pixel T shirts. You now have 1/36th as much data to process and your algorithm runs 36 times faster. If you can’t control the camera resolution, you can shrink the image or just sample every nth pixel. Second, you can often ask for a YUV or YIQ image from the camera. Discard Y and set your limits in IQ or UV coordinates. It’s about the same as HSV.

Joe’s eating this up – he’s had limited chances to talk with somebody else who is into computer vision. As we write this, he’s still trying with YOLO, but at lower resolution. If it doesn’t work he’ll try gamut detection. And it’s not his only project. Passenger carrying motorcycles called pikipikis are common here. A student has a project to enforce passengers wearing a helmet, and we fiddle with the student’s project.

The Dar es Salaam Scene

There’s other tech happening in Tanzania too. A few blocks away is [Ruta Electronics], a similar sugar cube sized shop developing smart meters. Everything from cases to PCB etching happens in the tiny shop. Downtown there are a few tech startups. There’s a fab lab, mostly oriented towards children. And on a quiet side street off the main drag, there’s a tiny shop with three guys who are hacking like crazy.

For us, we’ve had a chance to make a friend from a different culture and play with a robot car together — what could be better?  When you’re traveling, are you on the lookout for other hackers or hackerspaces? It’s worth the effort and brings our community together in a way that even the internet can’t.

The most collectible items in the realm of vintage computers often weren’t the most popular of their era. Quite the opposite, in fact. Generally the more desireable systems were market failures when they first launched, and are now sought out because of a newly-appreciated quirk or simply because the fact that they weren’t widely accepted means there’s fewer of them. One of the retro computers falling into this category is the Apple III, which had fundamental hardware issues upon launch leading to a large recall and its overall commercial failure. [Ted] is trying to bring one of these devices back to life, though, by slowing its clock speed down to a crawl.

The CPU in these machines was a Synertek 6502 running at 1.8 MHz. With a machine that wouldn’t boot, though, [Ted] replaced it with his own MCL65+, a purpose-built accelerator card based on the 600 MHz Teensy 4.1 microcontroller in order to debug the motherboard. The first problem was found in a ROM chip which prevented the computer loading anything from memory, but his solution wouldn’t work at the system’s higher clock speeds. To solve that problem [Ted] disabled the higher clock speed in hardware, restricting the system to 1 MHz and allowing it to finally boot.

So far there haven’t been any issues running the computer at the slower speed, and it also helps keep the computer cooler and hopefully running longer as well, since the system won’t get as hot or unstable. This isn’t [Ted]’s first retrocomputing rodeo, either. His MCL chips have been featured in plenty of other computers like this Apple II which can run at a much faster rate than the original hardware thanks to the help of the modern microcontroller.

There are certain design aesthetics from every era that manage to survive the fads of their time and live throughout history. Ancient Greek architecture is still drawn upon for design inspiration in modern buildings, the mid-century modern style from the 60s still inspires various designs of consumer goods, and the rounded, clean looking cars from the 90s are still highly desirable qualities in automotive design. For electronics, though, we like this 70s-inspired calculator that [Aaron] recently built.

The calculator hearkens back to the days of calculators like the HP-29C with its large buttons and dot-matrix display. [Aaron] built the case out of various woods with a screen angled towards the user, and it uses a LCD display similar to those found in antique calculators. The brain of the calculator is an Arduino which fits easily into the case, and [Aaron] also built the keyboard from scratch with Cherry MX-style mechanical keys soldered together into a custom shape.

The software to run the calculator is fairly straightforward, but we are most impressed with the woodworking, styling, and keyboard design in this build. [Aaron] is also still ironing out some bugs with the power supply as it uses a DC-DC converter to power the device from a single lithium battery. For those who are more fond of early 2000s graphing calculators instead, be sure to take a look at this graphing calculator arcade cabinet.

The Arudino is a powerful platform for interfacing with the real world, but it isn’t without limits. One of those hard limits, even for the Arduino MEGA, is a finite number of pins that the microcontroller can use to interface with the real world. If you’re looking to extend the platform’s reach in one of your own projects, though, there are a couple of options available. This project from [Bill] shows us one of those options by using the ATtiny85 to offload some of an Arduino’s tasks using I2C.

I2C has been around since the early 80s as a way for microcontrollers to communicate with each other using a minimum of hardware. All that is needed is to connect the I2C pins of the microcontrollers and provide each with power. This project uses an Arduino as the controller and an arbitrary number of smaller ATtiny85 microcontrollers as targets. Communicating with the smaller device allows the Arduino to focus on more processor-intensive tasks while giving the simpler tasks to the ATtiny. It also greatly simplifies wiring for projects that may be distributed across a distance. [Bill] also standardizes the build with a custom dev board for the ATtiny that can also double as a shield for the Arduino, allowing him to easily expand and modify his projects without too much extra soldering.

Using I2C might not be the most novel of innovations, but making it easy to use is certainly a valuable tool to add to the toolbox when limited on GPIO or by other physical constraints. To that end, [Bill] also includes code for an example project that simplifies the setup of one of these devices on the software end as well. If you’re looking for some examples for what to do with I2C, take a look at this thermometer that communicates with I2C or this project which uses multiple sensors daisy-chained together.

C and C++ are powerful tools, but not everyone has the patience (or enough semicolons) to use them all the time. For a lot of us, the preference is for something a little higher level than C. While Python is arguably more straightforward, sometimes the best choice is to work within a full-fledged operating system, even if it’s on a microcontroller. For that [Chloe Lunn] decided to port Unix to several popular microcontrollers.

This is an implementation of the PDP-11 minicomputer running a Unix-based operating system as  an emulator. The PDP-11 was a popular minicomputer platform from the ’70s until the early 90s, which influenced a lot of computer and operating system designs in its time. [Chloe]’s emulator runs on the SAMD51, SAMD21, Teensy 4.1, and any Arduino Mega and is also easily portable to any other microcontrollers. Right now it is able to boot and run Unix but is currently missing support for some interfaces and other hardware.

[Chloe] reports that performance on some of the less-capable microcontrollers is not great, but that it does run perfectly on the Teensy and the SAMD51. This isn’t the first time that someone has felt the need to port Unix to something small; we featured a build before which uses the same PDP-11 implementation on a 32-bit STM32 microcontroller.

When [John Floren] obtained a vintage Depraz mouse, he started out being content to just have such a great piece of history in his possession. But if you’re like him, you know it’s not enough to just have something. What would it be like to use it?

To find out, [John] embarked on a mission to build a USB adapter for his not so new peripheral.
Originally used in very early terminals with a Unix GUI, the Depraz mouse utilizes an unusual male DE9 connector rather than the more familiar female DB9 used in RS232 serial mice. Further deviating from the norm, he found that the quadrature encoders were connected directly to the DE9 connector.

Armed with an Arduino Pro Mini and some buggy sample code, he got to work. The aforementioned buggy code was scrapped and a fresh sketch for the Arduino Pro Mini gave the Depraz mouse the USB interface it lacked. [John] also found that he wasn’t the first hardware hacker to have modified the mouse for their use. Be sure to read to the end the article to find out about the vintage surprise lurking in the mouse shell itself! A demonstration of the mouse in action can be seen in the video below the break.

Looking for a fun mouse hack? Perhaps you’d like to use your more modern USB mouse on a retro computer, or try your hand at recreating an early Apple mouse for use in modern computers.

Join us on Wednesday, April 21 at noon Pacific for the AVR Reverse Engineering Hack Chat with Uri Shaked!

We’ve all become familiar with the Arduino ecosystem by now, to the point where it’s almost trivially easy to whip up a quick project that implements almost every aspect of its functionality strictly in code. It’s incredibly useful, but we tend to lose sight of the fact that our Arduino sketches represent a virtual world where the IDE and a vast selection of libraries abstract away a lot of the complexity of what’s going on inside the AVR microcontroller.

While it’s certainly handy to have an environment that lets you stand up a system in a matter of minutes, it’s hardly the end of the story. There’s a lot to be gained by tapping into the power of assembly programming on the AVR, and learning how to read the datasheet and really run the thing. That was the focus of Uri Shaked’s recent well-received HackadayU course on AVR internals, and it’ll form the basis of this Hack Chat. Then again, since Uri is also leading a Raspberry Pi Pico and RP2040 course on HackadayU in a couple of weeks, we may end up talking about that too. Or we may end up chatting about something else entirely! It’s really hard to where this Hack Chat will go, given Uri’s breadth of interests and expertise, but we’re pretty sure of one thing: it won’t be boring. Make sure you log in and join the chat — where it goes is largely up to you.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 21 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

High-level programming languages do a great job of making a programmer’s job easier, but these languages often leave a lot of efficiency on the table as a compromise. While a common thought is to move into a lower-level language like assembly to improve on a program’s speed or memory use, there’s often a lot that can be done at the high level before resorting to such extremes. This, of course, is true of the Arduino platform as well, as [NerdRalph] demonstrates by shrinking the size of the Arduino core itself.

[NerdRalph] had noticed that the “blink” example program actually includes over 1 kB of extraneous code, and that more complicated programs include even more cruft. To combat this issue, he created ArduinoShrink, which seeks to make included libraries more modular and self-contained. It modifies the some of the default registers and counters to use less memory and improve speed, and is also designed to improve interrupt latency as well by changing when the Arduino would otherwise disable interrupts.

While there are some limits to ArduinoShrink, such as needing to know specifics about the pins at compile time, for anyone writing programs for Arduinos that are memory-intensive or need improvements in timing this could be a powerful new tool. If you’d prefer to go in the opposite direction to avoid ever having to learn C or assembly, though, you can always stick with running Python on your embedded devices.

While early scientists and inventors famously underestimated the value of radar, through the lens of history we can see how useful it became. Even though radar uses electromagnetic waves to detect objects, the same principle has been used with other propagating waves, most often sound waves. While a well-known use of this is sonar, ultrasonic sensors can also be put to use to make a radar-like system.

This ultrasonic radar project is from [mircemk] who uses a small ultrasonic distance sensor attached to a rotating platform. A motor rotates it around a 180-degree field-of-view and an Arduino takes and records measurements during its trip. It interfaces with an application running on a computer which shows the data in real-time and maps out the location of all of the objects around the sensor. With some upgrades to the code, [mircemk] is also able to extrapolate objects hidden behind other objects as well.

While the ultrasonic sensor used in this project has a range of about a meter, there’s no reason that this principle couldn’t be used for other range-finding devices to extend its working distance. The project is similar to others we’ve seen occasionally before, but the upgrade to the software to allow it to “see” around solid objects is an equally solid upgrade.

The trick to a fun escape room is layers. For [doktorinjh]’s Spacecase, you start with an enigmatic aluminum briefcase and a NASA drawstring backpack. A gamemaster reads the intro speech to set the mood, and you’re ready to start your escape from the planet. The first layer is the backpack with puzzles you need to solve to get into the briefcase. In there, you discover a hidden compartment and enough sci-fi references to put goofy smiles on our faces. We love to see tools reused as they are in one early puzzle, you use a UV LED to reveal a hidden message, but that light also illuminates puzzle clues later.

All the tech in Spacecase makes it a wonder of mixed media. The physical layer has laser engraved wood featuring the font from the 1975 NASA logo, buttons, knobs, LEDs, toggle switches, and a servo. Beneath the visible faceplate is an RGB sensor, audio player, speaker, and at the center is an Arduino MEGA. We’d love to get our hands on Spacecase for a game, and we’re inspired to pull out all the stops and build games with our personal touches. Maybe something with a mousetrap.

This isn’t the first escape room hardware we’ve seen and [doktorinjh] similarly made a bomb diffusing game.