Open Source Controller For Old And Expensive Industrial Robots

The Zynq-7000 usage at the core of the robot controller. (Credit: Excessive Overkill, YouTube)
The Zynq-7000 usage at the core of the robot controller. (Credit: Excessive Overkill, YouTube)

Industrial robots like robotic arms are basically everywhere, albeit usually out of the public’s eye in factories. This also means that they get replaced and scrapped all the time, making for many opportunities to snap up an industrial robot that once cost as much as a pretty fancy car for essentially peanuts. Over the years the bloke behind the [Excessive Overkill] YouTube channel did this a lot, which also revealed the main issue with these ‘cheap’ robots: the electronics and associated software, with the manufacturer rarely going out of their way to appease to hobbyists trying to fix up one of these units, never mind for free.

That said, if you’re persistent enough, you can reverse-engineer these beasts to the point where you can develop your own controller hardware and software solution. This is exactly what was done, resulting in an open source controller, found on the ExcessiveMotion GitHub page, that should allow you to control many of these industrial robots. At the core is a Zynq-7000 hybrid FPGA-ARM SoC chip, running real-time Linux (with preemptive scheduling patch) on the SoC side and custom HDL on the FPGA side to handle the hard real-time tasks.

The controller during testing. (Credit: Excessive Overkill, YouTube)
The controller during testing. (Credit: Excessive Overkill, YouTube)

The controller is made to be modular, with a backplane that can accept various interface cards in addition to the current RS-485 and RS-422 interfaces that are commonly used in industrial settings, such as here for controlling the individual servo drives of the robots. To make assembly and testing interesting, the first controller and integration with a robot was made ready for display at the Open Sauce 2025 event, requiring things to be rushed along, including reverse-engineering the servo protocol for a small-ish industrial robot suitable for public display and use, as well as developing the kinematics for the robotic arm.

With the controller now demonstrated, clearly this is the perfect time to rush out and get one of these fun industrial robots for a few hundred bucks. Currently the controller is still being finalized, with the author asking for feedback on what it should be able to support. If you have a particularly unusual industrial robot lounging around without the requisite controller, this might be your chance to revive it.

Thanks to [Hans] for the tip.

Continue reading “Open Source Controller For Old And Expensive Industrial Robots”

Segger’s Awkward USB-C Issue With The J-Link Compact Debugger

Theoretically USB-C is a pretty nifty connector, but the reality is that it mostly provides many exciting new ways to make your device not work as expected. With the gory details covered by [Alvaro], the latest to join the party is Segger, with its J-Link BASE Compact MCU debugger displaying the same behavior which we saw back when the Raspberry Pi 4 was released in 2019. Back then so-called e-marked USB-C cables failed to power the SBC, much like how this particular J-Link unit refuses to power up when connected using one of those special USB-C cables.

We covered the issue in great detail back then, discussing how the CC1 and CC1 connections need to be wired up correctly with appropriate resistors in order for the USB-C supply – like a host PC – to provide power to the device. As [Alvaro] discovered through some investigation, this unit made basically the same mistake as the RPi 4B SBC before the corrected design. This involves wiring CC1 and CC2 together and as a result seeing the same <1 kOhm resistance on the active CC line, meaning that to the host device you just hooked up a USB-C audio dongle, which obviously shouldn’t be supplied with power.

Although it’s not easy to tell when this particular J-Link device was produced, the PCB notes its revision as v12.1, so presumably it’s not the first rodeo for this general design, and the product page already shows a different label than for the device that [Alvaro] has. It’s possible that it originally was sloppily converted from a previous micro-USB-powered design where CC lines do not exist and things Just Work™, but it’s still a pretty major oversight from what should be a reputable brand selling a device that costs €400 + VAT, rather than a reputable brand selling a <$100 SBC.

For any in the audience who have one of these USB-C-powered debuggers, does yours work with e-marked cables, and what is the revision and/or purchase date?

Surprisingly Refined Perpetual Motion Device Teardown

Perpetual motion devices are either a gag, a scam, or as in the case of this particular toy that [Big Clive] bought on AliExpress, a rather fascinating demonstration of a contact-free inductive sensor combined with a pulsed magnet boost for the metal ball. A cool part about the device is that it comes with a completely clear enclosure, so you can admire its internals while it’s operating. Less cool was that after unboxing the device wasn’t working as the detector wasn’t getting the 12 V it needs to operate, requiring a bit of repairing first.

The crucial part of the perpetual motion device schematic with the sensor, MCU and coil. (Credit: bigclivedotcom, YouTube)
The crucial part of the perpetual motion device schematic with the sensor, MCU and coil. (Credit: bigclivedotcom, YouTube)

Based on the label on the bottom of the device with the creative model identifier P-toy-002, its standby current is 10 µA which ramps up to 3 A when it’s operating. This makes sense when you look at the two core components: the industrial inductive detector, and a rather big electromagnet that’s driven by a bank of three 10 mF, 35V capacitors, turning it into something akin to a coilgun. Annoyingly, an attempt was made to erase most of the IC package markings.

The circuitry isn’t too complex, fortunately, with an adjustable electromagnet coil voltage circuit combined with a MOSFET to provide the pulse, and a 78L12 regulator to generate the 12 VDC from the coil’s voltage rail for the sensor that is monitored by a MCU.

