Open Source Your Air Ride Suspension

Air ride suspensions have several advantages over typical arrangements, but retrofitting a system to a vehicle that didn’t come with it can get pricey fast, especially if you want to go beyond the basics. The Open Source Air Suspension Management Controller aims to give people a fully customizable system without the expense or limitations of commercial units.

The project started as an upgrade to a basic commercial system, so it assumes that you’re bringing your own “bags, tank, compressor, tubing and fittings.” The current board uses an Arduino Nano, but the next revision based on the ESP32 will allow for a wider feature set.

With a Bluetooth connection and Android app, you can control your ride height from a phone or integrated Android head unit. Currently, the app shows the pressure readings from all four corners and has controls for increasing or decreasing the pressure or airing all the way up or down to a given set point.

Want to know how air suspensions work? How about this LEGO model? If you want a suspension with active tuning for your bike, how about this Arduino-powered mod?

Linux Fu: Kernel Modules Have Privileges

I did something recently I haven’t done in a long time: I recompiled the Linux kernel. There was a time when this was a common occurrence. You might want a feature that the default kernel didn’t support, or you might have an odd piece of hardware. But these days, in almost all the cases where you need something like this, you’ll use loadable kernel modules (LKM) instead. These are modules that the kernel can load and unload at run time, which means you can add that new device or strange file system without having to rebuild or even restart the kernel.

Normally, when you write programs for Linux, they don’t have any special permissions. You typically can’t do direct port I/O, for example, or arbitrarily access memory. The kernel, however, including modules, has no such restriction. That can make debugging modules tricky because you can easily bring the system to its knees. If possible, you might think about developing on a virtual machine until you have what you want. That way, an errant module just brings down your virtual machine. Continue reading “Linux Fu: Kernel Modules Have Privileges”

A Closer Peek At The Frame AR Glasses

The Frame AR glasses by Brilliant Labs, which contain a small display, are an entirely different approach to hacker-accessible and affordable AR glasses. [Karl Guttag] has shared his thoughts and analysis of how the Frame glasses work and are constructed, as usual leveraging his long years of industry experience as he analyzes consumer display devices.

It’s often said that in engineering, everything is a tradeoff. This is especially apparent in products like near-eye displays, and [Karl] discusses the Frame glasses’ tradeoffs while comparing and contrasting them with the choices other designs have made. He delves into the optical architecture, explaining its impact on the user experience and the different challenges of different optical designs.

The Frame glasses are Brilliant Labs’ second product with their first being the Monocle, an unusual and inventive sort of self-contained clip-on unit. Monocle’s hacker-accessible design and documentation really impressed us, and there’s a pretty clear lineage from Monocle to Frame as products. Frame are essentially a pair of glasses that incorporate a Monocle into one of the lenses, aiming to be able to act as a set of AI-empowered prescription glasses that include a small display.

We recommend reading the entire article for a full roundup, but the short version is that it looks like many of Frame’s design choices prioritize a functional device with low cost, low weight, using non-specialized and economical hardware and parts. This brings some disadvantages, such as a visible “eye glow” from the front due to display architecture, a visible seam between optical elements, and limited display brightness due to the optical setup. That being said, they aim to be hacker-accessible and open source, and are reasonably priced at 349 USD. If Monocle intrigued you, Frame seems to have many of the same bones.

Bent Shaft Isn’t A Bad Thing For This Pericyclic Gearbox

With few exceptions, power transmission is a field where wobbling is a bad thing. We generally want everything running straight and true, with gears and wheels perfectly perpendicular to their shafts, with everything moving smoothly and evenly. That’s not always the case, though, as this pericyclic gearbox demonstrates.

Although most of the components in [Retsetman] model gearboxes seem familiar enough — it’s mostly just a collection of bevel gears, like you’d see inside a differential — it’s their arrangement that makes everything work. More specifically, it’s the shaft upon which the bevel gears ride, which has a section that is tilted relative to the axis of the shaft. It’s just a couple of degrees, but that small bit of inclination, called nutation, makes the ring gear riding on it wobble as the shaft rotates, allowing it to mesh with one or more ring gears that are perpendicular to the shaft. This engages a few teeth at a time, transferring torque from one gear to another. It’s easier to visualize than it is to explain, so check out the video below.

Gearboxes like these have a lot of interesting properties, with the main one being gear ratio. [Retsetman] achieved a 400:1 ratio with just 3D printed parts, which of course impose their own limitations. But he was still able to apply some pretty serious torque. The arrangement is not without its drawbacks, of course, with the wobbling bits naturally causing unwelcome vibrations. That can be mitigated to some degree using multiple rotatins elements that offset each other, but that only seems to reduce vibration, not eliminate it.

