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.
When you think of world-changing devices, you usually don’t think of the washing machine. However, making laundry manageable changed not only how we dress but how much time people spent getting their clothes clean. So complaining about how laborious our laundry is today would make someone from the 1800s laugh. Still, we all hate the laundry and [Andrew Dupont], in particular, hates having to check on the machine to see if it is done. So he made Laundry Spy.
How do you sense when the machine — either a washer or a dryer — is done? [Andrew] thought about sensing current but didn’t want to mess with house current. His machines don’t have LED indicators, so using a light sensor wasn’t going to work either. However, an accelerometer can detect vibrations in the machine and most washers and dryers vibrate plenty while they are running.
The four-part build log shows how he took an ESP8266 and made it sense when the washer and dryer were done so it could text his cell phone. He’d already done a similar project with an Adafruit HUZZAH. But he wanted to build in some new ideas and currently likes working with NodeMCU. While he was at it he upgraded the motion sensor to an LIS3DH which was cheaper than the original sensor.
[Andrew] already runs Node – RED on a Raspberry Pi, so incorporating this project with his system was a snap. Of course, you could adapt the approach to lots of other things, as well. The device produces MQTT messages and Node – RED subscribes to them. The Pushover handles the text messaging. Node – RED has a graphical workflow that makes integrating all the pieces very intuitive. Here’s the high-level workflow:
You might wonder why he didn’t just have the ESP8266 talk directly to Pushover. That is possible, of course, but in part 2, [Andrew] enumerates some good reasons for his design. He wants to decouple components in the system for easier future upgrades. And MQTT is simple to publish on the sensor side of things compared to API calls which are handled by the Raspberry Pi for now.
We love to hack IKEA products, marvel at Raspberry Pi creations, and bask in the glow of video projection. [Nord Projects] combined these favorite things of ours into Lantern, a name as minimalist as the IKEA lamp it uses. But the result is nearly magic.
The key component in this build is a compact laser-illuminated video projector whose image is always in focus. Lantern’s primary user interface is moving the lamp around to switch between different channels of information projected on different surfaces. It would be a hassle if the user had to refocus after every move, but the focus-free laser projector eliminates that friction.
A user physically changing the lamp’s orientation is detected by Lantern’s software via an accelerometer. Certain channels project an information overlay on top of a real world object. Rather than expecting its human user to perform precise alignment, Lantern gets feedback from a Raspberry Pi camera to position the overlay.
Speaking of software, Lantern as presented by [Nord Projects] is a showcase project under Google’s Android Things umbrella that we’ve mentioned before. But there is nothing tying the hardware directly to Google. Since the project is open source with information on Hackster.io and GitHub, the choice is yours. Build one with Google as they did, or write your own software to tie into a different infrastructure (MQTT?), or a standalone unit with no connectivity at all.