Using Multiple Quadcopters To Efficiently Lift Loads Together

Much like calling over a buddy or two to help with moving a large piece of furniture and pivot it up a narrow flight of stairs, so too can quadcopters increase their carrying capacity through the power of friendship and cooperation. However, unless you want to do a lot of yelling at your mates about when to pivot and lift, you’d better make sure that your coordination is up to snuff. The same is true with quadcopters, where creating an efficient coordination algorithm for sharing a load is far from easy and usually leads to fairly slow and clumsy maneuvering.

Simplified overview of the motion planner by Sihao Sun et al.
Simplified overview of the motion planner by Sihao Sun et al.

Recently. researchers at the Technical University of Delft came up with what appears to be a quite efficient algorithm for this purpose. In the demonstration video below, it’s easy to see how the quadcopters make short work of even convoluted obstacles while keeping themselves and their mates from getting tangled.

The research by [Sihao Sun] et al. appears in Science Robotics (preprint), in which they detail their trajectory-based framework and its kinodynamic motion planner. In short, this planner considers the whole-body dynamics of the load, the cables, and the quadcopters. An onboard controller for each quadcopter is responsible for translating the higher-level commands into specific changes to its rotor speeds and orientation.

Along with tests of its robustness to various environmental factors, such as wind, the researchers experimented with how many simultaneous quadcopters could work together with their available computing capacity. The answer, so far, is nine units, though they think that the implementation can be further optimized.

Of course, sometimes you just want to watch synchronized drones.

Continue reading “Using Multiple Quadcopters To Efficiently Lift Loads Together”

Using The Pyroelectric Effect To Identify Broken MLCC Capacitors

Vintage computer hardware can fail in a variety of fascinating ways, with [Bits und Bolts] dealing with an interesting failure mode, in the form of degraded MLCC capacitors on Voodoo 2 graphics cards. These little marvels of miniaturized surface-mount technology enable the placement of ceramic capacitors with very little space required, but as they degrade over time or due to physical damage, they can cause big issues in a circuit.

In the case of the two Voodoo 2 GPUs that [Bits und Bolts] was trying to fix, the clue that something was wrong was graphical glitches, which seemed to be related to something dragging down the 5V rail. Using the standard ‘inject voltage and see what gets hot’ method, he discovered a couple of dead MLCCs and replaced them. But something was still dragging the rail down. Unfortunately, whatever it was wasn’t enough to heat up the part in question, and no sane person wants to desolder hundreds or even thousands of MLCCs on a PCB and see whether it makes a difference.

Ultimately, the pyroelectric effect was used to hunt down the culprit, saving countless hours of work. This is a property of certain naturally electrically polarized crystals, in which the material generates a voltage when heated or cooled. Materials like that used in MLCCs, for example.

Continue reading “Using The Pyroelectric Effect To Identify Broken MLCC Capacitors”

Building A Drivable, Life-Size 3D-Printed LEGO Technic Buggy

The 8845 LEGO Technic Dune Buggy original. (Credit: Matt Denton)
The 8845 LEGO Technic Dune Buggy original. (Credit: Matt Denton)

It’s part of the great circle of life that toys and scale models that provide a reflection of macro-sized objects like vehicles and buildings will eventually be scaled up again to life-sized proportions. Case in point the LEGO Technic dune buggy that [Matt Denton] recently printed at effectively human scale, while also making it actually drivable.

The basis for this project is the 8845 Dune Buggy which was released in 1981. Unlike the modern 42101 version, it’s more straightforward and also seems more amenable to actually sitting in despite featuring more pieces for a total of 174 pieces.  Naturally, [Matt] didn’t simply go for a naïve build of the 8845 buggy, but made a few changes. First is the scale that’s 10.42 times larger than the LEGO original, based around the use of 50 mm bearings. The model was also modified to be a single-seater, with the steering wheel placed in the center.

With some structural and ergonomic tweaks in place, the resulting CAD model was printed out mostly in PLA with a 1 mm nozzle and 10% infill using a belt FDM printer to help with the sheer size of the parts. After that it was mostly a LEGO kit assembly on a ludicrous scale that resembles a cross between building a LEGO kit and assembling Ikea flatpack furniture.

At merely the cost of most of his sanity, [Matt] finally got the whole kit together, still leaving a few suspension issues to resolve, as it turns out that so much plastic actually weighs a lot, at 102 kg. With that and other issues resolved, the final touch was to add an electric motor to the whole kit using a belt-driven system on the rear axle and bringing every LEGO minifig’s dreams to life.

After a few test drives, some issues did pop up, including durability concerns and not a lot of performance, but overall it performs much better than you’d expect from a kid’s toy.

Continue reading “Building A Drivable, Life-Size 3D-Printed LEGO Technic Buggy”

Android Developer Verification Starts As Google Partially Retreats On Measures

