A great many drones out there, whether homebuilt or store-bought, follow the same basic format. Four motors, some kind of controller, and a lithium-polymer battery supplying the juice to keep everything in the air. It’s a format that produces a remarkably capable air vehicle, suitable for everything from high-speed camera work to urban search and rescue.

With that said, the format does have its limitations. [Suryansh Sharma] has been working on alternative designs for fancy and interesting drones that are half quadcopter and half blimp, and he came to Hackaday Europe 2026 to tell us all about it.

[Suryansh]’s talk took in a number of drone projects which he has been involved with. The first was the creatively-named BEAVIS, or Balloon Enabled Aerial Vehicle for IoT and Sensing. This was a project that aimed to tackle one of the greatest limitations of the common multirotor drone. Namely, as [Suryansh] so elegantly puts it, they “suck when it comes to staying in the air.” This is for a very simple reason—much like the helicopter, a multirotor drone must expend energy continuously to generate lift by spinning its propellers. Conventional multirotors don’t have wings that generate lift from forward motion, and any sort of gliding or similar behavior is basically impossible. Continual energy expenditure is the only thing keeping a multirotor aloft.

The point of BEAVIS was to fix this by combining drone tech with a simple lighter-than-air balloon. It’s an interesting combination, because a multirotor drone has excellent maneuverability and agility, but terrible endurance. A lighter-than-air balloon is quite the opposite, which has excellent endurance while suffering in all other respects. The BEAVIS concept outfits a small balloon with four motors in a split-cross configuration, which allows for planar translation as well as the ability to control yaw of the craft. With all four motors mounted horizontally in the same plane, it may seem like vertical control is not possible. However, by turning on two opposing props, it’s possible to create a low-pressure region beneath the craft which tends to push it downwards. Meanwhile, if you turn all four props on in the right directions, you create a high pressure region underneath the balloon which pushes the craft up. With the balloon, it has the benefit of being able to just hang in the air without continually burning through battery power. Endurance times of well over an hour were possible with this build, compared to maybe less than ten minutes for a comparable pure multirotor.

BEAVIS was eventually developed into Janus— described as a “morphing quadrotor blimp with balloon failure resilience.” The goal was to build a craft that was viable for deployment in the real world, and that could undertake mobile ecological sensing work. The main difference to the previous design was that it would no longer solely fly as a balloon with horizontally-mounted props. Instead, Janus would feature a mechanism to allow the rotors to be positioned in the vertical axis to allow for conventional multirotor flight. This was key to allowing the craft to fly both as a lighter-than-air craft, and to survive and keep flying in the event the balloon burst or was otherwise damaged. The build was eventually deployed in Kenya to aid in ecological data collection for conservation efforts.

[Suryansh] has been involved in other drone-related projects, too. Open Gimbal was a particularly interesting effort, involving the construction of a bench-testing rig for developing small multirotor drone craft. The 3-DoF platform offered unrestricted rotational freedom, allowing for a craft to be put through its paces in a controlled way without requiring a large open  space for free flight. [Suryansh] also discusses his work with a company called Avy, which specializes in VTOL drones with a focus on emergency response roles. The company has deployed drones that use multirotor technology to launch vertically, while relying on fixed wing aerodynamic elements to extend range and improve efficiency for longer flight times. The drones feature a neat charging setup, wherein pogo pins on the fins pick up power from the metal launchpad to ensure that batteries are fully charged and the drone is ready to go at all times.

Ultimately, multirotor drones have taken on their basic form for good reason. With that said, as [Suryansh]’s talk explains, modifications to the form can have great utility when made to suit a particularly specific mission or application. If you’re developing a drone for a certain purpose, and you’re running into hard limitations, you might try thinking outside the box to make something more fitting for your goals.

Intel’s Itanium architecture was an interesting experiment, but it has gone down in history as one of the chip giant’s bigger flops, so much so that it earned the name “Itanic” in the tech press. This is perhaps unfair, considering it did limp on until a quiet EOL in 2020. We didn’t know anyone missed it, but perhaps it was more the technical challenge than nostalgia for obsolete server hardware that led [Yufeng Gao] and [gdwnldsKSC] to spin up an instruction-set translator for the late, lamented, IA-64 architecture.

Note that it’s very much in alpha, version 0.1, so don’t expect all the things. Neither HP-UX and OpenVMS will boot, which is a pity since Itanium’s great success was arguably winning those OSes and thereby killing the bespoke architectures HP and DEC had at the time. Gentoo can get to a shell, as long as you use Kernel 6.6 or older, and Windows Server 2003 and XP-64 both apparently boot.

