1. In the short to medium term 3D printing will be something that companies use to provide customized goods to consumers, not something that consumers use directly.
2. 3D printing won’t take off for in-home manufacturing until a printer can build something like a toaster

A 3D printer is an incredibly powerful tool for prototyping. In the hardware lab at the office we have a couple of Dimension printers, a laser cutter, a PCB mill, a Vinyl cutter, and a fairly complete set of power and hand tools. With those tools, a few McMaster-Carr and Digikey orders, and enough assembly time we can build a prototype of just about anything. A dizzying array of goods has come out of that lab and let us try out things in a few days to a week that would have taken us a few months to a year if we had tried to do the same thing ten years ago.

The problem is that the output of the printer requires additional off the shelf parts and significant assembly time to turn an ABS structure into something functional. This is where I think the toaster is a useful mechanism to talk about.

The pop-up toaster is arguably the simplest appliance in your kitchen. And yet it is also filled with components that are beyond the reach of 3D printing today.  (You can learn more than you ever wanted to know about how a toaster works here.) Here are several challenges that toasters present for 3D printers:

1. The whole device is heat-resistant. Toasters heat to about 300 degrees Fahrenheit, but the melting point of ABS plastic is only 221 degrees. Clearly printing the toaster body out of ABS isn’t going to work.
2. The power cord of a toaster contains both conductive elements and insulating elements. There are also insulating elements scattered around inside the toaster. Extrusion printers can handle the insulating elements, but not the heat resistance. Binding printers (sintering or EBM) can handle the conductive elements, but only print one material at a time so they can’t combine the conductive elements with the insulating elements in one object.
3. “A toaster’s heating element usually consists of Nichrome ribbon wound on mica strips.” Nichrome is actually used in extrusion printers to heat the plastic. I can’t find any reference to either it or Mica being printable, and that would definitely require multiple materials in a binding printer.

None of these problems are insurmountable. Several 3D printers can already print in multiple materials. They just all happen to be different kinds of extruded plastic. Eventually those printers will figure out how to include metal in their parts. Heat resistance is probably a bigger challenge given how the printers work, but in theory they could use materials with even higher melting points so the resulting products could handle 300 degrees without a problem. And the list of materials that can be printed is growing every year. Eventually these problems will be solved.

That brings me back to the first conclusion, however, because I don’t think those solutions are going to come from the low-end printers you can afford to put in your house. Figuring out how to print conductive and insulating materials in the same batch is a hard problem. Heat resistance is a hard problem (for extrusion printers). Printing new and exotic materials is hard problem. These are the sort of thing that researchers are going to chew on for a while, then expensive first generation commercial implementations will need to be built.

As MakerBot eats away at the low end businesses of Objet and Dimension these bigger companies will move further up-market and add some of these higher-end features. Eventually MakerBot and its ilk will get those features too, but that is going to take a long time, probably ten or more years. In the meantime, the only printers capable of printing “advanced” devices like a toaster will be those that cost tens or hundreds of thousands of dollars. Price alone will keep these printers out of the hands (and garages) of individuals for a long time.

The only people who will be able to afford the next generation of toaster-capable printers are companies that use that capital investment as part of their business. That includes hardware labs that use these as tools for prototyping, but also mass-customization companies that build iPhone covers or print MineCraft levels today. These companies can charge a premium for their products because of the customization so they can amortize the cost of the printers (and learning how to use them) over thousands of customers. They will also be the primary market for companies like Dimension and Objet, so those printer providers will have no reason to drop their prices to a level normal people can afford.

One last random thought before I end this meandering post:  The printers that we’re running in twenty years will bear about as much resemblance to today’s 3D printers as my Nexus 4 bears to my first computer (a TI 99-4/A). They will be a combination of binding and extrusion, or something we can’t even imagine now. They will include many elements of a pick-and-place machine to include complex semiconductors in the resulting devices. And, once their utility reaches a certain point, their prices will be in free-fall. Eventually the future of 3D printing is bright. I just don’t think it’s going to happen overnight.

