[Matthiew] needed to create a system that would allow a computer to read braille. An electromechanical system would be annoying to develop and would require many hardware iterations as the system [Matthew] is developing evolves. Instead, he came up with a much better solution using a webcam and OpenCV that still gets 100% accuracy.
Instead of using a camera to look for raised or lowered pins in this mechanical braille display, [Matthiew] is using OpenCV to detect the shadows. This requires calibrating the camera to the correct angle, or in OpenCV terms, pose.
After looking at the OpenCV tutorials, [Matthiew] found a demo that undistorts an image of a chess board. Using this same technique, he used fiducials from the ARTag project to correctly calibrate an image of his mechanical braille pins.
As for why [Matthiew] went through all the trouble to get a computer to read braille – something that doesn’t make a whole lot of sense if you think about it – he’s building a braille eBook reader, something that just screams awesome mechanical design. We’d be interested in seeing some more info on that project as well.
For something that’s used for such banal transactions like buying drugs and sending the Jamaican bobsled team to the Olympics, cryptocurrencies such as Bitcoin are actually very impressive pieces of software. It’s a very ingenious solution to the Two Generals Problem, and the fact it made a few Bitcoin early adopters very, very rich doesn’t hurt either. [Ken Shirriff] decided to take a look at the Bitcoin protocol by creating a Bitcoin address and transferring a small amount of bitcoin to that address, manually. It’s a great look at how the Bitcoin protocol actually works, and how ingenious this protocol actually is.
[Ken]’s first task was to create a Bitcoin address. This is a 256-bit private key is the basis for the Bitcoin wallet private key (after being encoded as ASCII characters), and as the 512-bit public key (after being sent through an elliptic curve algorithm). The 512-bit public key is then hashed with SHA-256 and RIPEM 160 to generate the 160-bit public key hash and the Bitcoin address.
After creating a bitcoin address and wallet, [Ken] set out on manually creating a transaction. The idea was to buy a few cents (USD) from Coinbase and send them to his manually created address. This involved creating a transaction according to the Bitcoin spec and signing the transaction. Signing each Bitcoin transaction is the key to Bitcoin’s security, and is done with a small bit of code written in the Bitcoin scripting language.
With everything written in Python, [Ken] was ready to send his transaction off into the Bitcoin network. This was done by finding a few peers on the Bitcoin network and sending off a few packets. After a little bit of mining on the network, [Ken]’s transaction went through, confirmed by a deposit into his Bitcoin wallet.
It’s an awesome writeup and impressive achievement to manually send a few Bitcoins from one wallet to another. More impressively, [Ken] provided some amazing insight into how the Bitcoin protocol works, and how much work went into its creation.
The International Obfuscated C Contest – the contest to create the most useful, useless, or unique program in absolutely unreadable C code – has just posted the winners of the 2013 contest.
Of the entries of note, a few really stand out. The pic at the top of this post, for instance, comes courtesy of this submission. It’s an iterative ray tracer stuck inside an infinite loop that, when left running overnight, is able to produce amazing renders.
An IOCCC contest wouldn’t be complete without some ASCII art C code, and this entry fits the bill. It’s a Tetris painting tool that creates images made out of tetronomoes. Each image is built up one line at a time from the bottom up, using Tetris’ lack of physics to create a picture out of un-cleared lines.
One of the most impressive entries for this (last?) year’s contest is a tiny 8086 PC emulator/virtual machine written in only 4043 bytes of code. It’s a fully functional 80s-era PC emulator that can run vintage copies of AutoCAD, Windows, Lotus 1-2-3, and SimCity.
All the submissions are awesome, but like any IOCCC contest, there aren’t actually any winners. Or they’re all winners. The Obfuscated rules aren’t very clear in that regard.
The lowly Arduino, an 8-bit AVR microcontroller with a pitiful amount of RAM, terribly small Flash storage space, and effectively no peripherals to speak of, has better speech recognition capabilities than your Android or iDevice. Eighty percent accuracy, compared to Siri’s sixty.Here’s the video to prove it.
This uSpeech library created by [Arjo Chakravarty]
uses a Goertzel algorithm to turn input from a microphone connected to one of the Arduino’s analog pins into phonemes. From there, it’s relatively easy to turn these captured phonemes into function calls for lighting a LED, turning a servo, or even replicating the Siri, the modern-day version of the Microsoft paperclip.
There is one caveat for the uSpeech library: it will only respond to predefined phrases and not normal speech. Still, that’s an extremely impressive accomplishment for a simple microcontroller.
This isn’t the first time we’ve seen [Arjo]’s uSpeech library, but it is the first time we’ve seen it in action. When this was posted months and months ago, [Arjo] was behind the Great Firewall of China and couldn’t post a proper demo. Since this the uSpeech library is a spectacular achievement we asked for a few videos showing off a few applications. No one made the effort, so [Arjo] decided to make use of his new VPN and show off his work to the world.
Continue reading “An Arduino With Better Speech Recognition Than Siri”
[Ralph] has been working on an extraordinarily tiny bootloader for the ATtiny85, and although coding in assembly does have some merits in this regard, writing in C and using AVR Libc is so much more convenient. Through his trials of slimming down pieces of code to the bare minimum, he’s found a few ways to easily trim a few bytes off code compiled with AVR-GCC.
To test his ideas out, [Ralph] first coded up a short program that reads the ATtiny85’s internal temperature sensor. Dissassembling the code, he found the a jump to a function called __ctors_end: before the jump to main. According to the ATtiny85 datasheet, this call sets the IO registers to their initial values. These initial values are 0, so that’s 16 bytes that can be saved. This function also sets the stack pointer to its initial value, so another 16 bytes can be optimized out.
If you’re not using interrupts on an ATtiny, you can get rid of 30 bytes of code by getting rid of the interrupt vector table. In the end, [Ralph] was able to take a 274 byte program and trim it down to 190 bytes. Compared to the 8k of Flash on the ‘tiny85, it’s a small amount saved, but if you’re banging your head against the limitations of this micro’s storage, this might be a good place to start.
Now if you want to hear some stories about optimizing code you’ve got to check out the Once Upon Atari documentary. They spent months hand optimizing code to make it fit on the cartridges.
With WiFi, Wonder Trade, and new Pokemon that are freakin’ keys, you’d think the latest generation of everyone’s reason to own a Nintendo portable is where all the action is, right? Apparently not, because Pokemon Blue just became a development tool for the Game Boy.
Despite all notions of sanity, this isn’t the first time we’ve seen someone program a Game Boy from inside a first generation Pokemon game. Around this time last year, [bortreb] posted a tool assisted run that deposited and threw away in-game items to write to the Game Boy’s RAM. Using this method, [bortreb] was able to craft a chiptune version of the My Little Pony theme inside Pokemon Yellow.
A year later, [TheZZAZZGlitch] has gone above and beyond what [bortreb] did. Instead of a tool assisted run, [ZZAZZ]’s hack can be done manually on a real Game Boy. This trick works by using an underflow glitch to obtain item ‘8F’ in the player’s inventory. Here’s a great tutorial for doing that. With this 8F item, a few items can be tossed and a ‘programming’ mode is activated where code can be written to RAM by walking to an X Y position on the map, using the 8F item, and writing a program byte by byte.
The maximum amount of code that can be written to the Game Boy RAM is 254 bytes, just large enough for [TheZZAZZGlitch] to write a very, very simple version of Akranoid, Breakout, or one-player Pong. Not much, but very, very impressive.
Video of [ZZAZZ] ‘jailbreaking’ his copy of Pokemon Blue available below.
Continue reading “Pokemon Blue Becomes An IDE”
Have you ever thought a particular project could be better if you could just control the file access directly? [Stavros Korokithakis] did, specifically for a backup program he was working on. What followed was the realization that writing a FUSE filesystem, particularly in Python, isn’t as complicated as it may seem. Really, through the power of open source, the heavy lifting has already been done for us. If you’d like to try it yourself, you’ll need to install fusepy. From that point, you simply need to define the filesystem methods you will be using.
Python isn’t going to win any speed contests in the filesystem space, but that isn’t really the point. Using this technology opens up a huge opportunity for new ways of accessing data. If you let your mind wander, you can conceive of encrypted filesystems, seamless remote data access, new key-value storage designs, etc. Perhaps even more interesting is the idea of using Python to communicate with a physical device… maybe a proc filesystem to keep track of your robot telemetry? We’d love to hear your ideas in the comments.
We had success using [Stavros’] example script on Linux and OSX. (Fair warning if you’re on a Mac, the pip version of fusepy seems to be linked against fuse4x rather than OSXFUSE, but once you’ve got the prerequisites installed, you’re golden.) We didn’t have a Windows machine to test. Can anyone confirm if the same is possible there?