It’s not incredibly performant, with 486-level speeds when running on Ryzen 5000 series hardware, but then, it is a 64-bit hardware being emulated here, and pretty weird hardware at that. Itanium’s Very Long Word Instruction architecture was notoriously hard to program well. Specifically, it was hard to compile optimized programs for, so we expect optimizing an emulator is going to be similarly difficult. That’s why this is so impressive, even at this early stage.

The late, unlamented Itanium is probably one of the few systems not in the Virtual OS Museum, but perhaps eventually this project will change that.

via Raymii.org

[Pedro Neves] has a mid-drive e-bike, but he doesn’t own it — not truly, since he can’t repair the motor unit. For a hacker to be in that position, there are only two options: crack the old one and make it your own, or build your own from scratch. [Pedro] built his own and is open-sourcing it on his website for everyone to play with. Right now, that’s .step files and a BOM, so you’ll need to watch the design/build video on YouTube below to get the full picture.

His choice of a motor from an old battery-powered angle grinder is both thrifty and environmentally friendly, so we approve. His goal of 25 km/h seems like a reasonable speed limit, but may still be too fast for some countries’ regulations— so do check the local rules if you’re going to build this. Making the most of 3D-printed components is also a choice that makes the project more accessible, but don’t worry — the bearing surfaces are all metal. That includes the clutch bearing that will let you pedal home if the battery dies or the motor craps out. Well, unless the printed plastic axle gives up the ghost, but that got replaced with a CNC version, so it’s all good. Unless you’ve got legs like Hercules, it ought to hold.

If that’s not DIY enough, you could always build the motor yourself. This mid-drive is also part of a larger project [Pedro] is working on for a whole cargo bike, as he details in his video, which is a worthy project we’ve seen other examples of before.

Calculators are so ubiquitous and so familiar that they are easy to take for granted in many different ways. [lcamtuf] points out one that has probably never occurred to many of us: the user interface for a calculator is an unexpectedly complex thing.

Resolving something like 1 + 2 = is pretty straightforward but complexity compounds rapidly after that, with numerous special cases. Let’s imagine one decides to program a simple calculator UI as a weekend project. The development process might look a little like this:

1. User types in 1 + 2 = and the calculator displays 3. What happens if the user immediately presses -?
2. No problem, just consider the result of the previous operation as an already-there input. So we’ll have 3 - for this next operation, and wait for more.
3. Unless we should have treated that - as a negative sign for whatever number is coming next, making it a negative number? No, ignore that. Just treat whatever results from pressing equals as a pre-typed input.
4. Unless the user hits a number. Because if they hit 2 (for example) then we’ll have a 32 and not a 2 which they probably, definitely don’t expect. So that’s a special case and we should insert a clear if that happens.
5. Oh, better clear if the user enters a decimal, too.
6. I’m going to need a coffee…

And that’s just the tip of the iceberg. Imagine trying to figure all this out for the very first time, without the benefits of habit and history to fall back on.

The fact is that supporting the apparently trivial behavior of a simple calculator requires an underlying complex state machine that deals with all kinds of special cases in order to make the UI feel intuitive. And that’s just for a basic four-function calculator; we haven’t even touched on how special keys like % should behave.

We know [lcamtuf] speaks from experience, not just because of their deep knowledge of calculator history but because they rolled their own calculator that uses voltmeters as digit displays and there’s nothing like actually implementing something to make one appreciate it.

Just when you thought we’d run out of things to port DOOM to, here comes [Ahmed Amer] with his CSS-DOS, a massive 300 MB CSS style sheet, that runs not just DOS, but Windows 1.0 and, of course, DOOM. The CSS sheet isn’t holding a DOOM port this time, though — it’s holding a full IBM PC compatible, with a simulated 8086, 640 kB of RAM, floppy and VGA controllers. Yes, in one style sheet. We did mention it was 300 MB, right?

CSS is not a very good programming language. It’s got functions and if statements nowadays, but it doesn’t really do programs in the usual sense. That is, lists of instructions that feed one into another. You can’t change a variable without jumping through hoops. The sort of static behavior you get from a CSS sheet actually matches hardware architecture better than software, which was the key insight [Ahmed] had to make the project possible. It’s still not easy, or elegant, or perhaps even sane, as you can find out from the excellent write-up he has describing how he pulled this off. We particularly like the interactive guide to the full mountain of madness that is the .css file.