1. Wrong. Netflix did pick up more content. They are doing some interesting things with Arrested Development, for instance. However, I don’t think people will look back on all the pricing changes, Qwikster, and the general user annoyance as a year when Netflix “kicked ass”.
2. Correct. 50 Mbit FiOS! Woot! We moved from Seattle to Kirkland into a house where the previous owners bullied Verizon into running the fiber. It’s completely awesome.
3. Sort-of Correct. It’s not 60%, but Android is up to 43% market share. “Dizzying array” is the only way to describe the number of Android devices out there, though that’s not entirely a positive thing.
4. Correct. Google and some of their partners announced a plan to improve the update situation. Hopefully that will work out.
5. Correct. What new glasses? The Vuzix Star 1200s look cool, but $5k is a bit out of the consumer price range.
6. Correct. This one was sort of a gimme since there’s no way to tell if this is really the start of anything. I’ve seem a bunch of Nissan Leafs around my neighborhood though.
7. Wrong. I certainly haven’t heard of any such advance. Did I miss one?

4.5 out of 7 isn’t so bad. Some of my predictions were pretty soft-ball though, so I kind of cheated.

I think I’m going to skip writing my own 2012 predictions post this year. I would love to hear what you think is going to happen this year. Post them in the comments! (I’ll probably pick the best of them and put up a new post collecting them.)

Edit: @JZig points out that math is hard. 7 – 2.5 = 4.5

1. Transmitter sends a signal at time X saying “It’s time X!”
2. Receiver receives that signal at time Y
3. Distance = ( Y – X ) / speed_of_light

So how do you build a common time base on a ad-hoc network of locator nodes run by a random assortment of people? The short answer is that you don’t. Assuming a few things about all the hardware involved you can get by coming up with an ad-hoc time base that still lets you compute distance without requiring any kind of central authority.

This assumes a few things about beacons and receivers in the network:

• Each node (beacon or receiver) has a fixed (and known) amount of receiver lag. This is the time between when a signal hits the antenna and when it’s pushed to whatever internal system can tag it with the internal clock of the node. This is Send(N) for node N.
• Each node has a fixed (and known) amount of transmitter lag. This is the time between when a message is sent and timestamped, and when it actually leaves the transmitter’s antenna. This is Recv(N) for node N.
• None of the nodes are lying.

With these assumptions, the system is relatively straightforward. Any node can compute the translation from its own time base Time(n, t) to some other node’s time base Time(m, t) by pinging that node:

1. Node N generates a random number ping_key
2. Node N broadcasts a message containing ping_key and records ping_time = Time(N, t).
3. Node M receives that broadcast message and records receipt_time = Time(M, t).
4. Node M sends out a broadcast of its own with: NodeID(M), ping_key, Send(M), Recv(M), receipt_time, Time(M, reply)
5. Node N receives the response and notices that ping_key matches its own ping_key.
6. Node N computes its relative time base with M as follows:
   • Total_time = Time(N, reply_receipt) – Time(N, transmission) – ( receipt_time – Time(M, reply))
   • distance_time = (Total_time – Send(N) – Recv(N) – Send(M) – Recv(M) )/2
   • distance = distance_time/speed_of_light
   • time_base_difference = Time(M, t) – Time(N, t) = Time(M, receipt) – Time(N, transmission) – (distance_time + Send(N) + Recv(M))
   • time_base_difference2 = (Time(M, reply) + distance_time + Send(M) + Recv(N) ) – Time(N, reply_receipt)
7. Node N stores NodeID(M), time_base_difference, distance in its table of nearby beacons. (time_base_difference and time_base_difference2 should be equal assuming that all the lag numbers are right and the distance hasn’t changed. If they drift apart something is wrong.)

This mechanism enables each beacon to keep a constantly updated time base for every node in range via the same packets it is using to determine distance to those beacons. Beacons can then send out everything they know:

