Microsoft's Robots Will Assimilate You
Posted 21 Aug 2005 at 16:15 UTC by steve 
Nelson Bridwell sends
us Microsoft news from the International
Conference on Advanced Robotics in Seattle where Stewart
Tansley revealed details of what could be Microsoft's latest effort
to assimilate
the field of
robotics. Apparently this is now part of a larger strategy to create
more University
level students accustomed to using and developing proprietary software.
"They have decided that the best way to increase
enrollment is to
work with universities to incorporate robotics and computer games
into the computer science curriculum as class projects where
students can exercise their technical skills." The robotics and
computer games would be developed using various Microsoft proprietary
software tools instead of the currently preferred Open Source /
Free software
tools. Part of their plan is to develop robot platforms with
hardware that runs Microsoft's .net language natively and offering
them at much lower prices than conventional robotics hardware. A Power
Point presentation (viewable in Open Office - caution 28MB) that
accompanied Tansley's talk is availble online. For more details from
Nelson, read on.
Nelson continues,
As part of this effort, they have defined the mobile robot hardware
platform needed for universities as:
* 32-bit processors required for serious software development.
..Although robots could also include 8-16 bit embedded processors.
* Cost range $200-$1000
..$10,000 is too expensive for the classroom.
* Flexible
* Durable
* Available - Companies must be able to deliver thousands of these...
..And the companies must still be in business
They are working with several robot manufacturers to coordinate
marketing of these products to universities. They expect these
products to become available over the next 12 months.
According to the presentation, Microsoft may intend to concentrate their
marketing efforts on creating a new robotics community rather than
attempting to convert the existing community to proprietary tools. By
feeding
more advanced hardware into their newly created proprietary software
community, they hope to "seize the opportunity to accelerate the state
of the art", in essence shifting the majority of robotics users to their
proprietary platform and away from open standards and Free Software.
More details about Microsoft's robotics strategies can be found in a
2004 presentation titled, Applying
32bit Operating Systems in Educational Robotics (PDF format).
A webpage
with a steaming video of Tansley's talk is availble on Microsoft's site
but is in a proprietary MS format (in fact, the whole page is in
non-standard HTML that doesn't work in non-IE browsers).
For more information about a previous and apparently defunct attempt
to create a native .net CPU for robotics, see our 2004 story on the .net CPU Module. The
website associated with the .net CPU module appears to be gone, so I
assume the company failed or never made it to market. (anyone know for
sure?)
Don't forget Gate's Laws
of Robotics as quoted in a previous story.
It is clear to me that Microsoft has been carefully been sidesteppng a
number of marketing/PR minefields.
For instance, the suggestion that there is a real ($$$) robotics
market at the current moment for them to assimilate is a wonderful
fantasy.
However, if you look at Tansley's slides, you will see that there is a
very practical reason why Microsoft is choosing to spend money and
time on this effort, which is not likely to show a financial return in
the immediate future.
There has been a precipitous drop in the number of university-level
compter science graduates since the Internet bubble burst, which is
impacting their ability (and cost) of hiring new software engineers.
Simple supply and demaind will tell you that if graduates are in short
supply then they will have to offer larger starging salaries ($5,000?)
in order to meet their anual hiring quota (1,000?). Do the math!
(Payroll is by far the largest component of MS's expenses.)
They are also wise enought to know that trying to sell universities on
the exclusive use of their software would be, to borrow a phrase from
The Borg, "futile!" They are well aware that the Computer Science
community is almost entirely oriented towards inexpensive open-source
solutions.
However, basic business practices dictate that they have to offer
competing MS products. Otherwise, MS stockholders would quash this
endeavor. (Notice Tansley's subtle cheer about the RoboSoccer winners
who used Windows CE.)
And will there be a larger fraction of CS graduates who feel
comfortable with designing these MS products into a wide range of
application, whether or not the robotics industry every actually takes
off? Most certainly!
And will their efforts help improve the state-of-the-art for
robotics? I think so!
This isn't exactly related to MS but one thing I've noticed that would
improve the state-of-the-art in inexpensive robots is wheel encoders.
All the inexpensive robot kits seem to lack wheel encoders. Gearmotors
with built-in encoders are easily available but they tend to be
expensive. The usual work around is a DIY encoder using printed discs
and photodetectors of some sort. If someone came up with an
inexpensive robot kit with built-in wheel encoders, that would
be a major advance in my book. Or is something like this already out
there somewhere?
pretty cool design, well thought out, and worth it, but not
inexpensive. NuBotics Pete
Skeggs designed, and think they are sold there and at Acroname. For
other motors, might be good just to add something from US Digital or play hack a
(mechanical) mouse.
A lack of encoder feedback is one thing that bothers me about my ER-
1. (The other is that they did not include a straight-forward API
interface for programming it.)
The two suggestions that I offered Tansley after his talk were:
(1) They should try to design sensors and control subsystems so that
you could have access to low-level signals. That way, the robots
could be useful for EE control systems exercises, and the programmer
could also have access to richer environment feedback, such as that
you must be driving up a slope or pushing against a barrier if you
need unusually more drive current to maintain your velocity.
(2) They should try to make sure that these robotics kits are also
widely avaialble to professional engineers (for prototyping) and
hobbyists, not just CS departments.
One thing that would help the robotics community in my opinion is some
set of robotics standards. I think this could be the area that MS might
be the most help in and perhaps the worst problem at.
Standards such that robot engineers could take components off the shelf,
and plug them into their robot, hack a little code and get that module
working would be a real boon to robotics. Right now there are no
standards. If you build a robot, how would it be standard with another
robot? Tim Brown at least has tried to align himself with PCs to get
some sort of standards, but I think it needs to go further than that.
Right now you get a raw device such as a motor or a sonar and there's no
standards from the connections and cabling to the api to voltages etc.
One thing that MS did for PCs was make plug & play protocol and
connections where each peripheral had certain methods for plugging in.
The Operating system could many times just up and talk to it, figure it
out, and add it gracefully and it shows up in your system resources.
For robotics, there's nothing like that. Just about any robot that is
built today is designed from scrach, hard wired put together and hard
coded for the most part. You can't just plug together a bunch of parts
and have a robot. It's not that easy. It's not easy at all.
So the first thing you might say is, it would not make sense to add an
IC to a motor just so that it would meet some sort of standard. I say,
it wouldn't take much to make a 8 pin pic do all the negotiating between
the motor and a motherboard. You then could have the motor module with
encoder, h-bridge, and all be connected by SPI power and ground. That
would be cool. If you could buy a couple of such motors anyone could
easily add them to a robot and get going fairly quickly with simple
standard API that works with all similar motors with controller board.
Or perhaps just the interface board could be made and one would just
have to set a few jumpers to make the motor work with a standard
controller board.
Each component could be made with similar standard APIs that a
microcontroller board could simply poll the perifreal and figure out
what to do with it. Some sort of Robot Operating System could figure if
a motor was added then do some navigation. If a camera was added so
some sort of vision processing. If an arm was added work with that. If
a leg was added, etc. The brain program itself could be an application
that runs on top of the ROS.
People are always having to reinvent stuff all the time. How many times
have you seen the same bump into wall robot being recreated by someone.
Sure it may look a little different, but you know what I'm talking
about. You know why? It's because the learning curve on building a
robot is so steep that you feel like you've accomplished something when
you've gotten to the point of just having a robot that will move on its
own. How many times and how many ways do robot builders have to figure
out how to interface a motor to an MCU board? How many times do people
have to write and rewrite some code fragment? What if you never had to
write motor control code again because someone was bright enough to
write a driver and you could just reuse that driver? What if you could
just use a sonar driver? A you name it gizmo driver? You could move on
to more exciting stuff like making a robot to do something useful
control code. Wouldn't that be tremendous?
Until some sort of standards are agreed upon and companies start using
them, robotics will trudge along slowly and only be able to be built by
the most talented minds and even then really can't be easily modified
after it's completed. To build a robot, you have to know too much.
You've got to be an EE, a Physics guru, a software guru, hardware guru,
etc guru to make a robot. Why? Because right now you have to know all
of these things if you want to make a motor turn or even if you want to
connect some motor controller board with 20 some odd pin connections to
various who knows what they do so you got to figure them out things.
It needs to be where you can connect a motor module and your mcu just
talks to the board and tells the motor to go forward so far and reverse
so far and how fast (or some sort of standard api for motors). There
you have it. Low testing because you already expect a certain type of
performance out of the board. Someone already did that testing. You
just got to hook it up and go about your business of making your robot
go somewhere.
I could easily see MS coming in and setting these standards and using
existing Windows tech to quickly get to that position. However, I don't
expect that MS is willing or even wants to do that. They just want to
take over existing tech, they don't really want to make tech. So where
are we. We are waiting for some robotics company hero to set the
standards for us so that we can all benefit from it. I don't expect
that MS will be that hero.
So what do we need. We need a robot standards board that does noting
but figures out standards. Right now robots are making all kinds of
stuff but they have no vision. Instead they just go striking out on
their own and creating whatever suits their whim as how it should be
done. Each one has a small picture instead of the bigger picture.
That's what we need a robot standards group for. To define the bigger
picture for others to follow. You might even see two or three standards
appear like PC vs MAC but at least there might be more rhyme and reason
to it all.
So you say the robotics field is too diverse for standards? Not at all.
There could be one set of standards for tiny robots, and another for
medium and another for large. All of the standards could be similar so
they may even be able to scale if need be, but I can still see like a
Windows CE (forgive me for my pea brain can't think of a better example
this late at night) and a XP version of standards for robots hardware
and software.
OK, I've rambled on too long and it's late. So I'm going on to bed now.
Sorry for my long soap box hour of power.
I agree with the whole standards thing. I think that robotics is fun
because you learn a lot about a lot of things, and I think that
knowing how something works is really great, but lets face it, if you
have to put in so much time into getting the basics sorted out (ie
reinvent the wheel again) then when do you get time to do all those
things that move the field forward. For example, I have had a great
learning experience interfacing the SRF04 to my M16C, but really, I
don't know if I want to do that all again with the Sharp IR ranger.
I've been thinking about this sort of thing for a little while, and
what may be needed, with this alleged about-to-be boom of PC-based
robots based on nanoITX, is a PCI card peripheral controller - you
know a couple of 1-amp h-bridges, a couple of servo outputs, a couple
of sharp IR ranger modules, a couple of SRF04 modules, a couple of
odometry modules - I think you know where I'm going. Then all you
need is an open source driver for windows AND linux and then you can
have some serious higher level experimentation potential.
What do you think, is such a thing needed, and if so what is required
on such a PCI card?
Cheers,
Marcin.
I agree. Anything like a PCI card that can control robotic stuff is
cool and could really help build a robot. You could probably pick up a
PCI card with address logic from Jameco if you wanted to build one to
get you started. Or, you might search to see if something out there
like that already exists.
However PCs are not really geared for a robotics environment. They
don't really make efficient use of power nor is it easy to interface a
battery to them. Nor is the video easy on batteries. PCs are usually
heavy creatures.
Laptops on the other hand are great at power efficiency and great for
robotics. They are battery ready, have low power video, light weight, etc.
What you might want to be looking at is something that will work with
laptops. PCI cards are pretty much for PCs only. You might look at
making a board that runs on ethernet, USB or serial to talk to it
instead (ie: something a laptop can use to communicate to it). Such a
board could be used by either platform (PC or laptop).
There might already be some sort of I/O boards out there that have USB
or serial to it. You would then only need to add your IR and H-Bridge
sort of stuff that wouldn't already come on it standard.
I do feel like laptop robots are the wave of the future for now. You
can usually get a cheap older laptop for not too much cash that does
most of what your robot brain will need to do.
I think you're right regarding the PCI thing. I'm not much of a fan
of USB from a hobbyist point of view as it's not too easy to interface
anything to USB except a PC/laptop/handheld, but for interfacing to
those things, it could be good. Pretty much all major SBCs now have
USB ports (including the low power ones like the xscale and other arm-
based boards) so the applicability would be pretty wide...
hhmm - that does provide a lot of food for thought... now to find
those extra hours in the day...
cheers, Marcin
Standards..., posted 22 Aug 2005 at 13:29 UTC by Nelson »
(Journeyer)
I very much agree with the need for standard mechanical, electrical,
and software interfaces between the main computer(s) and
sensor/control subsystems.
The only place where I do not necessarily advocate sinking a lot of
effort on standards would be for the high-level algorithms, since
right now it is a wide open frontier, and it is anyone's guess in
which direction that will be headed.
I also am an advocate of the laptop USB/PCMCIA approach (although
other approaches are also viable). The RCM on the ER-1 was a
wonderful idea, if only they supported servos/encoders rather than
stepper motors.
Nelson Bridwell
www.MobileRobot.Org
All we would need to start a robotics standards board would be a bunch
of guys with a will and a purpose and a great recursive acronym. Any
suggestions?
Here's one...
R.E.C.U.R.S.E. = Recurse Every Cognition Until Robotic Standards Emerge
Standards Group, posted 22 Aug 2005 at 22:05 UTC by steve »
(Master)
Actually, Intel started a standards group a while back but it sort of
fizzled out after a year or so. I'm still on the mailing list but
haven't heard a peep out of them in a long time. The group is called the
The Robotics Engineering Task Force. They came out with some draft
protocols and APIs and, I think, were working with the idea of
standarizing on the player/stage software as a working model.
http://www.robo-etf.org/
Such a group already exists; although still a fledgling they are
showing a lot of promise. The standardized hardware interface / bus
may very well end up being Ethernet.
Have a look at this site:
www.jauswg.org
Part of one of my previous jobs involved work in the technical
regulatory compliance area in the Australian navy. Through that, I
was exposed to a lot of Defence standards (mostly US MIL-STD) and I
tell you, there's nothing as sure to turn a hobby into a chore than
compliance with a MIL-STD interface definition. Don't get me wrong, I
think these are very appropriate for military systems, especially
weapons platforms, the amount of rigor required to comply was
difficult for even for big defence contractors.
However, while overkill for the tinker/hobbyist/etc the GOA does
provide some structure and architectural guidelines. And I guess if
you develop the most neato path planning and localisation code for
your magellan-bot, then you have all the info available to wrap it in
JAUS compatible interfaces and sell it off to Raytheon or Thales
(depending which side of the atlantic you live on!) and become the
robotics millionaire you always wanted to be!
Cheers, Marcin.
One thing that MS does is make their own standard. They take what's out
there and just do it their way. There's good and bad to it. Basically,
their free to take all the things they like and leave out all the things
they don't. Of course, they disregard all the reasoning behind why
things are there and get themselves into trouble sometimes. But,
because they're so influential it sort of forces people to follow their
standard.
For example, sure there were already two button mice on the market.
But, they made their own MS style of two button mouse. Now, why would
anyone create their own protocol anymore since there's the MS mouse
standard protocol. I think logitech may still include a driver, but
most cheap mice you find use the standard driver and get around having
to include a setup disk.
So, I could see if MS starts creating stuff, people will start following
their protocols. People know when to jump on a bandwagon, and when a
big behemoth like MS picks a standard, then that's where the money train
is going. So, I'm guessing if MS does do robotics, then you can be sure
that whatever MS comes up with that'll be where everyone else will be
hedging their bets and following close behind on their coattails. It
doesn't matter if their standards are well thought out or even
completely usable. All that matters is being a part of that popularity
boat that most people can warm up to. And if you're not on the boat
when it leaves the doc, then you'll be stuck because no one will want
your "off the wall" devices that aren't compatible with MS robotics stuff.
That seems to be why a lot of companies create standards to try to head
off such a scenario with MS. Sort of like WWW group? They make HTML
standards and such and yet MS follows them loosely and everyone follows
MS and make webpages for IE only because of mob rule. Hopefully,
browsers like Firefox can take back the web, but it's hard to fight
against a mob. IE browsers can be inferior and still people will use
them (feel free to speculate why).
So I guess the question is, do we let MS win by default by coming in and
forcing standards down our throat, or do we come up with some sort of
personal robotics standards and head off the threat? My sad self thinks
we won't really bother. We'll just wait around to see how the battle
presents itself. Either a hero appears and with futility battles the
oppressor or we watch as the nemesis wins by default. Either way, the
personal robotics industry is vunerable right now to whoever has the
power to take charge of it.
PC-BOTS, posted 26 Aug 2005 at 08:03 UTC by Timster »
(Master)
As Swirl pointed out in his first comment I have tried to align myself
with PC-BOTS... as a first step on the road to creating some kind of
standards for robotics.
Because different robots computational needs and phsical properties vary
so widely it very difficult to achieve standards. If we were all trying
to create the same robot then it would happen sooner than later but of
course we're not.
The reason I have aligned myself with the 914 PC-BOTS more specifically
is that I see some common goals among the budding robot builders... the
big one being some kind of mobility and navigation. I think if this
came "out of the box" with robotic kits with little or no effort then
you'd see more people focusing on other "robotic" functionality...
however once again, "other" functions will require varying degrees of
computational power...(and specialized knowledge)... and PCs are already
on a peformance roadmap that will keep increasing computating power and
meet those needs. When you PC-BOT hasn't got enought computing OOOMPH,
you can swap in another newer motherboard/platform that does, based
around generally the same standards, or add a bigger hard drive... or
better 3ccdd webcam etc, essentially leech off the standards of
established industry needs for PCs.
While its also been pointed out that power is an issue I think you'll
find that not only VIA is interested in low power computing but that
this week at the Intel Developer Forum, the beast themselves have
plotted out that low power solutions are now the way forward. Good news
for all roboteers.
With a commercial company like White Box Robotics driving a standard
hardware platform, then the community (typically open source) or another
commercial business (Microsoft?) can possibly begin pushing software for
some basic functionality.
Right now the community is heavily fragmented, in terms of interests,
goals and abilities as the hobbiests, educators, mad scientists and
businesses all have different robotic objectives. Microsoft will likely
be much more focused... and if they can provide a software platform that
makes specific application development easier... then perhaps they'll
drive the community and businesses as well. This is a tried and true
formula for the PC and may well work for robotics.
I think essentally we're all impatient for robotics to start to realize
its potential at a personal level the way many more mature technologies
already have and I think commercial efforts like Microsoft's whether as
a solution or catalyst to alternatives is a very necessary part of that
push.
Anywho... if you're into joining in on the PC-BOTS concept/stepping
stone for robotics.. come on over (shameless plug) www.914pcbots.com
Basics first, posted 26 Aug 2005 at 14:07 UTC by marcin »
(Journeyer)
Maybe I'm still too new at this robotics thing and I don't know what
I'm talking about...but I'll forge on anyway, no point breaking the
habit of a lifetime:
I think using webcams, pentiums, windows, and mouse drivers is all
great for those upper levels of the robotic control system - all that
stuff like recognising your face, captured robot, environmental
awareness, blah blah. To me that's at the application layer.
What I was thinking was that at the slightly lower levels of sensor
and effector control, lower end decision making etc, it would be nice
to have a standard interface.
Something like an PC104 interface - say 50 pins (2 rows of 25) where
designated pins are for motor control (direction, PWM, enable),
odometry (L&R pulses), range finder (TX direction, data),
acceleration, temperature, whatever. And these things could stack
like PC104 boards. Could also have an addressable general purpose set
of control line for 'other' things.
So, for example someone who makes a motor board using the LMD18200
simply taps of the requisite pins and wires them to the 18200. Those
boards made withthe LM298 would need some interface circuitry, but to
the roboteer (I like that term, and I'm glad to see someone else uses
it!) they still just make the settings on the same 6 pins, regardless
of the underlying implementation. Same goes for SRF04, vs other
rangers be they ultrasonic or IR or laser.
Some boards could have multiple functions, some boards only one -> it
wouldn't matter.
my 2c goes a long way :)
Just to follow up on Timster's thought. A PC Bot doesn't have to run
windows any more than a desktop PC does. Desktop PCs run Linux, BSD, Mac
OS, DOS, all sorts of stuff. Same is true for those PC bots - should be
easy enough to run Linux on them and get the same benefits you'd get
from running Windows but you'd also get lower cost and no BSODs.
A dedicated 25 pin header would be great, but I would suggest also
adding a few pins for networking. Something like power, ground, clock
and data. If you had that, you could talk to every "smart" sensor and
"smart" motor controller through packets and all those modules can talk
back too. The packet itself would tell which device you're talking to
and the data. The modules just have to filter for only messages
addressed to them. Some common robotic network schemes are CAN, i2c,
SPI, and RS232/RS485. Having smart modules and a networking scheme
would eliminate a lot of wires going everywere. Also, the nice thing
about going with a network instead of dedicated lines is that is has
room for expansion. You can add functionality tomorrow that you didn't
necessarily plan for today. You can't do that with dedicated pins. On
the module side, you'd just need to add a small pic chip to decode the
messages as a liason between the network and the module's function.
Now, if that networking scheme had some sort of standards so that a
motor manufacturer could make a motor that was "smart module ready" that
would be cool as it would sort of almost then be like plug and play.
I like it, posted 26 Aug 2005 at 16:43 UTC by marcin »
(Journeyer)
I like it, possibly because it reminds me of the original thesis ie
PCI-based robot controllers (I'm still not sold on using USB for
everything). We're now talking a cut-down PCI - be it CAN or some sort
of parallel structure. Maybe we don't need another interconnect
mechanism, but PC104,cPCI or something like that is the way to go?
The thing I was describing was really a very basic direct-control bus,
because I am pretty lazy and I don't have/use PICs.
Cheers, Marcin
PCs/Windows/Linux, posted 26 Aug 2005 at 16:53 UTC by marcin »
(Journeyer)
I think that possibly the whole operating system debate may go away soon
- you will use virtual machine architectures more and more, so that the
operating system just becomes whatever's convenient for a particular
component. I can imagine for example, that a lot of data acq (webcams
anyone) could be done by windows drivers, then passed by TCP to a calc
process in a linux virtual node. Distributed computing goes inside a
single chip.
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank