Visiting Our Neighbor Sedna: Feasibility Study Of A Mission To This Planetoid

July 6, 2025 by 25 Comments
Image of Sedna, taken by the Hubble Space telescope in 2004. (Credit: NASA)
Image of Sedna, taken by the Hubble Space telescope in 2004. (Credit: NASA)

While for most people Pluto is the most distant planet in the Solar System, things get a lot more fuzzy once you pass Neptune and enter the realm of trans-Neptunian objects (TNOs). Pluto is probably the most well-known of these, but there are at least a dozen more of such dwarf planets among the TNOs, including 90377 Sedna.

This obviously invites the notion of sending an exploration mission to Sedna, much as was done with Pluto and a range of other TNOs through the New Horizons spacecraft. How practical this would be is investigated in a recent study by [Elena Ancona] and colleagues.

The focus is here on advanced propulsion methods, including nuclear propulsion and solar sails. Although it’s definitely possible to use a similar mission profile as with the New Horizons mission, this would make it another long-duration mission. Rather than a decades-long mission, using a minimally-equipped solar sail spacecraft could knock this down to about seven years, whereas the proposed Direct Fusion Drive (DFD) could do this in ten, but with a much larger payload and the ability do an orbital insertion which would obviously get much more science done.

As for the motivation for a mission to Sedna, its highly eccentric orbit that takes it past the heliopause means that it spends relatively little time being exposed to the Sun’s rays, which should have left much of the surface material intact that was present during the early formation of the Solar System. With our explorations of the Solar System taking us ever further beyond the means of traditional means of space travel, a mission to Sedna might not only expand our horizons, but also provide a tantalizing way to bring much more of the Solar System including the Kuiper belt within easy reach.

Going To The (Parallel) Chapel

July 6, 2025 by 11 Comments

There is always the promise of using more computing power for a single task. Your computer has multiple CPUs now, surely. Your video card has even more. Your computer is probably networked to a slew of other computers. But how do you write software to take advantage of that? There are many complex systems, of course, but there’s also Chapel.

Chapel is a reasonably simple programming language, but it supports parallelism in various forms. The run time controls how computers — whatever that means — communicate with one another. You can have code running on your local CPUs, your GPU, and other processing elements over the network without much work on your part.

Continue reading “Going To The (Parallel) Chapel” →

Convert Any Book To A DIY Audiobook?

July 6, 2025 by 12 Comments

If the idea of reading a physical book sounds like hard work, [Nick Bild’s] latest project, the PageParrot, might be for you. While AI gets a lot of flak these days, one thing modern multimodal models do exceptionally well is image interpretation, and PageParrot demonstrates just how accessible that’s become.

[Nick] demonstrates quite clearly how little code is needed to get from those cryptic black and white glyphs to sounds the average human can understand, specifically a paltry 80 lines of Python. Admittedly, many of those lines are pulling in libraries, and some are just blank, so functionally speaking, it’s even shorter than that. Of course, the whole application is mostly glue code, stitching together other people’s hard work, but it’s still instructive and fun to play with.

The hardware required is a Raspberry Pi Zero 2 W, a camera (in this case, a USB webcam), and something to hold it above the book. Any Pi with the ability to connect to a camera should also work, however, with just a little configuration.

On the software side, [Nick] pulls in the CV2 library (which is the interface to OpenCV) to handle the camera interfacing, programming it to full HD resolution. Google’s GenAI is used to interface the Gemini 2.5 Flash LLM via an API endpoint. This takes a captured image and a trivial prompt, and returns the whole page of text, quick as a flash.

Finally, the script hands that text over to Piper, which turns that into a speech file in WAV format. This can then be played to an audio device with a call out to the console aplay tool. It’s all very simple at this level of abstraction.

Continue reading “Convert Any Book To A DIY Audiobook?” →

A Look Through The Eye Of A Bowling Ball

July 5, 2025 by 16 Comments

If you are anything like us, last time you went bowling, you thought more about how the ball came back to you than actually knocking down the pin. Perhaps you even wondered what it would be like to be a bowling ball making its way back through mysterious and hidden machines. [Wren] and [Erik Beck] did as well, so they set out to make a bowling ball camera to find out.

At the heart of the contraption is an Insta360 X5 camera nestled between water-jet cut metal plates. Because each lens of the camera has a 200 degree field of view, anything in the overlap of the two lenses simply does not appear, so the two metal plates likewise, do not appear. This does leave a somewhat noticeable seam down the middle of the footage, but overall worked out very well. To prevent vibrations in the bowling ball, it can only be rolled along the plate line, making said seam appear in all the footage. Because the stabilization is happening purely digitally, and the camera itself is spinning with the ball, motion blur became an issue immediately. Fortunately increasing the shutter speed fixed the issue, along with an increase in ISO to compensate for the decreased exposure.