• Their own location (estimated from GPS and refined via the algorithm in the simulator)
• Time(beacon, broadcast)
• For each beacon N in range:
  • Node ID of N
  • Time(N, broadcast)

Here comes the unfortunate part: In order to figure out its own time base relative to a beacon each receiver must ping at least one beacon. Once it has that beacon’s time base it can figure out every other beacon in range of that beacon and work out from there. Because clocks on nodes will drift apart over time this ping will need to be repeated every X minutes. Because the last pinged beacon will eventually be out of range, it should also be repeated whenever the receiver moves more than Y distance. This ping need not contain any identifying information about the receiver, so it shouldn’t have privacy implications, but it will reduce the scalability of the system from receiver_count = infinite to receiver_count = bandwidth / (ping_size * ping_frequency). As long as the pings are relatively small and infrequent that should not be an issue. Multiple receivers attached to the same clock (i.e. multiple receivers carried by the same person) could also share time base information and would not need separate pings.

What do you think? Will it work? Are predictable transmit and receive lag even realistic?

Both receivers and beacons use transmit time to compute distance. Beacons use those distances (and the knowledge that they are all actually in fixed positions) to build an accurate mesh of their relative positions to each other. Those relative positions are fixed to absolute positions by including beacons with very precise known positions in the network.

I wanted to see if I could figure out how to actually find beacon positions relatively and then absolutely based on those few known beacons, so I built a simulator. The beacons use a mass and spring system to push and pull each other around into usually the right positions. This has the advantage of working without any central authority computing beacon positions. If its neighbors are trustworthy, each beacon can “move” itself around until it finds a stable location. This simulation is in 2D, but there’s nothing preventing it from working just as well in 3D.

The simulator is in Javascript, so I’ve just embedded it below. You can find some instructions on how to use it if you scroll down. Comments appreciated!

Select a beacon type from the UI and click anywhere in the frame to add a beacon at that location. Or click Random to add a new beacon.

Units are in pixels, except for the mass and spring weight values which are in Foozles and Smurfs respectively.

You can also use these key equivalents:
k: select Known
u: select Unknown
g: select GPS
r: place a beacon of the selected type at a random location

1. The system should scale to any number of mobile devices.
2. The system should work indoors and outdoors. It should also work underground in places like subway stations.
3. No one should be able to track the position of devices in the system.
4. A mobile device should require minimal warm-up time of less than ten seconds
5. A mobile device should be able to determine its position on an ongoing basis with a frequency of at least 30Hz.
6. A mobile device should be able to pinpoint its position down to 1cm or less.
7. A mobile device should be able to operate with its positioning system activate at all times and still maintain a reasonable battery life.

The closest current contender is GPS. Let’s see how it does on each of those front:

1. So far so good. The GPS satellites don’t care how many receivers there are. GPS has weathered an explosion in the number of receivers over the past ten years and come through just fine.
2. GPS fails this one. It works outdoors most of the time but indoors only if you are near an equator-facing window. It never works underground.
3. Since GPS receivers only listen, this is generally true.  The 911-driven remote activation requirements allow some GPS devices to be trackable, but the tracking happens through the phone’s network connection not through the positioning system itself.
4. GPS manufacturers claim warm-start times under ten seconds. According TTFF measurements for many models from 2003 some models can warm-start in under ten seconds. Things have significantly improved since then.
5. GPS receivers typically send an NMEA position sentence once per second (or 1Hz). SparkFun lists a few GPS components in the 5-10Hz range. It’s not clear if this is a limitation of the system or if GPS has an inherent update frequency limitation, so we’ll assume that improved chipsets will get the frequency up to 30Hz.
6. GPS completely fails this one. Under ideal circumstances and non-real-time post-processing GPS will get you down to about 2cm. Under normal circumstances the accuracy is more like 10-50m. GPS will tell you what street you’re on (if you assume you’re on a street) or what house you’re in, but it can’t tell you what room you’re in.
7. Current GPS receivers still draw too much power to leave them on all the time, but Moore’s Law is changing that. They should be always-on in a few more years.

