If you’re in motorsport, or maritime, or mining fields, you can always call on a technician to come down and fix something when it’s broken. You can lay hands on the parts, reconfigure things, make repairs, and get something working again. In space, that’s seldom possible. If you’re lucky enough to have a manned mission, you might be able to make some running repairs; if you’re working with an unmanned robot, probe, or satellite, your potions are altogether more limited. If you can’t find a fix, it’s game over—a particularly brutal result when huge budgets and years of work are on the line.

Janelle Wellons came down to Hackaday Europe to talk about space. More particularly, the engineering and debugging operations that keep all sorts of space programs alive. Her talk dives into some of the creative solutions engineers have had to come up with to save million-dollar missions from becoming unrecoverable boondoggles.

Janelle came down to Hackaday Europe to talk about space, because she lives and breathes it. An experienced aerospace engineer, she’s worked at NASA JPL and iSpace, contributing to the success of missions taking place far from our humble globe. She drew on that experience to talk through what it takes to keep a mission on the rails when things go a little sideways, which happens in space, just as it does anywhere else.

A fantastic example of that, retold in her talk, is the Galileo mission. It was built to travel far across the solar system, eventually winding up at Jupiter to study the Red Giant and its moons.  The probe was engineered with a pair of communication systems—a low-gain antenna for vital signs and management, and a high-gain antenna for sending science data and images back to Earth. The high-gain antenna was key to the mission, capable of offering 10,000 times the bandwidth of the low-gain antenna.

Tragically, though, the high-gain antenna never got to play its starring role. It didn’t deploy properly after launch, and that left NASA with a probe capable of capturing all this fantastic science data, but no way to send it home at a reasonable data rate. Janelle steps through the multiple hacks that make the most of the communication link with the low-gain antenna. NASA engineers whipped up compression algorithms for images and science data, and figured out how to array several Deep Space Network antennas for better signal. This netted an effective data transfer rate of 1,000 bits/second with the low gain antenna. It was still a far cry from the 134 kilobits per second that should have been possible with the high-gain antenna, but a huge leap forward from the 8-16 bits originally possible with the low-gain rig. Ultimately, it saved the mission, allowing the capture of mountains of scientific data on the largest planet in the solar system.

“NASA Astronaut Christina Cook is also working through troubleshooting steps of the waste management system that’s aboard the Integrity spacecraft.” – Ground control, Artemis II mission, 2026

Another great story told by Janelle concerned the Artemis II mission. The lunar flyby was part of NASA’s efforts to eventually return to the Moon itself, and was notable for debuting some special new hardware—the toilet. Unlike previous visits to the moon as part of the Apollo program, Artemis astronauts travel in luxury, with a proper commode built to handle the specific requirements of the zero-gravity space environment. Unfortunately, though, this new hardware had plenty of teething problems.

Early attempts to repair the system involved attempting to reprime the toilet’s pump by adding water to the system. It wasn’t long before the toilet threw another error, though. On the short-duration Artemis II mission, the toilet was set up to vent urine to space. Only, venting wasn’t working—with the suspicion being that the vent pipes had frozen over. The trick to solve this was simple—turning the spacecraft to face the vents towards the sun, so as to heat them enough to melt the blockage. Janelle also notes that during the multiple periods the toilet was down, the astronauts had to rely on alternative means of passing waste—showing a slide of the “collapsible contingency urinals” that did the job.

There’s also a great look at Perseverance’s twin, which lives here on Earth. Janelle has been down to the Mars yard at NASA’s Jet Propulsion Laboratory, where engineers, in her words—”test before you do.” The problem is, when you’re driving a robot on a foreign planet, you can’t just send someone over to repair a broken wheel or flip it back up if it tips over. Thus, many maneuvers and operations are rehearsed in the Mars yard with the twin of Perseverance, running it over recreated obstacles to determine a safe plan of attack.

Oftentimes, when we’re using a microcontroller, we’re whipping up some very specific code focused on executing a particular task. The device is set up to execute code that does exactly what we want with minimal overhead. However, sometimes, there are scenarios where it pays to go with a somewhat heavier setup, wherein the microcontroller runs an operating system for the benefits that offers.

Federico Terraneo came to Hackaday Europe to discuss this very topic. He talks about kernel architecture, real-time operating systems, and how to best use C++ in the world of microcontrollers.

Microcontrolling

The talk begins in a helpful place. Federico starts by explaining what an operating system actually is. Basically, it’s the software that exists between the hardware and the applications that run upon it. Breaking it down into parts, an operating system typically consists of a main kernel, atop which sits things like the basic system services, libraries, and device drivers, along with utility programs necessary to maintain and work with the system. The user interface sits on top of all that, which allows the user to select and run applications and generally use the operating system to get things done.

Of course, different operating systems differ in the specifics of their architectures. Monolithic kernels, such as Linux relies on, keep a split between kernelspace and userspace. This is where where the kernel has full hardware access running on the CPU in system mode, while the applications run in user mode without such direct access. Monolithic kernels typically only run on architectures with memory management units (MMU)—think full-scale computers with proper CPUs, like your laptop or desktop. Unikernel operating systems, like FreeRTOS, are a little different, where applications and the operating system are collapsed down into a single executable binary that runs with raw hardware access. There is no abstraction, no memory protection, or anything like that, which makes the architecture easier to run on typical microcontrollers. There are also microkernels, which aim to minimize the amount of code that runs in system mode, pushing things like drivers and filesystem access into userspace. This architecture still needs an MMU, and is mostly only seen in niche uses where high security and/or attention to safety is critical.

