We’ve seen plenty of impressive robots of all sizes here at Hackaday, but recently we were particularly inspired by [Hans Jørgen Grimstad] and his thrifty mini sumo build.
Using the BBC micro:bit platform as a starting point, Hans seized the opportunity to build a competitive mini sumo bot without breaking the bank. According to his blog, the enchanting little machine uses commonly available parts and cost around $30 when built in 2020 (or $50 according to the more recent video, perhaps taking into account the cost of hardware in these trying times).
The results can be seen in the video below. Some sacrifices were made – Hans admits that the 3.3 V linear regulator gets a little toasty, but the design is kept much simpler by doing away with a switching regulator. The 700 RPM N20 motors are wired directly up to the 6 V battery pack, giving this plucky wrestler plenty of sumo-smashing power.
Hans hopes that the build can lower barriers to entry for new builders in robot tournaments, being something that can easily be put together in a garage or local makerspace for a low, low price. The mini sumo form factor is a great beginner or amateur project, made even easier when makers like Hans put all the nitty-gritty details up on GitHub. This is certainly not the first accessible sumo robotics project that we have covered, and it won’t be the last. We hope we see loads more of these endearing robotic gladiators at future events.
While the impulse to solving problems in complex systems is often to grab a microcontroller and some sensors to automate the problem away, interfacing with the real world is often a lot more difficult than it appears. Measuring soil moisture, for example, seems like it would be an easy way of ensuring plants get the proper amount of water, but soil is a challenging environment for electronics and this solution often causes more problems than it solves. [Kevin] noticed this problem with soil moisture sensors and set about solving this problem with a much simpler, though indirect, method of monitoring his plants electronically.
Rather than relying on soil conductivity for testing soil moisture levels, he has developed an alternate method of determining if the plants need to be watered simply by continuously weighing them. The hypothesis that he had was that a plant that needs water will weigh less as the available water respirates out of the plant or evaporates from the soil. This means that using a reliable sensor like a load cell to measure weight rather than an unreliable one like a soil moisture sensor will result in more reliable data he can use to automate his plants’ watering.
[Kevin]’s build is based around an ESP32 and a commercially-available load cell which are all built into the base of the plant’s pot. The design hides all of the electronics in a pleasant enclosure and is able to communicate relevant info wirelessly as well. The real story here, however, isn’t a novel use of an ESP32 chip, but rather out-of-the-box problem solving by using an atypical sensor to solve this problem. That’s not to say that you can’t ever use other sensors to directly monitor your garden and automate its health, though.
We will have all at some point seen a fascinating project online, only to find not enough information to really appreciate and understand it. Such a project came [Bill Meara]’s way over at the SolderSmoke podcast, and he was fortunately able to glean more from its creator. What [Tom] had made from junkbox parts was a fairly traditional analogue receiver for the 20m amateur band which would be quite an achievement in itself, but what makes it special is its use of an FPGA to augment the analogue tuning.
A traditional analogue radio has a local oscillator which is mixed with the signal from the antenna, and an intermediate frequency of the difference between oscillator and desired signal is filtered from the result and amplified. The oscillator on older receivers would have used a free running tuned circuit, while a newer device might use a phase-locked loop to derive a stable frequency from a crystal.
What [Tom]’s receiver does is take a free-running traditional receiver and use the FPGA as a helper. It has a frequency meter that drives the display, but it also uses the measured figure to adjust the oscillator and keep it on frequency. It has two modes; while tuning it’s a traditional analogue receiver, but when left alone the FPGA stops it drifting. We like it, it’s definitely a special project.
Radio control toys can be great fun to play with. However, at the bottom end of the market, sometimes you find you’ve bought something that just doesn’t work quite right. [saulemmetquinn] found that with a cheap RC helicopter, and set about re-engineering the design in Tinkercad.
The entire frame of the original helicopter was discarded, replaced with one made out of CAD-designed and 3D printed components. The end result is far lighter and less cumbersome than the original design, while also managing to look a lot more like an actual helicopter. It also served to correct some of the problems which [saulemmetquinn] stated made the original toy difficult to fly.
Assembling your own tiny helicopter motors and mechanisms would be quite difficult, and time consuming. [saulemmetquinn] was instead able to leverage the good parts of the original design, and build something better from that. It’s very much the essence of hacking, right there.
For readers that might not spend their free time watching spools of PLA slowly unwind, The Spaghetti Detective (TSD) is an open source project that aims to use computer vision and machine learning to identify when a 3D print has failed and resulted in a pile of plastic “spaghetti” on the build plate. Once users have installed the OctoPrint plugin, they need to point it to either a self-hosted server that’s running on a relatively powerful machine, or TSD’s paid cloud service that handles all the AI heavy lifting for a monthly fee.
Unfortunately, 73 of those cloud customers ended up getting a bit more than they bargained for when a configuration flub allowed strangers to take control of their printers. In a frank blog post, TSD founder Kenneth Jiang owns up to the August 19th mistake and explains exactly what happened, who was impacted, and how changes to the server-side code should prevent similar issues going forward.
TSD allows users to remotely manage and monitor their printers.
For the record, it appears no permanent damage was done, and everyone who was potentially impacted by this issue has been notified. There was a fairly narrow window of opportunity for anyone to stumble upon the issue in the first place, meaning any bad actors would have had to be particularly quick on their keyboards to come up with some nefarious plot to sabotage any printers connected to TSD. That said, one user took to Reddit to show off the physical warning their printer spit out; the apparent handiwork of a fellow customer that discovered the glitch on their own.
According to Jiang, the issue stemmed from how TSD associates printers and users. When the server sees multiple connections coming from the same public IP, it’s assumed they’re physically connected to the same local network. This allows the server to link the OctoPrint plugin running on a Raspberry Pi to the user’s phone or computer. But on the night in question, an incorrectly configured load-balancing system stopped passing the source IP addresses to the server. This made TSD believe all of the printers and users who connected during this time period were on the same LAN, allowing anyone to connect with whatever machine they wished.
New code pushed to the TSD repository limits how many devices can be associated with a single IP.
The mix-up only lasted about six hours, and so far, only the one user has actually reported their printer being remotely controlled by an outside party. After fixing the load-balancing configuration, the team also pushed an update to the TSD code which puts a cap on how many printers the server will associate with a given IP address. This seems like a reasonable enough precaution, though it’s not immediately obvious how this change would impact users who wish to add multiple printers to their account at the same time, such as in the case of a print farm.
While no doubt an embarrassing misstep for the team at The Spaghetti Detective, we can at least appreciate how swiftly they dealt with the issue and their transparency in bringing the flaw to light. This is also an excellent example of how open source allows the community to independently evaluate the fixes applied by the developer in response to a discovered flaw. Jiang says the team will be launching a full security audit of their own as well, so expect more changes getting pushed to the repository in the near future.
We were impressed with TSD when we first covered it back in 2019, and glad to see the project has flourished since we last checked in. Trust is difficult to gain and easy to lose, but we hope the team’s handling of this issue shows they’re on top of things and willing to do right by their community even if it means getting some egg on their face from time to time.
We love depth-sensing cameras and every neat hack they enabled, but this technological novelty has yet to break through to high volume commercial success. So it was sad but not surprising when CRN reported that Intel has decided to wind down their RealSense product line.
As of this writing, one of the better confirmations for this report can be found on the RealSense SDK GitHub repository README. The good news is that core depth-sensing RealSense products will continue business as usual for the foreseeable future, balanced by the bad news that some interesting offshoots (facial authentication, motion tracking) will be declared “End of Life” immediately and phased out over the next six months.
This information tells us while those living out on the bleeding edge will have to scramble, there is no immediate crisis for everyone else, whether they be researchers, hobbyists, or product planners. But this also means there will be no future RealSense cameras, kicking off many “What’s Next?” discussions in various communities. Like this thread on ROS (Robot Operating System) Discourse.
Three popular alternatives offer distinctly different tradeoffs. The “Been Around The Block” name is Occipital, with their more expensive Structure Pro sensor. The “Old Name, New Face” option is Microsoft Azure Kinect, the latest non-gaming-focused successor to the gaming peripheral that started it all. And let’s not forget OAK-D as the “New Kid On The Block” that started with a crowdfunding campaign and building an user community by doing things like holding contests. Each of these will appeal to a different niche, and we’ll keep our eye open in the future. Let’s see if any of them find the success that eluded the original Kinect, Google’s Tango, and now Intel’s RealSense.
Accessibility is one obvious approach to this challenge. But you can also consider the example of reference designs in datasheets. Manufacturers know you don’t want to re-invent the wheel to use their switch-mode power supply so they give you information on how to lay it out on the PCB and what parts to choose. Now take that idea and run with it. This could be a modular design that takes the wizardry out of building electronic projects. But it could just as easily be a aimed at the end user — perhaps lab equipment that’s normally expensive and requires expertise to operate but you’ve reimagined it to have most of that expertise built in.
Need some more help figuring out what this is all about? Let’s look at some of the projects that have already been entered. With devices all around us that have superb cameras and dazzling screens, [Timo] realized it wouldn’t take much to turn one into an inspection microscope, which is just what’s been done with nothing more than a 3D-printed stand and a desk lamp.
[Alain] put his electronics knowledge, and the availability of cheap modules, to great use for his non-verbal son. The PECS Communication Board has a grid of sixteen images, each is a button to act as input. He makes the point that tablet apps exist for this, but durability and cost are both issues that his approach helps address.
There are already a ton of other great entries for this round of the Hackaday Prize, but it wouldn’t be complete without yours. Ten will be chosen to receive $500 each and move on to the finals with a $25,000 grand prize on the line. Start your project right now on Hackaday.io and use the left sidebar drop down menu on your project page to enter it.
You have until Monday morning when the next round begins. Good luck!