In a recent blog post Google announced that the early access phase of its Android Developer Verification program has commenced, as previously announced. In addition to this new announcement Google also claims to be taking note of the feedback it has been receiving, in particular pertaining to non-commercial developers for whom these new measures are incredibly inconvenient. Yet most notable is the ’empowering experienced users’ section, where Google admits that to developers and ‘power users’ the intensive handholding isn’t required and it’ll develop an ‘advanced flow’ where unverified apps can still be installed without jumping through (adb) hoops. Continue reading “Android Developer Verification Starts As Google Partially Retreats On Measures”

Tiny386 On An Espressif ESP32-S3

Some people may remember the joys of trying to boot Linux on an 8-bit AVR microcontroller, which was an absolute exercise in patience. In comparison [He Chunhui]’s Tiny386 emulator running on an ESP32-S3 MCU is positively zippy when it boots and runs Windows 95. The provided video (also embedded below) makes clear that while you can comfortably waddle off to prepare and pour a fresh cup of tea, it’s actually borderline usable.

The source code can be obtained via GitHub, which contains not just the basic emulated 80386 CPU written in C99, but also peripherals borrowed from TinyEMU and QEMU, along with a SeaBIOS ROM. In addition to the Windows 95 demo it’s claimed that Tiny386 should be able to run most 16/32-bit software.

Right now the ESP32-S3 version targets the JC3248W535 board, which is a roughly $30 development board featuring a built-in display with touch screen and an ESP32-S3 module. Although it has a USB-C port, it appears that this one is just for programming and not for the USB peripheral of the ESP32-S3. With the USB OTG peripheral used, one could conceivably make a small 386 system based around an ESP32-S3 that features a USB hub to plug a keyboard, mouse, etc. into.

Considering that the Tiny386 emulator is a very simple and straightforward approach to emulating an early-90s PC, some optimization might enable a pretty zippy general purpose PC for early 90s software. Quite a boost from watching Linux struggle into a command line on an AVR, indeed.

Continue reading “Tiny386 On An Espressif ESP32-S3”

Running A Minecraft Server On A WiFi Light Bulb

WiFi-enabled ‘smart’ light bulbs are everywhere these days, and each one of them has a microcontroller inside that’s capable enough to run all sorts of interesting software. For example, [vimpo] decided to get one running a minimal Minecraft server.

The Bl602-equipped board inside the LED lightbulb. (Credit: vimpo, YouTube)
The Bl602-equipped board inside the LED lightbulb. (Credit: vimpo, YouTube)

Inside the target bulb is a BL602 MCU by Bouffalo Lab, that features not only a radio supporting 2.4 GHz WiFi and BLE 5, but also a single-core RISC-V CPU that runs at 192 MHz and is equipped with 276 kB of RAM and 128 kB flash.

This was plenty of space for the minimalist Minecraft server [vimpo] wrote several years ago. The project says it was designed for “machines with limited resources”, but you’ve still got to wonder if they ever thought it would end up running on a literal lightbulb at some point.

It should be noted, of course, that this is not the full Minecraft server, and it should only be used for smaller games like the demonstrated TNT run mini game.

Perhaps the next challenge will be to combine a large set of these light bulbs into a distributed computing cluster and run a full-fat Minecraft server? It seems like a waste to leave the BL602s and Espressif MCUs that are in these IoT devices condemned to a life of merely turning the lights on or off when we could have them do so much more.

Continue reading “Running A Minecraft Server On A WiFi Light Bulb”

Wayland’s Never-Ending Opposition To Multi-Window Positioning

There are many applications out there that use more than one window, with every modern-day platform and GUI toolkit offering the means for said application to position each of its windows exactly where it wants, and to restore these exactly in the configuration and location where the user saved it for that particular session. All toolkits but one, that is, for the Wayland project keeps shooting down proposals. Most recently merge request #264 for the ext-zones protocol by [Matthias Klumpp] as it descended into a 600+ comments spree.

This follows on an attempt two years prior with MR#247, which was rejected despite laying out sound reasons why the session protocol of Wayland does not cover many situations. In the breakdown video of the new ext-zones protocol discussion by [Brodie Robertson] the sheer absurdity of this whole situation becomes apparent, especially since KDE and others are already working around the Wayland project with their own extensions such as via KWin, which is being used commercially in e.g. the automotive world.

In a January 2024 blog post [Matthias] lays out many of his reasonings and views regarding the topic, with a focus on Linux desktop application usage from a scientific application perspective. When porting a Windows-, X11- or MacOS application to Wayland runs into compatibility issues that may necessitate a complete rewrite or dropping of features, the developer is more likely to stick to X11, to not port to Linux at all, or to use what eventually will amount to Wayland forks that patch around these missing API features.

Meanwhile X11 is definitely getting very long in the tooth, yet without it being a clean drop-in replacement it leaves many developers and end-users less than impressed. Perhaps the Wayland project should focus more on the needs of developers and end-users, and less about what it deems to be the One True Way?

Continue reading “Wayland’s Never-Ending Opposition To Multi-Window Positioning”