We often talk about the advantages of modular hardware here at Hackaday; the ability to just order a few parts online, hook them up with some jumper wires, and move onto the software side of things is a monumental time saver when it comes to prototyping. So anytime we see a new module that’s going to save us time and aggravation down the road, we get a bit excited.
Today we present the very slick I2CNavKey developed by [Saimon], a turn-key interface solution for your builds that can’t quite get away with a couple toggle switches. It not only gives you a four-way directional pad with center button, but a rotary “wheel” like on the old iPods. All of which you can access easily and with a minimum of wiring thanks to the wonders of I2C.
But even that might be selling the module short. This isn’t just a couple of buttons on a breakout board, the I2CNavKey is powered by its own PIC16F18345 microcontroller and features three configurable GPIOs with PWM support (perfect for an RGB LED) plus 256 bytes of onboard EEPROM storage.
[Saimon] has released the entire project as open source hardware for your hacking pleasure, but you can also get them as ready-to-use modules on Tindie for $18 USD [Editor’s Note: Because of a typo we originally we left the 1 out of the price]. Whether you’re a paying customer or not, you get access to the project’s absolutely phenomenal documentation, including a nearly 30 page manual that contains everything you’d ever want to know about the I2CNavKey and how to integrate it into your project. If all hardware was documented with this level of dedication, the world would be a much nicer place for folks like us.
There’s something enchanting about ancient tools and instruments. The idea that our forebears were able to fashion precision mechanisms with nothing but the simplest hand tools is fascinating. And watching someone recreate the feat, such as by building an astrolabe by hand, can be very appealing too.
The astrolabe is an ancient astronomical tool of incredible versatility, allowing the user to do everything from calculating when the sun will rise to predicting the positions of dozens of stars in the night sky. That it accomplishes all this with only a few moving parts makes it all the more fascinating. [Uri Tuchman] began the astrolabe build shown in the video below with only a few hand tools. He quickly had his fill of the manual fretsaw work, though, and whipped up a simple scroll saw powered by an old sewing machine foot treadle to speed up his work. The real treat though is the hand engraving, a skill that [Uri] has clearly mastered. We couldn’t help musing that a CNC router could do the same thing so much more quickly, but watching [Uri] do it was so much more satisfying. Everything about the build really makes a statement, from the contrasting brass and steel parts to the choice of complex Arabic script for the markings. [Uri] has another video that goes over astrolabe basics and his design process that’s well worth watching too.
While it’s nowhere near as complicated an instrument, this astrolabe puts us in the mood to watch the entire Clickspring clock build again. And [Chris] is working on his own ancient instrument build at the moment, recreating the Antikythera mechanism. We can’t wait to binge-watch that one too.
Our recent “Retrotechtacular” feature on an early 1970s dead-reckoning car navigation system stirred a memory of another pre-GPS solution for the question that had vexed the motoring public on road trips into unfamiliar areas for decades: “Where the heck are we?” In an age when the tattered remains of long-outdated paper roadmaps were often the best navigational aid a driver had, the dream of an in-dash scrolling map seemed like something Q would build for James Bond to destroy.
And yet, in the mid-1980s, just such a device was designed and made available to the public. Dubbed Etak, the system was simultaneously far ahead of its time and doomed to failure by the constellation of global positioning satellites being assembled overhead as it was being rolled out. Given the constraints it was operating under, Etak worked very well, and even managed to introduce some of the features of modern GPS that we take for granted, such as searching for services and businesses. Here’s a little bit about how the system came to be and how it worked.
Anyone old enough to have driven before the GPS era probably wonders, as we do, how anyone ever found anything. Navigation back then meant outdated paper maps, long detours because of missed turns, and the far too frequent stops at dingy gas stations for the humiliation of asking for directions. It took forever sometimes, and though we got where we were going, it always seemed like there had to be a better way.
Indeed there was, but instead of waiting for the future and a constellation of satellites to guide the way, some clever folks in the early 1970s had a go at dead reckoning systems for car navigation. The video below shows one, called Cassette Navigation, in action. It consisted of a controller mounted under the dash and a modified cassette player. Special tapes, with spoken turn-by-turn instructions recorded for a specific route, were used. Each step was separated from the next by a tone, the length of which encoded the distance the car would cover before the next step needed to be played. The controller was hooked to the speedometer cable, and when the distance traveled corresponded to the tone length, the next instruction was played. There’s a long list of problems with this method, not least of which is no choice in road tunes while using it, but given the limitations at the time, it was pretty ingenious.
Dead reckoning is better than nothing, but it’s a far cry from GPS navigation. If you’re still baffled by how that cloud of satellites points you to the nearest Waffle House at 3:00 AM, check out our GPS primer for the details.
The worst thing about walking around while trying to follow directions is that you have to keep looking down at them to get the next turn. At best, you’ll miss out on the scenery; at worst, you might walk into traffic.
Wouldn’t it be great if you didn’t have to look down? Yes it would, and with Walkity, there’s no need to look down. Walkity is a set of cuffs that slip on the backs of your shoes, pairs with your phone, and uses haptic feedback to tell you where to go. Each one has an Arduino Mini Pro, an NRF24L01 to talk to its mate, a Bluetooth module, a vibration motor, and what must be the thinnest, most flexible LiPo currently available on Earth. The specified cell is PGEB0083559, a 65 mAH cell that is 0.8 mm thick!
Your smartphone will vibrate in your pocket during naviation but our experience has been that of still not knowing which way to turn. Walkity’s feedback is simple and intuitive. The left cuff vibrates to indicate a left turn, right for right, and both vibrate when you reach your destination. Going the wrong way? Walkity will vibrate vigorously to let you know it’s time to pull over. It’s a great example of a an entry for the Human Computer Interface Challenge of the Hackaday Prize!
[Tom Scott] ran across an interesting visual effect created with Moiré patterns and used for guiding ships but we’re sure it can be adapted for hacks somewhere. Without the aid of any motors or LED animation, the image changes as the user views it from different angles. When viewed straight on, the user sees vertical lines, but from the left they see a right-pointing arrow and from the right, they see a left-pointing arrow. It’s used with shipping to guide ships. For example, one use would be to guide them to the center point of a bridge. When the pilots see straight, vertical lines then they know where to steer the ship.
US patent 4,629,325, Leading mark indicator, explains how it works and how to make one. Two screens are separated from each other. The one in front is vertical but the one behind is split in two and angled. It’s this angle which creates the slants of the arrows when viewed from the left or right. We had to convince ourselves that we understood it correctly and a quick test with two combs showed that we did. See below for the test in action as well as for [Tom’s] video of the real-world shipping one.
How does one go about programming a drone to fly itself through the real world to a location without crashing into something? This is a tough problem, made even tougher if you’re pushing speeds higher and high. But any article with “MIT” implies the problems being engineered are not trivial.
The folks over at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have put their considerable skill set to work in tackling this problem. And what they’ve come up with is (not surprisingly) quite clever: they’re embracing uncertainty.
Why Is Autonomous Navigation So Hard?
Suppose we task ourselves with building a robot that can insert a key into the ignition switch of a motor vehicle and start the engine, and could do so in roughly the same time-frame that a human could do — let’s say 10 seconds. It may not be an easy robot to create, but we can all agree that it is very doable. With foreknowledge of the coordinate information of the vehicle’s ignition switch relative to our robotic arm, we can place the key in the switch with 100% accuracy. But what if we wanted our robot to succeed in any car with a standard ignition switch?
Now the location of the ignition switch will vary slightly (and not so slightly) for each model of car. That means we’re going to have to deal with this in real time and develop our coordinate system on the fly. This would not be too much of an issue if we could slow down a little. But keeping the process limited to 10 seconds is extremely difficult, perhaps impossible. At some point, the amount of environment information and computation becomes so large that the task becomes digitally unwieldy.
This problem is analogous to autonomous navigation. The environment is always changing, so we need sensors to constantly monitor the state of the drone and its immediate surroundings. If the obstacles become too great, it creates another problem that lies in computational abilities… there is just too much information to process. The only solution is to slow the drone down. NanoMap is a new modeling method that breaks the artificial speed limit normally imposed with on-the-fly environment mapping.