GPS fails in two very important requirements: where you can use it and how accurate it is.  Satellite-based replacements for GPS are likely to have the same failure indoors and underground. If it ever launches, Galileo is supposed to have a commercial encrypted system that provides accuracy down to 1cm, but it still won’t work indoors or underground. Relying on satellite-based positioning is a dead-end for augmented reality.

The other way that AR researchers are tracking position is with a camera-based system. No one has yet built such a system that operates out in the wild, but it would be theoretically possible. A visual tracking system would operate by comparing the stream of images from the camera against a database of images that is stored in the cloud. The exact form of that comparison is a matter of much research. Whether the comparison happens in the cloud or on the mobile device is also an open question. The general form of the system (large database in the cloud and a stream of images from the camera on the mobile device) is pretty stable though. One key assumption here is that the image database for a city-sized area is far too large to download to the mobile device. Let’s see how that does on our requirements:

1. Because of the requirement that we either stream the camera images to the cloud or the local portion of the database from the cloud to the mobile device, each additional user puts incremental load on the system. The number of users in a local area will be limited by the mobile network bandwidth available to those users. The number of total users of the system will also be limited by the server capacity of the system’s provider, but that end of things can scale out more easily.
2. This system would work anywhere the database covered. Indoor and underground environments would be fine. Areas where the camera could only see other people (i.e. crowds) would be a problem because the database wouldn’t have anything static to compare against.  If the camera depends on environmental light this system would perform poorly in dark areas (or at night.)
3. If the camera’s images are streamed to the cloud the system’s provider would know exactly where each device was at all times. If the portion of the database related to a small area is streamed down to the device then the service provider will only be able to locate the device to within that small area. Either way, the provider will know where the user is to within a few hundred feet.
4. If the camera images are streamed to the cloud, start-up times should be more or less instant. If the database is streamed down to the device it may take a few seconds to get things started, which is well within our tolerance.
5. Current visual tracking systems have trouble reaching 30Hz, but Moore’s Law should take care of that eventually. For a system that streams the video to the cloud bandwidth can also affect update frequency. Once the link starts filling up with streams from other devices the update frequency goes down for every device.
6. Visual tracking systems are quite accurate. Finding hard numbers is difficult, but there’s no reason to believe that a visual tracking system would be less accurate than 1cm.
7. Visual tracking systems are power-hungry at the moment. They require fast cameras, fast network connections, fast CPUs on the mobile devices, and lots of memory. Because so much of the system is unknown, it’s hard to pin down numbers, but I would estimate that we need 100x power reduction before leaving this system on all the time is realistic. That will take Moore’s Law about ten years to accomplish.

If we can solve the low-light and power issues, a visual tracking system would certainly work for a small number of users. Solving the bandwidth constraint for a system that much of the population is using is a more daunting issue. All that bandwidth also makes the system expensive to operate, which will be passed on to end users as either usage fees or advertising. Building a workable generally available visual tracking system not an impossible problem, but it’s certainly a difficult one.

Personally, I’m not satisfied with either of these systems. I have thoughts on how to build a better one, but I’ll save those for a future post. What do you think? Am I missing any major requirements? Are any of mine unnecessary? Am I representing GPS or the imagined visual tracking system unfairly? Let me know in the comments!

