More ToyBots — Visitors from the Past come to enslave us in the future!

As I was saying a couple of weeks ago in reference to ToyBots, it’s may be a bit early from a technology standpoint, but the time is definitely coming — Lego has had some success with their Lego Mindstorms technology, and world creation in the online world — such as SimCity; Minecraft; and The Sims — has become the norm. Applying the world-building mindset to the physical world would be incredibly cool.

So, what would that look like?

One of the challenges with Mindstorms is that there is a genuine hurdle to making step 1 happen — so much so that Sylvan Learning Centers actually offer courses in Mindstorms: Link. You know that once a Sylvan course is offered in something, it has become both important to parents and hard for kids 🙂

And of course, at Microsoft we have the free to use Microsoft Robotics Developer Studio. Microsoft Robotics Developer Studio 4 is a freely available .NET-based programming environment for building robotics applications. It can be used by both professional and non-professional developers as well as hobbyists. Our last release was version 4.0, about a year ago, and there’s tremendous promise here for the future, but still — it’s pretty complicated stuff. It’s like trying to program a human brain to do everything imaginable.

We’ll have to take a different approach with ToyBots. First of all, to be a real “toy”, a ToyBot would have to be self-programmed. What I would imagine is that the toy would be constructed from a set of autonomous, pre-programmed “bricks” with particular functions, so that when connected they would act on commands that are pre-programmed on their firmware. For example, imagine a block which could make a sound — say a “siren” — and another block which was a light — say “flashing light”. Connected, you have a siren and flashing light, and they synch with each other to create “ambulance light bar”. Each “brick” (I’m using the word “brick” here very loosely folks) would be an Internet-connected IoT device, which can be updated from the cloud. So you could update “siren” to “European Siren” or “Police Siren” or somesuch. Likewise on the light, which could be different colors and different flashing frequencies. The key is that each brick performs a specific function, and although updateable, stays within its original parameters. Secondly, the blocks synch with each other based on how they’re connected, while not all blocks may necessarily respond to connections to each other. For example, our “ambulance light bar” may not respond to the speed of “wheels” modules — they may be separate processes, while they may be part of the same system.