Continue reading “A Look Through The Eye Of A Bowling Ball” →

Shadow Clock Shows The Time On The Wall

July 5, 2025 by 11 Comments

What if you build a clock that displayed the time not just on its own, but in its shadows as well? [Lewis] from [DIY Machines] has done just that, with a nifty 3D-printed shadow clock build.

The clock itself, based on a design by [shiura], has a hollow rim inside which are the two hands which actually display the time. The hands appear to almost float inside the clock, a tricky visual effect of the design which instantly catches the eye. The trick is simple—the minute hand is physically attached to the outer rotor, which sets its position. Meanwhile, the floating hour hand pivots freely around the center of the clock, with a secret magnet within. This magnet is attracted to a complementary magnet in the hour rotor—as that rotor turns, the hour hand points at the magnets inside.

So far, it’s already a cool clock. The bonus feature is that [Lewis] realized this design could show an even larger clockface on the wall behind, merely by using its shadows. Thus, the clock features an LED light source which can project the clock’s shadows into a much larger display than the desktop timepiece itself.

As for the electronics, it’s straightforward stuff. An ESP8266 devboard runs the show, turning stepper motors and controlling addressable LEDs to make the clock do its thing. It also queries a network time server in order to ensure the displayed time is always accurate to the second.

We’ve featured some other excellent clocks over the years, like this incredible thermochromic build. Video after the break.

Continue reading “Shadow Clock Shows The Time On The Wall” →

Daisy Chain Of Hacks Lets New Arm Board Run Doom

July 5, 2025 by 15 Comments

Running DOOM on ARM? Old hat. Running Doom (2016) on an ARM SBC? Well, that’s a bit more interesting, and [Interfacing Linux] shows us how with this handy guide, and in a video embedded below.

The ARM SBC in question is the Radxa Orion O6, which claims to be the world’s first open source ARMv9 motherboard. It has a 12-core ARM9.2 SoC from Cix, and crucially for gaming, a PCIe x16 slot to fit a graphics card. There’s onboard graphics in the SoC, of course, but that’s only going to cut it for old DOOM, not Doom (2016).

Obviously there is no ARMv9 build of this nine-year-old classic. Thus, a certain degree of hacking is required. An x86 emulation layer called FEX is used to run Steam, which includes the Proton compatibility layer to sit between the Linux system and the Windows system calls the games are making.

So, again: Windows games, running via a compatibility layer on a Linux system running on an x86 emulator, running on another Linux system, running on ARM hardware. Yeah, we’d call that a hack, and just possibly cursed. The amazing thing is that it works. As long as you use a PCI 3.0 graphics card, anyway; apparently newer ones don’t work, or at least not the one [Interfacing Linux] had to try. (Some report better luck with newer NVIDIA cards.) Which is a pity, because every game tested is GPU-throttled on this system. Considering the CPU should be handling all the emulation, that just goes to show how GPU-heavy even 10-year-old games are.

[Interfacing Linux] seems to enjoy running things where they should not; we just wrote up their SteamOS console.

This isn’t the first time a Radxa board has shown up on Hackaday either, but they don’t seem to be nearly as popular as the fruit-flavoured competition for the sort of projects we usually see. If you’ve got a good project using one of these powerful ARM boards– or anything else, don’t hesitate to send us a tip!

 

 

Mapping Tool Helps Identify Usable Land For Building

July 5, 2025 by 9 Comments

How would you go about identifying usable land that suits your building tastes? [Scott Sexton] was specifically looking for land that’s not too steep to build on, and realized that existing resources didn’t easily offer him this information. He thus dived into the world of GIS to try and solve this issue for himself.

[Scott] hoped that USGS maps might provide the information he needed, but found they lacked grade information, only presenting elevation and topographic data instead. From past experience reading such maps, he knew that seeing a lot of topographical lines close together tended to indicate steeper areas, but wasn’t sure on how to actually get the computer to parse this and spit out the information on steepness and grade that he wanted.

Ultimately, he set about downloading USGS elevation data in three-meter resolution. He then applied some calculus to determine the rate of change of the slope across areas of the data in order to mathematically find what he was looking for. Namely, flatter areas that would be more suitable for future construction. He then took the work even further, tweaking the output of his tools and automating until he could quickly and readily generate usability maps of areas of interest. He was even able to sanity-check his work by verifying that it correctly identified roads as obviously flat areas.

If you’ve ever tinkered with GIS work, [Scott’s] usability project may be of some interest. We’ve also seen amusing examples of what can go wrong when digital mapping data is used without sanity checks. Meanwhile, if you’ve got your own GIS hacks on the go, don’t hesitate to notify us via the tipsline!