Continue reading “Surprisingly Refined Perpetual Motion Device Teardown”

When Low SRAM Keeps The DOOM Off Your Vape

The PIXO Aspire is a roughly $35 USD vape that can almost play DOOM, with [Aaron Christophel] finding that the only thing that realistically stops it from doing so is that the Cortex-M4-based Puya PY32F403XC MCU only has 64 kB of SRAM. CPU-wise it would be more than capable, with a roomy 16 MB of external SPI Flash and a 323×173 pixel LC touch screen display covering the other needs. It even has a vibration motor to give you some force feedback. Interestingly, this vape has a Bluetooth Low-Energy chip built-in, but this does not seem to be used by the original Aspire firmware.

What [Aaron] did to still get some DOOM vapors on the device was to implement a screenshare firmware, allowing a PC to use the device as a secondary display via its USB interface. This way you can use the regular PC mouse and keyboard inputs to play DOOM, while squinting at the small screen.

Although not as completely overpowered as a recent Anker charging station that [Aaron] played DOOM on, we fully expect vapes in a few years to be perfectly usable for some casual gaming, with this potentially even becoming an original manufacturer’s function, if it isn’t already.

Continue reading “When Low SRAM Keeps The DOOM Off Your Vape”

Hosting A Website On A Disposable Vape

For the past years people have been collecting disposable vapes primarily for their lithium-ion batteries, but as these disposable vapes have begun to incorporate more elaborate electronics, these too have become an interesting target for reusability. To prove the point of how capable these electronics have become, [BogdanTheGeek] decided to turn one of these vapes into a webserver, appropriately called the vapeserver.

While tearing apart some of the fancier adult pacifiers, [Bogdan] discovered that a number of them feature Puya MCUs, which is a name that some of our esteemed readers may recognize from ‘cheapest MCU’ articles. The target vape has a Puya PY32F002B MCU, which comes with a Cortex-M0+ core at 24 MHz, 3 kB SRAM and 24 kB of Flash. All of which now counts as ‘disposable’ in 2025, it would appear.

Even with a fairly perky MCU, running a webserver with these specs would seem to be a fool’s errand. Getting around the limited hardware involved using the uIP TCP/IP stack, and using SLIP (Serial Line Internet Protocol), along with semihosting to create a serial device that the OS can use like one would a modem and create a visible IP address with the webserver.

The URL to the vapeserver is contained in the article and on the GitHub project page, but out of respect for not melting it down with an unintended DDoS, it isn’t linked here. You are of course totally free to replicate the effort on a disposable adult pacifier of your choice, or other compatible MCU.

Reverse-Engineering Aleratec CD Changers For Archival Use

Handling large volumes of physical media can be a bit of a chore, whether it’s about duplication or archiving. Fortunately this is a perfect excuse for building robotic contraptions, with the robots for handling optical media being both fascinating and mildly frustrating. When [Shelby Jueden] of Tech Tangents fame was looking at using these optical media robots for archival purposes, the biggest hurdle turned out to be with the optical drives, despite these Aleratec units being primarily advertised for disc duplication.

Both of the units are connected to a PC by USB, but operate mostly standalone, with a documented protocol for the basic unit that makes using it quite easy to use for ripping. This is unlike the larger, triple-drive unit, which had no documented protocol. This meant having to sniff the USB traffic that the original, very limited, software sends to the robot. The protocol has now been documented and published on the Tech Tangents Wiki for this Aleratec Auto Publisher LS.

Where [Shelby] hit a bit of a brick wall was with mixed-media discs, which standalone DVD players are fine with, but typical IDE/SATA optical drives often struggle with. During the subsequent search for a better drive, the internals of the robot were upgraded from IDE to SATA, but calibrating the robot for the new drives led [Shelby] down a maddening cascade of issues. Yet even after making one type of drive work, the mixed-media issue reared its head again with mixed audio and data, leaving the drive for now as an imperfect, but very efficient, ripper for game and multimedia content, perhaps until the Perfect Optical Drive can be found.

Continue reading “Reverse-Engineering Aleratec CD Changers For Archival Use”

Reverse-Engineering The Milwaukee M18 Diagnostics Protocol

As is regrettably typical in the cordless tool world, Milwaukee’s M18 batteries are highly proprietary. Consequently, this makes them a welcome target for reverse-engineering of their interfaces and protocols. Most recently the full diagnostic command set for M18 battery packs were reverse-engineered by [ToolScientist] and others, allowing anyone to check useful things like individual cell voltages and a range of statistics without having to crack open the battery case.

These results follow on our previous coverage back in 2023, when the basic interface and poorly checksummed protocol was being explored. At the time basic battery management system (BMS) information could be obtained this way, but now the range of known commands has been massively expanded. This mostly involved just brute-forcing responses from a gaggle of battery pack BMSes.

Interpreting the responses was the next challenge, with responses like cell voltage being deciphered so far, but serial number and the like being harder to determine. As explained in the video below, there are many gotchas that make analyzing these packs significantly harder, such as some reads only working properly if the battery is on a charger, or after an initial read.

Continue reading “Reverse-Engineering The Milwaukee M18 Diagnostics Protocol”