Now, we admit that “runs DOOM” may be an exaggeration — even if the maddeningly massive CSS sheet ran an IBM-AT full speed, that hardware can’t handle the game at any playable speed. It doesn’t emulate at anything close to full speed, though. Because this is such a gratuitously weird hack, it only runs at two instructions per second. No, not FPS, instructions, as in at the CPU level. Well, it could be worse, at least it’s not clock ticks. Still, if you’re time-dilated enough you can wait the 3 weeks to boot DOS, and the 3 months to load a level, you can play DOOM at 0.0001 FPS.

Look, we didn’t make the rules — they say everything has to try and run DOOM. They don’t say everything has to run it well.

At the current rate of robotics development, you might assume that we’re close to Skynet taking over. However, while we  likely wouldn’t do well in a physical fight against a robot, we can at least keep the bragging rights of having the cooler actuators. Or at least, that was the case before a new actuator came into town — introducing “Electrofluidic Fiber Muscles”.

Traditional robotic actuators use motors of some kind with a variety of gearboxes or linkages to turn rotational movement into usable movement. This isn’t always the most effective way to run some robotics movements, especially when modeling humans. This is why many have turned to pressurized modes of actuation. Though most don’t show quite the promise of the new player.

Electrofluidic Fiber Muscles use pressure to shorten muscle strands, similar to past actuators. However, these are a tad different, taking advantage of electrofluidic pressure. A small current under high voltage is able to drive a pressure gradient in a long tube. This tube can then be connected to both an extensor and flexor portion of an actuating circuit, similar to a biological mechanical system. Better yet, this driving pressure pump can be spun around the fibers themselves, making a tight package.

Unfortunately, it will probably be a bit till we see this inside a hobbyist robot. Until then, make sure to check out some other actuator feats!

Back in the days when an integrated circuit meant a simple but expensive device such as a 741 or a 555, most electronics enthusiasts made do with discrete transistor circuits. The common emitter amplifier and its variants are the most familiar, but the humble 3-legged device can do so much more. A particularly obtuse circuit is the subject of examination by [lcamtuf], the reverse avalanche oscillator. A 2N2222, a capacitor, an LED, and a resistor, the transistor is the wrong way round, and there’s nothing on its base. Yet the LED flashes, what on earth is up!

The answer lies in avalanche breakdown, the behavior of a reverse biased diode junction as the voltage across it increases. Eventually the electric field reaches the point at which an avalanche of electrons crosses the depletion layer, and the junction conducts. When connected across an RC circuit, the voltage in the capacitor slowly rises to the point at which avalanche breakdown occurs, and the capacitor abruptly discharges. As the voltage falls the avalanche conduction stops, and the cycle repeats itself. It’s a relaxation oscillator.

We’re treated to an explanation of why a transistor behaves this way and why a simple diode doesn’t, due to a “hump” in its I/V curve, and why the emitter-base junction has a lower breakdown voltage than the collector-base. It’s one of those circuits which looks as though it shouldn’t work, but never fails to oscillate.

Want to know more about transistors? Do we have the series for you!

[lcamtuf] is not just a calculator superfan, but also a skilled builder. That much is evident in the fabulous  design of Calcumator 2000, an electromechanical calculator that uses voltmeter readouts as digits (plus one at the bottom to represent decimal place). There are plenty of high-quality build images, so give it a look!

Calcumator 2000 is a bit of a love letter to a time when display technology hadn’t quite yet produced anything suitable for calculator use. This resulted in calculator designs that are generally unrecognizable compared to the 7-segment display based devices we see today. The Calcumator 2000, in all its electromechanical glory, would have fit right in that era.

The Calcumator 2000 has all the usual buttons one would expect from a simple calculator and drives a total of seven readouts, one of which acts as the decimal point. The idea of using voltmeters as digit displays came from [lcamtuf]’s voltmeter clock, an earlier work with a similar attention to detail in its design and assembly.

We want to take a moment to admire how clean the blue panel is. [lcamtuf] made it by painting one side of an acrylic panel, cutting the letters and design out on a CNC mill, then filling with white paint. The depth of the cuts gives the white elements a nifty multi-layer effect that really complements the design.

Want to see it work? Oh yes, you do. Check out the video, embedded just below.

Valve recently released a new version of the Steam Controller, which features a wired USB puck that serves both as charger and dedicated, low-latency wireless receiver. The downside is they aren’t currently available for purchase separately, but that’s not a worry because you can now make your own thanks to [safijari]’s OpenPuck project.

OpenPuck uses the highly affordable Pro Micro NRF52840 board, programmed to emulate the wireless receiver portion of the puck, meaning one can pair their Steam Controller to it just like they would with the factory puck. A major part of the project was naturally documenting the wireless protocol, but there’s also an array of extra features offered by OpenPuck.

