A team from the Institute for Automation of Complex Power System (ACS) at RWTH Aachen University have been working for a while on the analysis of widely distributed power systems. In a drive to move away from highly specialised (and expensive) electronics platforms, they have produced some instrumentation designed to operate with the Raspberry Pi platform, and an open source software stack. They call the platform the SMU (Synchronised Measurement Unit.) The SMU consists of a HAT sitting on an RPi3, inside a 3D printed box that is intended to attach to a DIN rail. After all, this is supposed to be an industrial platform.
Hardware wise, the star of the show is the Texas Instruments ADS8588S which is a 16-bit 8-channel simultaneous sampling ADC. This is quite a nice device, with 200 kSPS throughput and a per-channel programmable front end, packaged in a hacker-friendly 64-pin QFP. What makes this project interesting however, is how they solved the problem of controlling the sampled data acquisition and synchronisation.
1-PPS and BUSY edges converted to levels, then OR’d to trigger the DMA
By programming the ADC into byte-parallel mode, then using the BCM2837 Secondary Memory Interface (SMI) block together with the DMA, samples are transferred into memory with minimal CPU overhead. An onboard U-Blox Max-M8 GNSS module provides a 1PPS (top of second pulse) signal, which is combined with the ADC busy signal in a very simple manner, enabling both sample rate control as well as synchronisation between multiple units spread out in an installation. They reckon they can get synchronisation to within 180 ns of top-of-second, which for measuring relatively slow-changing power systems, should be enough. The HAT PCB was created in KiCAD and can be found in the SMU GitHub hardware section, making it easy to modify to your needs, or at least adjust the design to match the parts you can actually get your hands on.
A recent tour of an old WWII-era aircraft carrier reminded us how hard navigation was before the advent of GPS. It used to be the work of skilled people to sight the sun or the stars and use giant books to figure out a vessel’s position. Now you just ask your phone to listen to some GPS satellites and you have precision undreamed of with other systems. But GPS sometimes isn’t enough. Just using conventional GPS, you can locate yourself to a couple of meters. The new L5 band, which isn’t on all satellites yet, can get you to about 30cm. But if you need better — up to around 1 or 2 cm — you need to use special techniques lumped together as GNSS enhancements. [Viktor] wanted to have an Arudino -based lawnmower, but wanted to use more conventional GPS techniques along with ultrawideband (UWB) ranging tags.
Given that the ranging anchors are in the mowing area, we aren’t sure why the mower even has GPS other than to geofence so you can’t start autonomous operations until you are in range of the tags. The three anchors are placed in a triangle, so if the robot knows the distance to each tag it can use some math to locate itself inside the area quite precisely.
The proliferation of software-defined radio (SDR) technology has been a godsend for RF hobbyists. SDR-based receivers and transmitters have gotten so cheap that you’ve probably got a stick or two lying around your bench right now — we can see three from where we sit, in fact.
But cheap comes at a price, usually in the form of frequency stability, which can be prohibitive in some applications — especially amateur radio, where spectrum hygiene is of the utmost concern. So we were pleased to see [Tech Minds] tackle the SDR frequency stability problem by using a GPS-disciplined oscillator. The setup uses an ADALM-PLUTO SDR transceiver and a precision oscillator from Leo Bodnar Electronics. The oscillator can be programmed to output a rock-solid, GPS-disciplined signal over a wide range of frequencies. The Pluto has an external oscillator input that looks for 40 MHz, which is well within the range of the GPSDO.
Setup is as easy as plugging the oscillator’s output into the SDR’s external clock input using an SMA to UFL jumper, and tweaking the settings in the SDR and oscillator. Not all SDRs will have an external clock input, of course, so your mileage may vary. But if your gear is suitably equipped, this looks like a great way to get bang-on frequency — the video below shows just how much the undisciplined SDR can drift.
Like any good ham, [Tech Minds] is doing his bit to keep his signals clean and on target. His chief use case for this setup will be to work QO-100, amateur radio’s first geosynchronous satellite repeater. We’ve got to say that we hams living on the two-thirds of the globe not covered by this satellite are just dying to get a geosynchronous bird (or two) of our own to play with like this.
A metrology geek will go to extreme lengths to ensure that their measurements are the best, their instruments the most accurate, and their calibration spot-on. There was a time when for time-and-frequency geeks this would have been a difficult job, but with the advent of GPS satellites overhead carrying super-accurate atomic clocks it’s surprisingly easy to be right on-frequency. [Land-boards] have a GPS 10 MHz clock that’s based around a set of modules.
Since many GPS modules have a 10 MHz output one might expect that this one to simply hook a socket to the module and have done, but instead it uses another of their projects, a fast edge pulse generator with the GPS output as its oscillator, as a buffer and signal conditioner. Add to that an QT Py microcontroller board to set up the GPS, and there you have a standalone 10 MHz source to rival any standard. Full details can be found on the project’s wiki, and the firmware can be found on GitHub.
Do you know what the IODC word in GPS data means? If so, great! If not, head over to see the 32nd of [Michel van Biezen’s] 100-part video series on GPS. You probably want to watch the other 31 videos before he gets too much further ahead of you, too. [Michel] reminds you of that professor you had in college who knows a whole lot about something. In fact, scanning his YouTube channel, he knows a lot about many topics ranging from optics, chemistry, kalman filters, and lots of electronics.
There is a dedicated playlist for the GPS videos dating back to 2016. So 32 videos in about six years. So you might have a little time to catch up. While the first video is pretty introductory as you might expect, by the time you get to video 7 the topics switch to things like the C/A code, BPSK, and gory details of all the frame data, including the IODC word.
If there’s one thing that never seems to suffer from supply chain problems, it’s litter. It’s everywhere, easy to spot and — you’d think — pick up. Sadly, most of us seem to treat litter as somebody else’s problem, but with something like this machine vision litter mapper, you can at least be part of the solution.
For the civic-minded [Nathaniel Felleke], the litter problem in his native San Diego was getting to be too much. He reasoned that a map of where the trash is located could help municipal crews with cleanup, so he set about building a system to search for trash automatically. Using Edge Impulse and a collection of roadside images captured from a variety of sources, he built a model for recognizing trash. To find the garbage, a webcam with a car window mount captures images while driving, and a Raspberry Pi 4 runs the model and looks for garbage. When roadside litter is found, the Pi uses a Blues Wireless Notecard to send the GPS location of the rubbish to a cloud database via its cellular modem.
Cruising around the streets of San Diego, [Nathaniel]’s system builds up a database of garbage hotspots. From there, it’s pretty straightforward to pull the data and overlay it on Google Maps to create a heatmap of where the garbage lies. The video below shows his system in action.
Yes, driving around a personal vehicle specifically to spot litter is just adding more waste to the mix, but you’d imagine putting something like this on municipal vehicles that are already driving around cities anyway. Either way, we picked up some neat tips, especially those wireless IoT cards. We’ve seen them used before, but [Nathaniel]’s project gives us a path forward on some ideas we’ve had kicking around for a while.
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.