1. Netflix will continue to kick ass. Their selection of streaming movies and TV shows will explode in 2011, though they will have to pay more for all that content.
2. My internet connection will improve. Self-fulfilling prophecy? I hope so! I’ve had 1.5Mb/768kb DSL for ten years. It’s well past time to upgrade. In theory Qwest will be putting 20Mb service into my neighborhood soon, so maybe that’s in my future.
3. Android will continue to kick ass and take names. 2011 will see >60% smartphone market share, a dizzying array of tablets and phones, and probably even some netbooks by fall. More and more apps will start to ship on both Android and iOS at the same time.
4. Android 3.0 will include improvements for the annoying OS upgrade delays on that platform. Google will come up with some way to apply pressure on handset manufacturers and carriers to deliver the latest version of Android to uses in a more timely fashion.
5. Still no consumer-level visual pass-through AR glasses. I said it last year, and I’ll keep saying it every year until I’m wrong.
6. This will be the year the electric car revolution began. The Nissan Leaf and Chevy Volt will both sell well and set the stage for the electric cars of 2012 (including the Tesla Model S) to blow the doors off.
7. This year will feature one “unthinkable ten years ago” level medical advance. Will it be a cure for cancer? Regrowing limbs from your own stem cells? Repair of severed spinal cords? Pain medication with no side effects? Who knows, but something big is going to happen this year.

And that’s it!  If it’s not on this list it’s not going to happen in 2011!

(Think maybe something might happen in 2011 that wasn’t on this list? Please add your own prediction in the comments and we’ll see how you do!)

1. Correct. It is arguably fair to call STO the only significant MMO launch of 2010. APB sort of fizzled, after all. I haven’t heard much about STO since its launch though… not sure how it’s actually doing.
2. Sort of Correct. I could only come up with two cancellations from my list:
   • APB was actually cancelled after it came out. That’s the wrong way around.
   • The Agency is rumored to be more or less shut down at this point. Nothings been announced here and probably never will be.
3. Correct. Reports are that they’ve both sold millions of units.  Natal (now named Kinect) has also incited thousands a cool Kinect Hack YouTube videos. Dance Central is pretty cool, so at least one great Kinect game is already out.
4. Correct. According to this chart the unemployment rate in the US peaked at 10.6% in January 2010.
5. Wrong. I’ve seen no evidence that Junaio, Layar, or Wikitude are ready to stray from their AR roots yet. In fact they seem to be doubling down by making the set of things they can position at a GPS location much more complete.
6. Correct. There haven’t been any interesting new products in the area of wearable displays. Lots of talk at ARE2010 and elsewhere, but nothing concrete yet.
7. Correct. Google Goggles came to the iPhone, but other than that neither company has done anything on the AR front.
8. Wrong. There’s no indication that the marketing world (or consumers) are tired of simple AR campaigns. If anything the campaigns are continuing to grow in popularity and complexity.
9. Correct. The iPad and iPhone 4 came out. Good thing I didn’t predict how well the iPad would do… I would have massively underestimated it.
10. Correct. App store approval times are reported to be under a week these days. They also published the review guidelines, which is a big step up from 2009.
11. Sort of wrong. Technically 200,000 is more than 50,000, but I completely underestimated the meteoric rise of Android during 2010. I thought that Android phones would only outsell iPhones until iPhone 4 came out, but they topped the iPhone in May (in the US) and never looked back.
12. Correct. Nobody figured out what to do with it so Google mothballed the project.
13. Wrong. Wave doesn’t inter-operate with anything. That’s a bit part of why it failed in my opinion.

My score was 9 correct and 4 wrong. Better numbers than last year, but I think I made more safe bets for 2010 too. 2010 went pretty much how I expected it would (with the notable exception of Android going gangbusters.)

How was your year? Did anything surprising happen?

The High Concept

Play through a role-playing game adventure on your mobile phone while moving around your local park, hiking through the woods, or wandering the streets of your home town. Participate in simple quests solo, or play with friends. Or if you prefer, develop your own adventures and share them online for other people to play.

The Inspiration

In the 1980s and 90s there were a series of books called Fighting Fantasy that let players play through an RPG-like adventure without a gamemaster. Combine a mobile implementation of those books with geocaching and then let the users create all the actual content and you have GPS Quest.

The Technology

Building GPS Quest would be straightforward:

