In the winter, I hatched a vague plan to learn some of the modern unmanned aerial vehicle tech. Everybody needs an autonomous vehicle, and we’ve got some good flying fields within walking distance, so it seemed like it could work. Being me, that meant buying the cheapest gear that could possibly work, building up the plane by myself, and generally figuring out as much as possible along the way. I learn more by making my own mistakes anyway. Sounds like a good summer project.
Fast-forward to August, and the plane is built, controller installed, and I’ve spent most of the last month trying to make them work well together. (The firmware expects a plane with ailerons, and mine doesn’t have them, but apparently I’d rather tweak PID values than simply add a couple wing servos.) But it’s working well enough that it’s launching, flying autonomous waypoint missions, and coming home without any intervention. So, mission accomplished, right?
Nope. When I’m enjoying a project, I have a way of moving the goalposts on myself. I mean, I don’t really want to be done anyway. When a friend asked me a couple weeks ago what I was planning to do with the plane, I said “take nice aerial videos of that farm over there.” Now I see flight opportunities everywhere, and need to work on my skills. The plane needed an OLED display. It probably still needs Bluetooth for local configuration as well. Maybe a better long-range data link…
This is creeping featurism and moving-the-goalposts in the best of ways. And if this were a project with a deadline, or one that I weren’t simply enjoying, it would be a problem. Instead, having relatively low-key goals, meeting them, and letting them inspire me to set the next ones has been a blast. It makes me think of Donald Papp’s great article on creating hacking “win” projects. There he suggests creating simple goals to keep yourself inspired. I don’t think I could have planned out an “optimal” set of goals to begin with — I’ve learned too much along the way that the next goal isn’t obvious until I know what new capabilities I have. Creeping is the only way.
What about you? Do you plan your hobby projects completely in advance? Not at all? Or do you have some kind of hybrid, moving-the-goalposts sort of strategy?
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
The Unix operating system has been around for decades, and it and its lookalikes (mainly Linux) are a critical part of the computing world. Apple’s operating system, macOS, is Unix-based, as are Solaris and BSD. Even if you’ve never directly used one of these operating systems, at least two-thirds of all websites are served by Unix or Unix-like software. And, if you’ve ever picked up a smart phone, chances are it was running either a Unix variant or the Linux-driven Android. The core reason that Unix has been so ubiquitous isn’t its accessibility, or cost, or user interface design, although these things helped. The root cause of its success is its design philosophy.
Good design is crucial for success. Whether that’s good design of a piece of software, infrastructure like a railroad or power grid, or even something relatively simple like a flag, without good design your project is essentially doomed. Although you might be able to build a workable one-off electronics project that’s a rat’s nest of wires, or a prototype of something that gets the job done but isn’t user-friendly or scalable, for a large-scale project a set of good design principles from the start is key.
Rain barrels are a great way to go green, as long as your neighborhood doesn’t frown upon them. [NikonUser]’s barrel sits up high enough that he has to climb up on an old BBQ and half-dangle from the pipe to check the water level, all the while at the risk of encountering Australian spiders.
Everything is contained in a water-resistant box and driven by an Arduino Pro. The box is mounted on a piece of scrap lumber that lays across the top of the barrel. This allows the HC-SR04’s eyes to peer over the edge and send pings toward the bottom. It also helps to keep the readings consistent and the electronics from taking a swim.
Operation is simple: [NikonUser] reaches up, sets the plank across the barrel, and pushes the momentary. This activates the Arduino, which prompts the HC-SR04 to take several readings. The code averages these readings, does a little math, and displays the percentage of water remaining in the barrel.