You're using *what* OS to run your robot?
Yes, Virginia, I'm using Windows. Windows XP Embedded, specifically. I want an environment where I can write the logic for my robot using C# & the .NET Framework which is the programming environment I use in my day job for which I've developed quite a liking. I don't want to load up my robot with my 40 kilogram Dell Dimension, heck I don't even want to load my robot down with a 10 kg laptop. I want a small to medium sized robot.
The first path I followed was CMU's PPRK (Palm Pilot Robotic Kit) to which someone had attached a Pocket PC to rather than a Palm. This was very cool and motivating and a few hundred dollars and a couple of weeks later I was up and running. But I rapidly hit limitations:
It's harder to write .NET code for a Pocket PC
Many of the APIs are missing or limited, I couldn't write libraries very easily, and some key OS apis were missing (DirectShow & at the time various networking APIs).
It's really hard to upgrade a Pocket PC to a new version of the .NET Framework
With the .NET Framework improving rapidly, even today ~ five years after its first introduction, I found the "burned into the ROM on the device" approach very limiting. Pocket PCs are consumer devices, meant to be used and disposed rather than continually upgraded.
Drivers are hard to come by
A robot is nothing without its devices. While there was good support for the Acroname Brainstem, finding drivers for various network cards, cameras, GPSes, etc. was really tough. I ended up selecting from a list of very limited hardware suppliers whenever I wanted to try and add a new device. And with expansion ports basically limited to one PCCard or one SDCard, I wasn't able to add the number of devices I wanted.
The answer, I was told by people in the know, was to eschew the Pocket PC -- which is meant to be a consumer organizer -- and get a hardware platform that runs Windows CE. Aren't they the same I say? No, one is a consumer hardware device, the other is a development environment like Windows XP that you can customize, update, etc.
Now comes the search for a Windows CE enabled platform, a place to buy a license of Windows CE, etc. Well, let me cut to the quick. It turned out to be very expensive ($500, Quantity 20+) and none of the Windows CE resellers were terribly motivated to take on a custom, one off job for some robotics dude. Many months of discouragement later, I shrugged off the whole Windows CE and Pocket PC thing as an idea that sounds better than it is in reality.
Why not use Windows XP? It turns out there's a whole sub-culture in the PC world around making small, energy efficient PCs and sticking them everywhere. These motherboards are called Mini-ITX and they're fully capable x86 motherboards.
A very cool feature of XPe is that you can ditch the hard drive too. XPe has a "Target Builder" tool that lets you pick and choose exactly the functionality you want, omitting all the files you don't need. It also has a really important feature called the Enhanced Write Filter, or EWF, that lets you mirror your file system in RAM so that any writes you make are cached in RAM until you choose to commit them or throw them away (generally at shutdown time). This is really important when using static ram (like Sandisk CompactFlash cards) because while static ram can be written to, it can only be written to a couple of hundred thousand times. You laugh, but that one little bit on the disk that's constantly being "ping ping pinged" to update some timestamp or somesuch will cause a Compact Flash card to fail if you boot an operating system off of it and give it free reign to write whenever it wants.
After some playing around it turns out that I am able to load a full XPe image complete with all the networking functionality and utilities I want, Remote Desktop for remote management, and a bunch of other stuff onto a 512 MB CF card with enough room to load the entire .NET 2.0 Framework and still have plenty of space to store my robot applications and data logs. Since 512 MB CF cards are pretty darn cheap these days ($36 according to PriceWatch today), this makes for a pretty good and inexpensive solution.
The cool thing is there may be some limitations when using XPe in terms of functionality or driver compatibility, but I haven't found any yet. I'm able to use my Logitech QuickCam, a couple of different USB GPSes, any of my 802.11b wireless adapters, etc.
When writing add-on libraries for my robot, I've been able to use all the networking libraries of .NET, hook into DirectShow to get 30 fps uncompressed video frames off my QuickCam for image analysis, shuttle my real time sensor readings out to a laptop so I can do cool real time telemetry, leverage the built in RS-232 IO and GZip compression classes, etc. Basically all the tools and libraries a professional developer uses on their development PC.
This plus the ability to use a full IDE (Integrated Development Environment) like Visual Studio with remote debugging (on the robot itself) and all the tools you need to do a solid coding job like source control integration and a unit test framework. Pretty cool, nu?
So, what are the pros and cons of using XPe for a robot?
Pros
Runs on cheap, low power, small form-factor PC motherboards like the $95 Via EPIA 5000
Compatible with Windows XP drivers, so your device choices aren't limited
Has all the powerful libraries that you'd expect in a desktop development environment
Allows you to use a powerful programming environment with debugging, source control, etc.
Can easily test your code on your desktop PC running Windows XP without needing to use an emulator
Can load XPe in a virtual machine (like VMWare or Virtual PC) and connect to your microcontroller from the XPe VM
XPe evaluation is a free download
Cons
I *still* have not found an embedded reseller willing to sell me a Q1 license for XPEmbedded, so your "evaluation" image has to be rebuilt every 90 days.
While power efficient, the Via EPIA 5000 still chews power quickly compared to a microcontroller. I use two 1900 mAh NiCD battery packs to power my motherboard for ~30 minutes
So, that's my experience to date. I'm continuing to contact XPEmbedded resellers to try and find someone willing to sell Q1 licenses to robotic hobbyists. If I do, I'll let you know where you can get a license here. If you want more detailed information, such as what exact parts I ordered for my motherboard et al or what I included and omitted in my XPe image, drop me an email and I'll be happy to help you out.
The proof of whether this is a good idea or just another flake will be in next year's Robo-Magellan contest. I'm still of the opinion that solving a good, hard challenge like that one will stress software as much if not more than hardware. My challenge is to make sure that both my hardware and software are up to the task. Last fall, problems in my networking signal took me out of the race. I don't intend to let a hardware failure do the same next time.
- jcb
The first path I followed was CMU's PPRK (Palm Pilot Robotic Kit) to which someone had attached a Pocket PC to rather than a Palm. This was very cool and motivating and a few hundred dollars and a couple of weeks later I was up and running. But I rapidly hit limitations:
Many of the APIs are missing or limited, I couldn't write libraries very easily, and some key OS apis were missing (DirectShow & at the time various networking APIs).
With the .NET Framework improving rapidly, even today ~ five years after its first introduction, I found the "burned into the ROM on the device" approach very limiting. Pocket PCs are consumer devices, meant to be used and disposed rather than continually upgraded.
A robot is nothing without its devices. While there was good support for the Acroname Brainstem, finding drivers for various network cards, cameras, GPSes, etc. was really tough. I ended up selecting from a list of very limited hardware suppliers whenever I wanted to try and add a new device. And with expansion ports basically limited to one PCCard or one SDCard, I wasn't able to add the number of devices I wanted.
The answer, I was told by people in the know, was to eschew the Pocket PC -- which is meant to be a consumer organizer -- and get a hardware platform that runs Windows CE. Aren't they the same I say? No, one is a consumer hardware device, the other is a development environment like Windows XP that you can customize, update, etc.
Now comes the search for a Windows CE enabled platform, a place to buy a license of Windows CE, etc. Well, let me cut to the quick. It turned out to be very expensive ($500, Quantity 20+) and none of the Windows CE resellers were terribly motivated to take on a custom, one off job for some robotics dude. Many months of discouragement later, I shrugged off the whole Windows CE and Pocket PC thing as an idea that sounds better than it is in reality.
But wait, there is hope after all!
Why not use Windows XP? It turns out there's a whole sub-culture in the PC world around making small, energy efficient PCs and sticking them everywhere. These motherboards are called Mini-ITX and they're fully capable x86 motherboards.
A very cool feature of XPe is that you can ditch the hard drive too. XPe has a "Target Builder" tool that lets you pick and choose exactly the functionality you want, omitting all the files you don't need. It also has a really important feature called the Enhanced Write Filter, or EWF, that lets you mirror your file system in RAM so that any writes you make are cached in RAM until you choose to commit them or throw them away (generally at shutdown time). This is really important when using static ram (like Sandisk CompactFlash cards) because while static ram can be written to, it can only be written to a couple of hundred thousand times. You laugh, but that one little bit on the disk that's constantly being "ping ping pinged" to update some timestamp or somesuch will cause a Compact Flash card to fail if you boot an operating system off of it and give it free reign to write whenever it wants.
After some playing around it turns out that I am able to load a full XPe image complete with all the networking functionality and utilities I want, Remote Desktop for remote management, and a bunch of other stuff onto a 512 MB CF card with enough room to load the entire .NET 2.0 Framework and still have plenty of space to store my robot applications and data logs. Since 512 MB CF cards are pretty darn cheap these days ($36 according to PriceWatch today), this makes for a pretty good and inexpensive solution.
The cool thing is there may be some limitations when using XPe in terms of functionality or driver compatibility, but I haven't found any yet. I'm able to use my Logitech QuickCam, a couple of different USB GPSes, any of my 802.11b wireless adapters, etc.
When writing add-on libraries for my robot, I've been able to use all the networking libraries of .NET, hook into DirectShow to get 30 fps uncompressed video frames off my QuickCam for image analysis, shuttle my real time sensor readings out to a laptop so I can do cool real time telemetry, leverage the built in RS-232 IO and GZip compression classes, etc. Basically all the tools and libraries a professional developer uses on their development PC.
This plus the ability to use a full IDE (Integrated Development Environment) like Visual Studio with remote debugging (on the robot itself) and all the tools you need to do a solid coding job like source control integration and a unit test framework. Pretty cool, nu?
So, what are the pros and cons of using XPe for a robot?
Pros
Cons
So, that's my experience to date. I'm continuing to contact XPEmbedded resellers to try and find someone willing to sell Q1 licenses to robotic hobbyists. If I do, I'll let you know where you can get a license here. If you want more detailed information, such as what exact parts I ordered for my motherboard et al or what I included and omitted in my XPe image, drop me an email and I'll be happy to help you out.
The proof of whether this is a good idea or just another flake will be in next year's Robo-Magellan contest. I'm still of the opinion that solving a good, hard challenge like that one will stress software as much if not more than hardware. My challenge is to make sure that both my hardware and software are up to the task. Last fall, problems in my networking signal took me out of the race. I don't intend to let a hardware failure do the same next time.
- jcb
posted by Jay Beavers at 9:59 PM
<< Home