1. Develop a simple RPG engine with monsters, loot, stats, and leveling up. Leave as many hooks as possible for user-generated content to modify things. Combat will probably want to be turn-based. Write a mobile app to resolve combats in the system.  This is by far the hardest step. Probably do this with just one player for the first version.
2. Build a back end that can track a player’s RPG stats over time. Include a quest system that can unroll an adventure in front of the player as they move around the world. This would probably be waypoint-based so the user can look at the next place to go on a map on their phone.
3. Build quest creation tools that let a user (you) write new quests in the actual physical world.
4. Publish all this to the world.
5. Iterate until massively popular

There are many hundreds of features that could be added once the basic system is up and running. Some ideas include:

• Multiplayer. First for small parties of 2-5 people and them maybe for raids of 20-40 people.
• Audio for monsters, navigation,  and quests. You could download it all before starting the quest so it could play quickly.
• Custom art for quests. Might want to download this ahead of time too.
• A builder-maintained bestiary
• A builder-maintained loot catalog
• Tools to remap existing quests onto new locations
• Matchmaking tools to help players find each other
• The sci-fi, zombie, pirate, superhero, spy, vampire, giant robot, caveman, and not-at-all-fantasy-medieval versions of the same game. That last one is so some SCA people can feel comfortable playing your game.
• Leaderboards for quest builders, quest remappers, and players to give all of those people bragging rights.
• More simple geocaching features like buried treasure and traps that players can leave for each other.
• Ports to whichever platform you didn’t launch for in the first place.
• Trading systems, auction systems, crafting systems

What do you think? Would you play?

SeAR July 2010: Augmented Reality the Next Next Big Thing from Joe Ludwig on Vimeo.

This is my talk from last Wednesday’s Seattle Augmented Reality Meetup. I will upload the discussion that followed as a separate video later today. Comments and feedback are welcome… just comment below or over on Vimeo.

The working title for the app is Mobile Photo Hunt. If you give Photo Hunt a try and have feedback, I set up a User Voice forum to collect that feedback. This is an open alpha, so don’t be surprised if major changes occur over the coming weeks. I am making it available here well before it goes up on the app market so I can get some early feedback. Please tell me what you think.

The basic idea is this: People take pictures of cool or interesting things in the world and upload those as puzzles. Those pictures (and their GPS coordinates) are made available to everyone else and everyone else is encouraged to find whatever the thing is and take a picture of their own to prove that they found it.  Other users can then compare the two pictures and vote up or down about whether or not they match. Some sort of game mechanics wrap the whole activity to encourage good puzzles, searching for puzzles, and confirming matches. Except for the game mechanics this all basically works now.

The game uses Facebook Connect to authenticate users. I expect to eventually add Twitter, Google,  and OpenID logins as alternate ways to authenticate. I have no interest in maintaining a list of usernames and passwords, so creating a custom Photo Hunt account will never be an option.  These login methods are only used to figure out who you are and and come up with something to call you. The app doesn’t publish anything to your feed, send any messages to your friends, or do anything else annoying in whatever social network you used to log in.  I may eventually add the ability to automatically post new puzzles to Facebook/Twitter, but that will be something you can opt-in to when you upload the puzzle.

There are a few known issues up on User Voice already, and a few more minor ones I’ll list here:

• After logging in you will see three paragraphs telling you how to play but no buttons. They appear after your phone acquires a GPS signal. Need a busy indicator of some sort to indicate what’s going on.
• The FB Connect login has a yellow warning bar that says “Cookies Required.” Cookies actually WORK and your login is stored, so I don’t know what that’s about. Haven’t dug into it yet.
• When you bring up an on-screen keyboard the FB Connect dialog freaks out. I’m hoping this will be fixed when I switch to the official Facebook SDK.
• After you switch to another app it may still be using GPS. Killing Photo Hunt with a task killer will probably fix that. Eventually it will stop using GPS on its own.

So that’s my app.  Please give it a shot and tell me what you think.

Here’s a QR code for the app in case you happen to be viewing this on your desktop: