Watching movies on the big screen is fun, but getting out to the cinema or drive-in can be a hassle. It’s possible to get the same experience at home with a little creativity, as shown in this DIY projector screen build by [The Hook Up].
The build started with a giant motorized roller screen designed for a patio. It was scored on the cheap as it was salvaged after removal from its original home. Having seen a screen door turned into a boat with the help of Flex Seal, [The Hook Up] was confident that the flyscreen could be sealed up and used for projection.
Right away, the going got tough. Light applications weren’t really filling in the holes in the flyscreen, while thick applications had major issues with runs. Eventually, the screen was painted with 3 gallons of white Flex Seal and hung up to test.
The runs caused issues, as the lumpy screen texture was distracting when viewing movies. Additionally, the glossy finish was creating unsightly reflections. After some trial and error, the issues were solved by sanding the Flex Seal surface flat and using matte clear spray paint to dull the shine.
Lobe pumps are perhaps most popularly known for their use in Rootes-type superchargers, but they can pump water, too. [Let’s Print] demonstrates this ably with a 3D-printed design that can pump with the best of them.
The design uses two figure-eight shaped counter-rotating rotors, or lobes. As the rotors turn, they trap fluid between the rotor and the housing, forcing it towards the outlet. It’s a positive-displacement design, meaning it traps a fixed volume of fluid in each rotation, moving it from inlet to outlet.
The design requires proper timing of the two rotating lobes in order to ensure they maintain the closed volume and don’t impact each other. This is achieved with a pair of timing gears on the back of the pump. The housing, lobes, and gears are all 3D-printed, making this a build that anyone can replicate at home with their own printer.
ABS was used for the rotors for its better handling of friction without melting as easily. However, resin-printed lobes were also employed for their higher tolerances, too, with both designs working acceptably in practice.
The pump still needs more improvement; the hope is to reduce the leaks out of the rear of the pump. [Let’s Print] also intends to add a motor to the pump itself rather than using a power drill to run the device. It’s great to see these 3D-printed pump builds continuing in earnest. Video after the break.
Stewart platforms are pretty neat, and not seen in the wild all that often, perhaps because there aren’t a vast number of hacker-friendly applications that need quite this many degrees of freedom within such a restricted movement range. Anyway, here’s an interesting implementation from the the curiously named [Circular-Base-Stewart-Platform] YouTube channel (no, we can’t find the designer’s actual name) with a series of videos from a few years ago, showing the construction and operation of such a beast. This is a very neat mechanism comprised of six geared motors on the end of arms, engaging with a large internal gear. The common end of each arm rides on the central shaft, each with its own bearing. With the addition of the usual six linkages, twelve ball joints, and a few brackets, a complete platform is realised.
This circular arrangement is so simple that we can’t believe we haven’t come across it before. One interesting deviation from the usual Stewart platform arrangement is the use of a central slip-ring connector to provide power, allowing the whole assembly to rotate continuously, in addition to the usual six degrees of freedom the mechanism allows. Control is courtesy of an Arduino Pro Mini, which drives the motors using a handful of Pololu TB6612 (PDF) dual H-bridge driver modules. Obviously, the sketch running on the Arduino will give the thing a fixed motion, but add in an additional data link over that central slip-ring setup (or maybe a wireless link), and it will be much more useful.
When we think of robotics, the first thing that usually comes to mind for many of us is some sort of industrial arm that’s bolted to the floor, or perhaps a semi-autonomous rover trudging its way across the dusty Martian landscape. While these two environments are about as different as can be, the basic “rules” are pretty much the same. Being on firm ground ground gives the robot a clear understanding of its position and orientation, which greatly simplifies tasks such as avoiding collisions or interacting with nearby objects.
But what happens when that reference point goes away? How does a robot navigate when it’s flying through open space or hovering in mid-air? That’s just one of the problems that fascinates Nick Rehm, who stopped by to host this week’s Aerial Robotics Hack Chat to talk about his passion for flying robots. He’s currently an aerospace engineer at Johns Hopkins Applied Physics Laboratory, where he works on the unique challenges faced by autonomous flying vehicles such as the detection and avoidance of mid-air collisions, as well as the development of vertical take-off and landing (VTOL) systems. But before he had his Master’s in Aerospace Engineering and Rotorcraft, he got started the same way many of us did, by playing around with DIY projects.
In fact, regular Hackaday readers will likely recall seeing some of his impressive builds. His autonomous ekranoplan designed to follow a target using computer vision graced the front page in April. Back in 2020, we took a look at his recreation of SpaceX’s Starship prototype, which used a realistic arrangement of control surfaces and vectored thrust to perform the spacecraft’s signature “Belly Flop” maneuver — albeit with RC motors and propellers instead of rocket engines. But even before that, Nick recalls asking his mother for permission to pull apart a Wii controller so he could use its inertial measurement unit (IMU) in a wooden-framed tricopter he was working on.
Discussing some of these hobby builds leads the Chat towards Nick’s dRehmFlight project, a GPLv3 licensed flight control package that can run on relatively low-cost hardware, namely a Teensy 4.0 microcontroller paired with the GY-521 MPU6050 IMU. The project is designed to let hobbyists easily experiment with VTOL craft, specifically those that transition between vertical and horizontal flight profiles, and has powered the bulk of Nick’s own flying craft.
Moving onto more technical questions, Nick says one of the most difficult aspects when designing an autonomous flying vehicle is getting your constraints nailed down. What he means by that is having a clear goal of what the craft needs to do, and critically, how long it needs to do it. How far does the craft need to be able to fly? How fast? Does it need to loiter at the target location, and if so, for how long? The answers to these questions will largely dictate the form of the final vehicle, and are key to determining if it’s worth implementing the complexity of transitioning from VTOL to fixed-wing horizontal flight.
But according to Nick, the biggest challenge in aerial robotics is onboard state estimation. That is, the ability for the craft to know its position and orientation relative to the ground. While high-performance computers have gotten lighter and sensors have improved, he says there’s still no substitute for having a ground-based tracking system. He mentions that those fancy demonstrations you’ve seen with drones flying in formation and working collaboratively towards a task will almost certainly have an array of motion capture cameras tucked off to the side. This makes for an impressive show, but greatly limits the practical application of these drone swarms.
Nick’s custom Raspberry Pi 4-powered quadcopter lets him test autonomous flight techniques.
So what does the future of aerial robotics look like? Nick says open source projects like ArduPilot and PX4 are still great choices for hobbyists, but sees promise in newer platforms which pair the traditional autopilot with more onboard computing power, such as Auterion’s Skynode. More powerful flight controllers can enable techniques such as simultaneous localization and mapping (SLAM), which uses 3D scans of the environment to help the robot orient itself. He’s also very interested in technologies that enable autonomous flight in GPS-denied environments, which is critical for robotic craft that need to operate indoors or in situations where satellite navigation is unavailable or unreliable. In light of the incredible success of NASA’s Ingenuity helicopter, we imagine these techniques will also play an invaluable role in the future airborne exploration of Mars.
We want to thank Nick for hosting this week’s Aerial Robotics Hack Chat, which turned out to be one of the fastest hours in recent memory. His experience as both an avid hobbyist and a professional in the field provided exactly the sort of insight the Hackaday community looks for, and his gracious offer to keep in touch with several of those who attended the Chat to further discuss their projects speaks to how passionate he is about this topic. We expect to see great things from Nick going forward, and would love to have him join us again in the future to see what he’s been up to.
The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.
Join Hackaday Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos for a free-as-in-beer showcase of the week’s most gnarly but palatable hacks. But first, a reminder! Round 2 of the 2022 Hackaday Prize comes to an end in the early hours of Sunday, June 12th, so there’s still enough time to put a project together and get it entered.
This week, we discuss the utility of those squishy foam balls in projects and issue the PSA that it is in fact pool noodle season, so go get ’em. We drool over if-you-have-to-ask-you-can’t-afford-it 3D printers with staircases and such, and wonder why breadboard game controls didn’t already exist. Later on we laugh about lasers, shake the bottle of LTSpice tips from [fesz], and ponder under-door attacks. Finally, we’re back to frickin’ laser beams again, and we discover that there’s a fruity demoscene in Kristina’s backyard.
The trend for making cyberdecks has seen the Raspberry Pi emerge as a favourite for these home-made computer workstations, with the all-in-one Raspberry Pi 400 providing a particularly handy shortcut to integrating the computer and keyboard components. There’s still the question of the cyberdeck chassis and screen though, and it’s one that [bobricius] has answered in what may be the simplest manner possible, by means of a riser PCB from the expansion port holding a 320×240 SPI display.
If this is starting to look familiar, then you’d be right to recognise it as a slightly higher-quality version of those cheap LCD screens that have been available for the Pi for quite a few years. Alongside the screen is a pair of speakers, and the whole thing extends upwards from the back of the Pi 400. We’d question how much load can be taken by the expansion connector, but in practice it seems not to be taking too much.
The device in use can be seen in the video below the break. It’s definitely not the largest of displays, and when used as a desktop, it’s rather cramped, but it seems adequate for a terminal. It has the advantage over many cyberdecks that when the novelty has waned, it can be removed, and the Pi 400 used with a conventional display.
The Pi 400 has been with us for nearly a couple of years now, and perhaps hasn’t had the recognition it deserves. If you’ve never tried one, take a look at our review from when it came out.
If you roll way back through the history of open source webmail projects, you’ll find Horde, a groupware web application. First released in 1998 on Freshmeat, it gained some notoriety in early 2012 when it was discovered that the 3.0 release had been tampered with, and packages containing a backdoor had been shipped for three months. While this time around it isn’t an intentional backdoor, there is a very serious problem in the Horde webmail interface. Or more accurately, a pair of problems. The most serious is CVE-2022-30287, an RCE bug allowing an authenticated user to trigger code execution on the connected server.
The vulnerable element is the Turba address book module, which uses a PHP factory method to access a specific address book. The create() method has an interesting bit of code, that first checks the initialization value. If it’s a string, that value is understood as the name of the local address book to access. However, if the factory is initialized with an array, any of the address book drivers can be used, including the IMSP driver. IMSP fetches serialized data from remote servers, and deserializes it. And yes, PHP can have deserialization bugs, and this one runs code on the host.
But it’s not that bad, it’s only authenticated users, right? That would be bad enough, but that second bug is a Cross-site Request Forgery, CSRF, triggered by viewing an email. So on a vulnerable Horde server, any user viewing a malicious message would trigger RCE on the server. Oof. So let’s talk fixes. There is a new version of the Turba module that seems to fix the bugs, but it’s not clear that the actual Horde suite has pushed an update that includes it. So you may be on your own. As is pointed out on the Sonar Blog where the vulnerability was discovered, Horde itself seems to be essentially unmaintained at this point. Maybe time to consider migrating to a newer platform. Continue reading “This Week In Security: For The Horde, Feature Not A Bug, And Confluence”→
Lobe pumps are perhaps most popularly known for their use in Rootes-type superchargers, but they can pump water, too. [Let’s Print] demonstrates this ably with a 3D-printed design 
series of videos from a few years ago, showing the construction and operation of such a beast. This is a very neat mechanism comprised of six geared motors on the end of arms, engaging with a large internal gear. The common end of each arm rides on the central shaft, each with its own bearing. With the addition of the usual six linkages, twelve ball joints, and a few brackets, a complete platform is realised.
