Apex Minecraft hosting recently held a scholarship competition. The person who sent in the best essay would win a $2,000 scholarship. The winning essay starts, “Five years ago, at age 13, I built an entire computer from scratch. Assembled from basic components: wires, torches, repeaters, pistons, and blocks, it was capable of rendering images to a display, multiplying and dividing numbers, and even calculating square roots.” I had to read it twice before it clicked that he was talking about a computer built entirely in a fictional universe.
It’s no wonder that he’s now a freshman at college, pursuing a degree in computer engineering. After reading this, I started to reminisce. The first computer I ever had access to was my mother’s laptop. It had an install of QBASIC on it, and I remember using it to make a few text based games. Later on when we got our first family computer I remember spending hours getting no better at video game programming using QBASIC.
It went on and on. I remember doing AI for video games in DarkBasic. I remember doing physics and collisions. Eventually I found my way to html, then php, to make websites about games (which are too terrible to share with you). So when the time came to program robots I was absolutely fearless. It just seemed like such a natural extension of what I already knew that it never occurred to me to be thankful for the time I spent trying to make my own simple little games until much later.
In the end I am still occasionally making little forays into game programming when I want to learn a new language or get back up to speed. It never occurred to me that perhaps this was just the way I’ve always learned a language.
Later on in the winner’s essay he goes on to describe his minecraft community. They taught new players. They taught themselves. They hung out and became friends. The writer gained a sense of self as a user of computers, a teacher of skills, a good member of a community, and a solver of problems. Unlike some of his classmates he won’t go to college and have to learn if he’s good enough. He’ll already know. All it took was a silly block based game.
Did any of you have seemingly frivolous endeavors show up as a foundation for your life and learning far into the future? Tell in the comments below how this ended up shaping your career.
For all the complexity involved in driving, it becomes second nature to respond to pedestrians, environmental conditions, even the basic rules of the road. When it comes to AI, teaching machine learning algorithms how to drive in a virtual world makes sense when the real one is packed full of squishy humans and other potential catastrophes. So, why not use the wildly successful virtual world of Grand Theft Auto V to teach machine learning programs to operate a vehicle?
The hard problem with this approach is getting a large enough sample for the machine learning to be viable. The idea is this: the virtual world provides a far more efficient solution to supplying enough data to these programs compared to the time-consuming task of annotating object data from real-world images. In addition to scaling up the amount of data, researchers can manipulate weather, traffic, pedestrians and more to create complex conditions with which to train AI.
It’s pretty easy to teach the “rules of the road” — we do with 16-year-olds all the time. But those earliest drivers have already spent a lifetime observing the real world and watching parents drive. The virtual world inside GTA V is fantastically realistic. Humans are great pattern recognizers and fickle gamers would cry foul at anything that doesn’t analog real life. What we’re left with is a near-perfect source of test cases for machine learning to be applied to the hard part of self-drive: understanding the vastly variable world every vehicle encounters.
A team of researchers from Intel Labs and Darmstadt University in Germany created a program that automatically indexes the virtual world (as seen above), creating useful data for a machine learning program to consume. This isn’t a complete substitute for real-world experience mind you, but the freedom to make a few mistakes before putting an AI behind the wheel of a vehicle has the potential to speed up development of autonomous vehicles. Read the paper the team published Playing for Data: Ground Truth from Video Games.
For beginners, diode types can sometimes be a bit of mental gymnastics. If all it does is act like a magic pixie check valve, why are there so many kinds? Schottky diodes are typically hard to mentally set apart from the standard when described by a data sheet. Zener diodes can be downright baffling for beginners, especially when mistakenly thrown in a circuit in place of a regular 1N4001. [Afrotechmods] put together a great video explaining their difference and use cases.
In both videos he does an excellent job of describing the pros and cons while setting up experiments to exhibit each. For the Schottky it’s the faster switching and lower voltage drop. For Zener it’s less about the cons and more about exploiting its strange configuration for voltage clamps, regulators, and making expensive guitars sound bad with audio distortion circuits.
He finishes both videos with good design tips for selecting and using the parts as a burgeoning circuit designer. Diode data sheets should be less of a mystery afterwards.
We all know that the little black globs on electronics has a semiconductor of some sort hiding beneath, but the process is one that’s not really explored much in the home shop. The basic story being that, for various reasons , there is no cheaper way to get a chip on a board than to use the aptly named chip-on-board or COB process. Without the expense of encapsulating the raw chunk of etched and plated silicon, the semiconductor retailer can sell the chip for pennies. It’s also a great way to accept delivery of custom silicon or place a grouping of chips closely together while maintaining a cheap, reliable, and low-profile package.
As SparkFun reveals, the story begins with a tray of silicon wafers. A person epoxies the wafer with some conductive glue to its place on the board. Surprisingly, alignment isn’t critical. The epoxy dries and then the circuit board is taken to a, “semi-automatic thermosonic wire bonding machine,” and slotted into a fixture at its base. The awesomely named machine needs the operator to find the center of the first two pads to be bonded with wire. Using this information it quickly bonds the pads on the silicon wafer to the board — a process you’ll find satisfying in the clip below.
The final step is to place the familiar black blob of epoxy over the assembly and bake the board at the temperature the recipe in the datasheet demands. It’s a common manufacturing process that saves more money than coloring a multimeter anything other than yellow.
In the show Full Metal Alchemist, there’s a city called Rush Valley whose main and only business are the high performance prostheses called Automail. Engineers roam the street in Rush Valley; the best have their own shop like that of the high-end clothiers in Saville Row. Of course; it’s all fantasy set in a slightly ridiculous Japanese cartoon, but while walking through this year’s Maker Faire I began to wonder if is a future that may come to be.
The problem with prosthetics is the sheer variety of injuries, body types, and solutions needed. If an injury is an inch higher or an inch lower it can have a big effect on how a prosthetic will interact with the limb. If the skin is damaged or the nerves no longer function a different type of prosthesis will be needed. Some prostheses are to replace a lost limb, others are to assist an ailing body in order to return it to normal function. More than a few are simply temporary aides to help the body along in its healing efforts. Unfortunately, this means that it’s often the case that larger companies only sell the prostheses people are most likely to need; the rarer cases are often left without a solution.
However, we see hackers stepping up and not just working on the problems, but solving them. One of our semifinalists last year, openbionics, inspired one of the projects we’ll be talking about later. There are robotic legs. We met a guy at MRRF who has been 3D printing hands for his son from the E-nable project.
Along these lines, we saw two really cool projects at Maker Faire this year: The first is the Motor-Assistive Glove, or MAG. MAG is designed to help people with Peripheral Neropathy regain some use of their hands while they go through the lengthy road to recovery. Perhipheral Neuropathy is a disease, usually resulting from diabetes, toxin exposure, or infection, where the nerves are damaged in such a way that typically the hands and feet are no longer mobile or feel sensation in a useful way. Once the disease is in full swing, a previously able person will find themselves unable to do simple things like hold a can of soda or grasp a doorknob firmly enough to open it.
We had a chance to interview one of the members of the MAG team, [Victor Ardulov], which you can see in the following video. [Victor] and his group started a research project at the University of Santa Cruz to develop the Motor-Assistive Glove. The concept behind it is simple. People with Peripheral Neuropathy typically have some movement in their hands, but no strength. The MAG has some pressure sensors at the tips of the fingers. When the user puts pressure on the pad; the glove closes that finger. When the pressure is off; the glove opens. The concept is simple, but the path to something usable is a long one.
My heyday in programming was about five years ago, and I’ve really let my skills fade. I started finding myself making excuses for my lack of ability. I’d tackle harder ways to work around problems just so I wouldn’t have to code. Worst of all, I’d find myself shelving projects because I no longer enjoyed coding enough to do that portion. So I decided to put in the time and get back up to speed.
Normally, I’d get back into programming out of necessity. I’d go on a coding binge, read a lot of documentation, and cut and paste a lot of code. It works, but I’d end up with a really mixed understanding of what I did to get the working code. This time I wanted to structure my learning so I’d end up with a more, well, structured understanding.
However, there’s a problem. Programming books are universally boring. I own a really big pile of them, and that’s after I gave a bunch away. It’s not really the fault of the writer; it’s an awkward subject to teach. It usually starts off by torturing the reader with a chapter or two of painfully basic concepts with just enough arcana sprinkled in to massage a migraine into existence. Typically they also like to mention that the arcana will be demystified in another chapter. The next step is to make you play typist and transcribe a big block of code with new and interesting bits into an editor and run it. Presumably, the act of typing along leaves the reader with such a burning curiosity that the next seventeen pages of dry monologue about the thirteen lines of code are transformed into riveting prose within the reader’s mind. Maybe a structured understanding just isn’t worth it.
I wanted to find a new way to study programming. One where I could interact with the example code as I typed it. I wanted to end up with a full understanding before I pressed that run button for the first time, not after.
When I first read about literate programming, my very first instinct said: “nope, not doing that.” Donald Knuth, who is no small name in computing, proposes a new way of doing things in his Literate Programming. Rather than writing the code in the order the compiler likes to see it, write the code in the order you’d like to think about it along with a constant narrative about your thoughts while you’re developing it. The method by which he’d like people to achieve this feat is with the extensive use of macros. So, for example, a literate program would start with a section like this:
KiCAD has been making leaps and bounds recently, especially since CERN is using it almost exclusively. However, while many things are the same, just enough of them are different from our regular CAD packages that it’s hard to get started in the new suite.
[Chris Gammell] runs Contextual Electronics, an online apprenticeship program which goes from concept to assembled electronics covering everything in between. To take the course you pay a nominal fee, but [Chris] posted a very excellent ten-part video series made during the last run of classes which you can watch without charge. The videos go through the basics of KiCAD while hitting the major points to consider when designing and manufacturing your electronics.
The project [Chris] chose is a simple circuit that blinks an LED with a 555. The first videos cover navigating KiCAD’s component schematic editor and library system. Next comes creating circuit schematics and component footprint creation. [Chris] covers PCB layout, the generation of Gerber files, and finally ordering the design from OSH Park — the purveyors of purple boards we’ve come to know and love. The series finishes up with simulating the circuit in LTSpice, ordering the parts, and finally soldering and debugging of the board. If all goes correctly you should now have a single blinking LED.
If the bright summer sun is burning your delicate skin, and you’d rather be locked inside with solder fumes, add this to your watch list now!