All the news that's fit to assimilate[ Home | Blogs | Events | Robots | Humans | Projects | Podcasts | About | Account ]
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.
* 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?
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...
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?
R.E.C.U.R.S.E. = Recurse Every Cognition Until Robotic Standards Emerge
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.
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:
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!
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.
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
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, 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.
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.
2012 Top 10 Robot Christmas Gift Ideas
DARPA Robotics Challenge Kick Off
2012 ASABE Robot Contest Photos
Interview with David L. Heiserman
David Anderson on Subsumption Robots
Review: Apocalyptic AI by Robert M. Geraci
Raspberry Pi Interview with Eben Upton
2012 VEX Robotics World Championship
Giant Dallas Robot Cited as Best Public Art
There's More Than One Way to Skin a Robot
Day of the Androids at Hanson Robotics
Apocalyptic AI by Robert M. Geraci
Robotics Programming 101
Pololu 3pi: the 10,000 Mile Review
Unofficial LEGO Mindstorms NXT Guide
Machinima Review: Stolen Life
i-ROBOT Poetry by Jason Christie
The Definitive Guide to Building Java Robots
Microbric Viper Kit
Introduction to Autonomous Mobile Robots