Hitting button combos lets one conveniently emulate Xbox, Nintendo Switch, or Sony PlayStation controllers. Meaning OpenPuck can for example be plugged into a Nintendo Switch and it will see OpenPuck as an official wired controller, complete with motion sensor and haptic feedback.

Why is it necessary for this emulation to be done from OpenPuck? Because while the Steam Controller has tight integration with Steam Input — a sort of highly useful translation layer for controller inputs — that integration also means the controller’s best features only work while Steam is running. OpenPuck’s ability to emulate other console controllers makes it flexible in a way the factory puck isn’t, and a user can make the most of a single controller this way.

It’s worth noting that while the real puck has the ability to charge the controller (whether or not the user makes it walk itself), the OpenPuck doesn’t have this ability. Does that mean one must still use the factory puck for charging? Not at all, as the Steam Controller charges just fine over a USB-C connection.

There’s a short video below that demonstrates the flashing and setup, so check it out if you think it might be useful to you.

Thanks for the tip, [Jaki]!

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?

Nobody wants to breathe solder fumes; that’s a given. For most of us, an industrial-looking fan-and-filter made in China and picked up cheap feels like more than enough to keep our lungs clear. Other people, people like [George Conneely], have more refined tastes. Why have a fume extractor when you can have a work of art?

This is one of those projects where the images really speak for themselves, because the whole point is to be beautiful. Sure, the wooden case is lovingly sculpted by a—wait, it’s 3D-printed!? Yes, with the right stain and care applying it, it seems Wood PLA can fool the eye, or at least the camera. Inside that PLA case there’s a custom PCB with an ATMega microcontroller and some MOSFETS to drive the Nixie tubes. The two digits represent the fan’s set RPM as a percentage of maximum, as is clearly labeled. Using a READY/NOT READY indicator pulled from a Panvia Tornado to show whether the fan has actually spun up to its set speed is an amazing touch.

The only problem with this build is that it is too nice. We’d almost rather see it on Don Draper’s desk than risk dirtying it on a lab bench. Evidently, [George] ascribes to the philosophy that one should surround oneself with beauty whenever possible. Your tastes may differ, but to many, nixie tubes certainly qualify– whether on a desk clock or in a car’s dashboard, there’s just something about that incandescent glow.

Thanks to [George] for the tip.

Many of us remember back in our school days taking tests and filling out answers on a Scantron sheet, those long rows of A, B, C, D, and E that had to be filled in with a #2 pencil. Ever wonder why it needed a #2 pencil, or what the point of using a Scantron was at all? That question is answered in the latest video from [SimonRetro], where he takes a look at the Scantron and how it works.

One of the more interesting things about the Scantron is that it’s such a standalone device. No software needed, no keypad to mess with just two rocker switches. The on/off switch is also the way you tell it to forget the last answer sheet and allow you to program in a new test. Upon booting, you feed in a Scantron sheet with some specific boxes filled in, and then it’s programmed and ready to take in and grade all the students’ answers. Opening up the Scantron reveals it’s pretty interesting inside: one control board with early-’90s-era chips. There’s also a lightbulb (no LEDs) shining through the six reading sections of the card, as well as an arrangement of belts and motors to move the card through the machine. The printer is a seven-pin printer used in conjunction with a pair of ink rollers to print out the results on the cards.

[SimonRetro] also went ahead and tried different ways to mark the sheets including pens, Sharpies, colored pencils, and different thicknesses of pencils besides the #2 to see which would and wouldn’t work in the Scantron. Thanks [SimonRetro] for exploring this machine from many of our childhoods and sharing its inner workings. Be sure to check out some of our other reverse engineering articles that explore how classic devices work.

Last September, Denmark was gripped by a spate of drone sightings near airports. It’s familiar territory for Hackaday, as we reported on a similar drone panic saga at British airports back in the last decade. Back then the British police dragged their feet and hid behind secrecy laws for years to avoid admitting they overreacted, but it seems in Denmark they do things differently (Danish language, Google Translate link.).

The Danish police in Jutland have rolled back their report, and noted that a reported observation alone is not enough to confirm a drone was present. It’s not confirmed why they’ve taken this step, but we’ve been told that there’s been an effort within the drone community to identify possible aircraft flight paths which could have resulted in a false drone sighting at the times in question.

We welcome this correction, and hope that its important message travels widely. Of course it is the right thing to do for a police force to take drone reports seriously, but overreacting as the British police did is of little help. We commend the Danish police for taking this step, and we’re likely to trust any drone reports from them a little bit more in the future. If you’d like to read our plea for a sensible response at the time, it’s here.

Thanks [UAVHive] for the tip.