[Retsetman] is no stranger to interesting gearboxes, of course, with his toothless magnetic gearboxes coming to mind. And this isn’t the only time we’ve seen gearboxes go all wobbly, either.

Continue reading “Bent Shaft Isn’t A Bad Thing For This Pericyclic Gearbox”

Human Brains Can Tell Deepfake Voices From Real Ones

Although it’s generally accepted that synthesized voices which mimic real people’s voices (so-called ‘deepfakes’) can be pretty convincing, what does our brain really think of these mimicry attempts? To answer this question, researchers at the University of Zurich put a number of volunteers into fMRI scanners, allowing them to observe how their brains would react to real and a synthesized voices.  The perhaps somewhat surprising finding is that the human brain shows differences in two brain regions depending on whether it’s hearing a real or fake voice, meaning that on some level we are aware of the fact that we are listening to a deepfake.

The detailed findings by [Claudia Roswandowitz] and colleagues are published in Communications Biology. For the study, 25 volunteers were asked to accept or reject the voice samples they heard as being natural or synthesized, as well as perform identity matching with the supposed speaker. The natural voices came from four male (German) speakers, whose voices were also used to train the synthesis model with. Not only did identity matching performance crater with the synthesized voices, the resulting fMRI scans showed very different brain activity depending on whether it was the natural or synthesized voice.

One of these regions was the auditory cortex, which clearly indicates that there were acoustic differences between the natural and fake voice, the other was the nucleus accumbens (NAcc). This part of the basal forebrain is involved in the cognitive processing of e.g. motivation, reward and reinforcement learning, which plays a key role in social, maternal and addictive behavior. Overall, the deepfake voices are characterized by acoustic imperfections, and do not elicit the same sense of recognition (and thus reward sensation) as natural voices do.

Until deepfake voices can be made much better, it would appear that we are still safe, for now.

Lindroid Promises True Linux On Android

Since Android uses Linux, you’d think it would be easier to run Linux apps on your Android phone or tablet. There are some solutions out there, but the experience is usually less than stellar. A new player, Lindroid, claims to provide real Linux distributions with hardware-accelerated Wayland on phones. How capable is it? The suggested window manager is KDE’s KWIN. That software is fairly difficult to run on anything but a full-blown system with dbus, hardware accelerations, and similar features.

There are, however, a few problems. First, you need a rooted phone, which isn’t totally surprising. Second, there are no clear instructions yet about how to install the software. The bulk of the information available is on an X thread. You can go about 4 hours into the very long video below to see a slide presentation about Lindroid.

Continue reading “Lindroid Promises True Linux On Android”

Programming Robots Is Hard, Figuring Out How To Make It Easier Is Harder

[Benjie Holson] is an experienced roboticist and wrote an interesting article published on IEEE Spectrum about how the idea most people have of non-roboticists is a myth, and efforts to target this group with simplified robotic frameworks tend to be doomed.

Now, let’s make a couple things absolutely clear right up front: He is not saying robots shouldn’t be easier to program, nor is he saying that non-roboticists literally do not exist (of course they do.) The issues he’s highlighting really come down to product design.

[Benjie] points out that programming robots is super hard, but it’s also hard in more than one way and for more than one reason. And when people try to create a product to make it easier, they tend to commit two big product design no-no’s: they focus on the wrong hard parts, and they design their product for a vaguely-defined audience that doesn’t really exist. That group is the mythical non-roboticist.

These are actually very solid points to make in terms of product design in general. Designing a product that solves the wrong problems for a poorly-defined group isn’t exactly a recipe for success. [Benjie]’s advice on making a truly effective and useful API framework that genuinely lowers the bar of complexity in a useful way is similarly applicable to product design in general.

His first piece of advice is not to design for poorly-defined amorphous groups. Your product should serve actual needs of actual users. If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.

The second is to design as though your users are just as smart as you are, just less tolerant of problems stemming from rough edges like compatibility and configuration issues. Remove those so that your users can get useful work done without having to re-invent the wheel, or resort to workarounds.

Robotic frameworks like ROS are useful and extensible, but whenever someone attempts to focus on creating a simplified framework, [Benjie] says they tend to step on the same rakes. It’s a mistake [Benjie] has committed himself, and see repeated by others. We think his advice is good product design advice in general, whether for designing APIs or something else.