Elliot Williams and Mike Szczys wish Hackaday a happy fifteenth birthday! We also jump into a few vulns found (and fixed… ish) in the WiFi stack of ESP32/ESP8266 chips, try to get to the bottom of improved search for 3D printable CAD models, and drool over some really cool RC cars that add realism to head-to-head online racing. We look at the machining masterpiece that is a really huge SCARA arm drawbot, ask why Hydrogen cars haven’t been seeing the kind of sunlight that fully electric vehicles do, and give a big nod of approval to a guide on building your own custom USB cables.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Conceptually, cooking on a grill is simple enough: just crank up the flames and leave the food on long enough for it to cook through, but not so long that it turns into an inedible ember. But when smoking, the goal is actually to prevent flames entirely; the food is cooked by the circulation of hot gasses generated by smoldering wood. If you want a well-cooked and flavorful meal, you’ll need the patience and dedication to manually keep the fuel and air balanced inside the smoker for hours on end.
Or in the case of the Smokey Mc Smokerson, you just let the electronics handle all the hard stuff while you go watch TV. Powered by the Raspberry Pi Zero and a custom control board, this open source smoker offers high-end capabilities on a DIY budget. Granted you’ll still need to add the fuel of your choice the old fashioned way, but with automatic air flow control and temperature monitoring, it greatly reduces the amount of fiddly work required to get that perfect smoke.
[HackersHub] has been working on Smokey Mc Smokerson for a few months now, and are getting very close to building the first complete prototype. The initial version of the software is complete, and the classy black PCBs have recently arrived. Some simulations have been performed to get an idea of how the smoke will circulate inside of the smoker itself, built from a 55 gallon drum, but technically the controller is a stand-alone device. If you’re willing to makes the tweaks necessary, the controller could certainly be retrofitted to commercially available smoker instead.
Ultimately, this project boils down to tossing a bunch of temperature sensors at the problem. The software developed by [HackersHub] takes the data collected by the five MAX6675 thermocouples and uses it to determine when to inject more air into the chamber using a PWM-controlled fan at the bottom of the smoker. As an added bonus, all those temperature sensors give the user plenty of pretty data points to look at in the companion smartphone application.
It is an old movie trope: a robot grips something and accidentally crushes it with its super robot strength. A little feedback goes a long way, of course, but futuristic robots may also want to employ soft grippers. [Jessica] shows how to build soft grippers made of several cast fingers. The fingers are cast from Ecoflex 00-50, and use air pressure.
A 3D-printed mold is used to cast the Ecoflex fingers, which are only workable for 18 minutes after mixing, so it’s necessary to work fast and have everything ready before you start.
These days, it’s common among us hackers to load a stepper motor with forces in-line with their shaft–especially when we couple them to leadscrews or worm gears. Unfortunately, steppers aren’t really intended for this sort of loading, and doing so with high forces can destroy the motor. Fear not, though. If you find yourself in this situation, [Voind Robot] has the solution for you with a dead-simple-yet-dead-effective upgrade to get your steppers tackling axial loads without issue.
In [Voind Robot’s] case, they started with a worm-gear-drive on a robot arm. In their circumstances, moving the arm could put tremendous axial loads onto the stepper shaft through the worm–as much as 30 Newtons. Such loads could easily destroy the internal stepper motor bearings in a short time, so they opted for some double-sided reinforcement. To alleviate the problem, the introduced two thrust bearings, one on either side of the shaft. These thrust bearings do the work of redirecting the force off the shaft and directly onto the motor casing, a much more rigid place to apply such loads.
This trick is dead simple, and it’s actually over five years old. Nevertheless, it’s still incredibly relevant today for any 3D printer builder who’s considering coupling a leadscrew to a stepper motor for their Z-axis. There, a single thrust bearing could take out any axial play and lead to an overall rigid build. We love simple machine-design nuggets of wisdom like these. If you’re looking for more printer-design tricks, look no further than [Moritz’s] Workhorse Printer article.
Who wouldn’t want a robot that can fetch them a glass of water? [Saral Tayal] didn’t just think that, he jumped right in and built his own personal assistant robot. This isn’t just some remote-controlled rover though. The robot actually listens to his voice and recognizes his face.
The body of the robot is the common “Rover 5” platform, to which [Saral] added a number of 3D printed parts. A forklift like sled gives the robot the ability to pick things up. Some of the parts are more about form than function – [Saral] loves NASA’s Spirit and Opportunity Mars rovers, so he added some simulated solar cells and other greebles.
The Logitech webcam up front is very functional — images are fed to machine learning models, while audio is processed to listen for commands. This robot can find and pick up 90 unique objects.
The robot’s brains are a Raspberry Pi. It uses TensorFlow for object recognition. Some of the models [Saral] is using are pretty large – so big that the Pi could only manage a couple of frames per second at 100% CPU utilization. A Google Coral coprocessor sped things up quite a bit, while only using about 30% of the Pi’s processor.
It takes several motors to control to robot’s tracks and sled. This is handled by two Roboclaw motor controllers which themselves are commanded by the Pi.
We’ve seen quite a few mobile robot rovers over the years, but [Saral’s] ‘bot is one of the most functional designs out there. Even better is the fact that it is completely open source. You can find the code and 3D models on his GitHub repo.
Check out a video of the personal assistant rover in action after the break.
Scarcity on the Internet is the siren song of bot writers. Maybe you’ve lost an eBay bid in the last milliseconds, or missed out on a hacker con when tickets sold out in under a minute — your corporeal self has been outperformed by a bot. But maybe you didn’t know bots are on a buying frenzy in the hyped-up world of fashion. From limited-run sneakers to anything with the word Supreme printed on it, people who will not accept any substitute in wearing the rarest and most sought after are turning to resellers who use bots to snag unobtanium items and profit on the secondary market.
At DEF CON 27 [FinalPhoenix] took the stage to share her adventures in writing bots and uncovering a world that buys and sells purchasing automation, forming groups much like cryptocurrency mining pools to generate leads on when the latest fashion is about to drop. This is no small market either. If your bots are leet enough, you can make a ton of cash. Let’s take a look at what it takes to write a bot, and at the bots-for-sale economy that has grown up around these concepts.
The internet is built with bots in mind and we have Google to thank for this. Their major innovation was moving us off of a curated internet to one that is machine crawled. Everyone wants good Google juice and that means building a site that is friendly to the Google bots that crawl and index the internet. This makes automation for your own purposes quite a bit easier. Namely, the monitor-bots that are used to detect when a retailer has the latest in stock. [FinalPhoenix] demonstrated a simple script that grabs the XML site map, parsing it for newly in-stock items, flagging them when found. But here’s the killer — if your monitor bot is a good one, you can turn it into a discord channel and sell subscriptions to others playing the reseller game, to the tune of $15-30 a month per subscriber.
Example slide of code used in a web-based buy-bot
Once your bot reports stock, the race is on to buy it before anyone else can. For this, you could use the APIs of the site, but that’s time-consuming and a lot easier for retailers to detect and block bot usage. For this part of her botting tools [FinalPhoenix] likes to use web-based bots that go through a browser framework like Chromium and allow obfuscation techniques like scrolling, clicking other items, random pauses, and other simple-minded actions that make your bot appear to be only human. In the examples for this talk, the Puppeteer framework was used for this purpose. In the end, the main role of this part of the bot is to use a verified account to complete the purchase as fast as robotically possible, which is why they’re called buy-bots. Retailers do have some tricks to combat these web-based attacks like adding secret keys in the DOM that need to be sent with the next post, but these are easy to discover and incorporate into the scripts.
This raises up another interesting part of the scheme, the verified accounts. For the best chance at profit, you need multiple accounts, each used just one time to avoid your buy-bot being detected by the retailer. For this, [FinalPHoenix] turns to services that sell accounts in packages of 500-10,000 and cost around just $5-10 per batch.
But wait, here’s where it gets really wild as recursion takes hold. Yes, these buy-bots are for sale (from sites like AIO Bot and usually around $300-1500), but they’re sold in limited quantities so that it’s harder for retailers to notice and take countermeasures. Just like how the clothing was limited release and incentivized bots-wielding resellers to enter the market, there is a secondary market for the bots themselves. [FinalPhoenix] reports that reselling one of these bots can yield $1000-1500 in profit. The same principles apply, and so what we’ve ended up with is bots buying bots to buy clothes. Who knows how many levels of bot-bot transactions there are, but it certainly feels like turtles all the way down.
Bot-based high-speed trading is the real way to make major bank on the securities market. Your average hacker is shut out of that “legitimate” business, but any enterprising programmer has the option of automating whichever reseller market they find most interesting. This breaks the public trust in commerce — buying quality products from a seller connected to their production for a reasonable price. If frustrates the manufacturer, alienates the consumer, but there appears to be little in place preventing it.
Robotics is hard, maybe not quite as difficult as astrophysics or understanding human relationships, but designing a competition winning bot from scratch was never going to be easy. Ok, so [Paul Bupe, Jr’s] robot, named ‘Goose’, did not quite win the competition, but we’re very interested to learn what golden eggs it might lay in the aftermath.
The mechanics of the bot is based on a fairly standard dual tracked drive system that makes controlling a turn much easier than if it used wheels. Why make life more difficult than it is already? But what we’re really interested in is the design of the control system and the rationale behind those design choices.
The diagram on the left might look complicated, but essentially the system is based on two ‘brains’, the Teensy microcontroller (MCU) and a Raspberry Pi, though most of the grind is performed by the MCU. Running at 96 MHz, the MCU is fast enough to process data from the encoders and IMU in real time, thus enabling the bot to respond quickly and smoothly to sensors. More complicated and ‘heavier’ tasks such as LIDAR and computer vision (CV) are performed on the Pi, which runs ‘Robot operating system’ (ROS), communicating with the MCU by means of a couple of ‘nodes’.
The competition itself dictated that the bot should travel in large circles within the walls of a large box, whilst avoiding particular objects. Obviously, GPS or any other form of dead reckoning was not going to keep the machine on track so it relied heavily on ‘LiDAR point cloud data’ to effectively pinpoint the location of the robot at all times. Now we really get to the crux of the design, where all the available sensors are combined and fed into a ‘particle filter algorithm’:
What we particularly love about this project is how clearly everything is explained, without too many fancy terms or acronyms. [Paul Bupe, Jr] has obviously taken the time to reduce the overall complexity to more manageable concepts that encourage us to explore further. Maybe [Paul] himself might have the time to produce individual tutorials for each system of the robot?
We could well be reading far too much into the name of the robot, ‘Goose’ being Captain Marvel’s bazaar ‘trans-species’ cat that ends up laying a whole load of eggs. But could this robot help reach a de-facto standard for small robots?
We’ve seen other competition robots on Hackaday, and hope to see a whole lot more!
