Sometimes a successful project isn’t only about making sure all the electrons are in the right place at the right time, or building something that won’t collapse under its own weight. A lot of projects involve a fair amount of social engineering to be counted as a success, especially those that might result in arrest and incarceration if built as originally planned. Such projects are often referred to as “the fun ones.”
For the past few months, we’ve been following [Bitluni]’s DIY electric scooter build, which had been following the usual trajectory for these things – take a stock unpowered scooter, replace the rear wheel with a 250 W hub motor, add an ESC, battery, and throttle, and away you go. Things took a very interesting turn, however, when his street testing ran afoul of German law, which limits small electric vehicles to a yawn-inducing 6 kph. Unwilling to bore himself to death thus, [Bitluni] found a workaround: vehicles that are only assisted by an electric motor have a much more reasonable speed limit of 25 kph. So he added an Arduino with a gyro and accelerometer module and wrote a program to only power the wheel after the rider has kicked the scooter along a few times – no throttle needed. The motor stops after a bit, needing another push or two to kick it back on. A brake lever kills the motor, as does laying the scooter on its side. It’s quite a clever design, and while it might not keep the Polizei at bay, you can’t say he didn’t try.
If you are a lover of all-things remote-conteolled, it’s likely that you know a thing or two about controllers. You’ll have one or two of the things, both the familiar two-joystick type and the pistol-grip variety. But had you ever considered that there m ight be another means to do it? [Andrei] over at ELECTRONOOBS has posted a guide to a tilt-controlled RC car. It is a good example of how simple parts can be linked together to make something novel and entertaining, and a great starter project for an aspiring hacker.
An Arduino Nano reads from an accelerometer over an I2C bus, and sends commands over a wireless link, courtesy of a pair of HC-12 wireless modules. Another Nano mounted to the car decodes the commands, and uses a pair of H-bridges, which we’ve covered in detail, to control the motors.
The tutorial is well done, and includes details on the hardware and all the code you need to get rolling. Check out the build and demo video after the break.
Everyone remembers popping their first wheelie on a bike. It’s an exhilarating moment when you figure out just the right mechanics to get balanced over the rear axle for a few glorious seconds of being the coolest kid on the block. Then gravity takes over, and you either learn how to dismount the bike over the rear wheel, or more likely end up looking at the sky wondering how you got on the ground.
Had only this wheelie cheating device been available way back when, many of us could have avoided that ignominious fate. [Tom Stanton]’s quest for the perfect wheelie led him to the design, which is actually pretty simple. The basic idea is to apply the brakes automatically when the bike reaches the critical angle beyond which one dares not go. The brakes slow the bike, the front wheel comes down, and the brakes release to allow you to continue pumping along with the wheelie. The angle is read by an accelerometer hooked to an Arduino, and the rear brake lever is pulled by a hobby servo. We honestly thought the servo would have nowhere near the torque needed, but in fact it did a fine job. As with most of [Tom]’s build his design process had a lot of fits and starts, but that’s all part of the learning. Was it worth it? We’ll let [Tom] discuss that in the video, but suffice it to say that he never hit the pavement in his field testing, although he appeared to be wheelie-proficient going into the project.
The Raspberry Pi’s goal, at least while it was being designed and built, was to promote computer science education by making it easier to access a working computer. What its low price tag also enabled was a revolution in distributed computing projects (among other things). One of those projects is the Raspberry Shake, a seismograph tool which can record nearby earthquakes.
Of course, the project just uses the Pi as a cost-effective computing solution. It runs custom software, but if you want to set up your own seismograph then you’ll also need some additional hardware. There are different versions of the Raspberry Shake, the simplest using a single Geophone which is a coil and magnet. Vibrations are detected by sensing the electric signal generated by the magnet moving within the coil of wire. Other models increase the count to three Geophones, or add in MEMS accelerometers, you can easily whip one of these up on your own bench.
The entire setup will fit nicely on a coffee table as well, making it much smaller (and cheaper) than a comparable professional seismograph. Once all of the Raspberry Shakes around the world were networked together, it gives an accurate, real-time view of seismic activity anywhere you can imagine. If you’ve ever been interested in geology or just want to see where the latest earthquake was, check out their projects. But you don’t need even a Raspberry Pi to see where the earthquakes are, thanks to a Hackaday Prize entry all you need is a Twitter account.
[Carson] didn’t know how to use an accelerometer until he wired one up to a Teensy and put it all in a hat. The result is a joystick that will probably cause you neck problems if you play video games for very long. You can see a video of how the device came to be and how it works, below.
We liked the approach of building up the circuit and testing it before integrating it with the hat. He used a small breadboard with half the Teensy pins hanging off. That seems to work, although we’d be worried about something shorting or floating pins causing issues. Of course, if you drove the disconnected pins as outputs or inputs with pullups that might not be a big deal.
There’s a school of thought that says complexity has an inversely proportional relation to reliability. In other words, the smarter you try to make something, the more likely it is to end up failing for a dumb reason. As a totally random example: you’re trying to write up a post for a popular hacking blog, all the while yelling repeatedly for your Echo Dot to turn on the fan sitting three feet away from you. It’s plugged into a WeMo Smart Plug, so you can’t even reach over and turn it on manually. You just keep repeating the same thing over and over in the sweltering July heat, hoping your virtual assistant eventually gets the hint. You know, something like that. That exact scenario definitely has never happened to anyone in the employ of this website.
Now it should be said, [Julio] is not claiming to be the first person to discover that ultrasonic sound can confuse MEMS gyroscopes and accelerometers. At Black Hat 2017, a talk was given in which a “Sonic Gun” was used to do things like knock over self-balancing robots using the same principle. The researchers were also able to confuse a DJI Phantom drone, showing that the technique has the potential to be weaponized in the real-world.
Anyone who slings code for a living knows the feeling all too well: your code is running fine and dandy one minute, and the next minute is throwing exceptions. You’d swear on a stack of O’Reilly books that you didn’t change anything, but your program stubbornly refuses to agree. Stumped, you turn to the only one who understands you and pour your heart out to a little yellow rubber duck.
When it comes to debugging tools, this digital replacement for the duck on your desk might be even more helpful. Rubber duck decoding, where actually explaining aloud to an inanimate object how you think the code should run, really works. It’s basically a way to get you to see the mistake you made by explaining it to yourself; the duck or whatever – personally, I use a stuffed pig– is just along for the ride. [platisd] took the idea a step further and made his debugging buddy, which he dubs the “Dialectic Ball,” in the form of a Magic 8-Ball fortune teller. A 3D-printed shell has an ATtiny84, an accelerometer, and an LCD screen. To use it, you state your problem, shake it, and read the random suggestion that pops up. The list has some obvious suggestions, like adding diagnostic print statements or refactoring. Some tips are more personal, like talking to your local guru or getting a cup of coffee to get things going again. The list can be customized for your way of thinking. If nothing else, it’ll be a conversation piece on your desk.