When it comes to microcontrollers, unikernels are the most relevant architecture to think about. However, they have limitations–in stability, in security, in the fact that there is no run-time code loading or any way to easily partially upgrade the system. The fluid kernel, which Federico came to explain, aims to solve some of these issues. It hopes to offer a scalable operating system solution that works across the world of embedded computing, where sometimes microcontroller resources are limited and where memory management units seldom exist. It’s also intended to be compatible with standard APIs—think POSIX, C++ standard libraries, and all that. Federico calls it the “UNIX on a chip” concept.

The fluid kernel aims to exist at the intersection of the monolithic kernel and the unikernel. It allows hosting applications in kernelspace or in userspace as needed. A fluid kernel is also built to be POSIX compliant twice—with the same API whether you’re operating in kernelspace or userspace. The fluid kernel concept is designed around achieving process abstraction via the hardware Memory Protection Unit (MPU) common in modern 32-bit microcontrollers. It’s not quite an MMU, and can’t do all the same fancy virtual memory tricks, but it’s enough to provide a basic level of memory protection on a microcontroller platform. The fluid kernel can also become a unikernel if so desired as a compile-time option, which takes away process support while reducing code size significantly. It allows for unikernel devleopment that can be upgraded into a fluid kernel later by flipping the compile-time option the other way.

Federico does a great job of explaining the pros and cons of the fluid kernel architecture, and explores the security implications inherent in going this route. The Miosix RTOS is discussed as the practical implementation of this philosophy, and there’s even a helpful diversion into the efficient use of C++ on microcontrollers. If you’re getting serious about embedded development, or you just want to learn about a new architecture you might find useful one day, it’s a great talk to dive into on your next lunch break.

There are many ways to detect stress in an individual. You can use self-reporting checklists, you could try and measure various vital signs like respiratory rate and pulse and infer things, or you could observe the levels of hormones like cortisol in the blood.

Or… you could pull some parts out of a Playstation 4, and get hacking. Edwin Hwu did precisely that, creating a device that can image the skin down to the nanometer and potentially even determine fine details about an individual’s health status. He came to Hackaday Europe 2026 to tell us all about it.

Look Closely

Edwin’s background is very relevant to this project. He worked in a research institute in Taiwan where he collaborated with the German National Metrology Institute, working on atomic resolution imaging on silicon wafers. When you’re doing sub-nanometer calibration work for the semiconductor industry, that’s serious stuff, as is the X-ray microscopy that Edwin has dived into. When it comes to looking at things at very tiny scales, he knows his stuff. He’s also done plenty of work on real-time cell culture monitoring, skin assessments, and even high resolution 3D printing. It’s a broad skill base that all fed into the project he came to Hackaday Europe to talk about.

There is a problem with optical microscopy that comes down to the diffraction limit of light—which means you can only image down to a resolution of around 1 micrometer. That’s why we use scanning electron microscopes for so many finer tasks, because the diffraction limit of electron beams is so much smaller. This allows the imaging of structures like carbon nanotubes or buckyballs, but with the limitation that the surface must be conductive and the imaging be done in a vacuum environment. A newer technology is the atomic force microscope (AFM), which involves using a very sharp probe with a tip of just 2-3 nanometers to actually touch molecules. This can be done without a need for a conductive surface or vacuum. When taking this approach to look at things on the nanometer scale, Edwin likens it to trying to poke a 1 euro coin with the tallest mountain on Earth. It’s a precise device with incredibly high resolution, but the average AFM costs half a million euros, and is incredibly bulky and slow at what it does. That is, unless… you find a way to build one on the cheap.

Some time ago, Edwin created an atomic force microscope using the optical head of a DVD player, achieving a resolution of 0.39 nanometers. With this build, it was possible to image a single strand of DNA. Edwin also talks about how he used simple piezoelectric buzzers to create an ultrafine scanner for this work. The piezo elements are used for actuation, since they can be controlled to make incredibly minute movements. The work developed to the point where DIY AFM kits were made available at a mere fraction of the cost of traditional laboratory-grade installations.

This work spawned a greater plan. Through his talk, Edwin explains how he figured out that e-waste gaming consoles could be turned into cutting-edge atomic force microscopes. Specifically, the Playstation 4 was the perfect candidate, with its high-end Blu-Ray optical head which is capable of reaching the diffraction limit of light. The Blu-Ray optical head is used to monitor the movement of the AFM probe, while scanning it is achieved with a piezo rig just like the earlier DVD-based build. It also has the benefit that the Blu-Ray hardware is built for higher data rates, meaning it’s possible to stream data from the optical head much faster for a quicker AFM scan. Edwin refers to his build as the HS-DAFM—for High Speed Dermal Atomic Force Microscope—since it’s 100 times faster than traditional laboratory atomic force microscopes.

The word “dermal” is important—because Edwin has put the build to use in examining skin nanotexture, for diagnostic purposes. His talk explains how, combined with machine learning systems, the tool can be used to investigate skin conditions and help in the diagnostic process. It’s also become useful from the perspective of cosmetics, and looking at how the skin looks at the nanoscale due to factors like aging and UV exposure. With the aid of machine learning tools, Edwin has found that it’s even possible to determine if someone has asthma with 75% accuracy, just from a skin scan. There is even an exploration of mental stress versus skin nanotexture, albeit in a very preliminary stage.

If you’ve ever wondered about the finer details of doing atomic force microscopy on the cheap, or how skin texture holds the secrets of so many health-related matters, Edwin’s talk is a great one. Sometimes thinking outside of the box and the limitations of commercial laboratory equipment can lead to wonderous things, as it did here!