We attended Maker Faire at the San Mateo Fairgrounds in San Francisco, May 19-20, 2007. We were one of many Makers at the Microsoft Pavilion, and were demonstrating robotic applications developed using Microsoft Robotics Studio (MSRS).
Our demonstration consisted of two of our new Stinger Robot kits (prototypes), performing line following and obstacle avoidance behaviors, and a Traxster (retrofitted with a crane) which was responsible for loading/unloading blocks on to/off of the Stingers as they drove around.
Figure 1
Figure 2 – Arena Layout
Each robot used our Serializer Robot Controller as the main controller board for controlling/querying sensors, motors, and components.
The Microsoft Robotics Studio demo applications consisted of two separate services running under Microsoft Robotics Studio:
- Line Following Service (controlling the robots), and a
- Traxster Crane Service (controlling the Traxster Crane and Load/Unload gates).
Line Following Service:
The Line Following Service used three types of sensors to implement the desired behaviors:
- Our I2C Line Following sensor
- A Sharp GP2D12 infrared sensor
- Quadrature wheel encoder sensors (built onto our DC Gearhead Motors)
The I2C Line Following sensor was used to follow the white line (on the black arena mat). It can also be used to follow a black line on a white (or bright) surface.
The Sharp GP2D12 infrared sensor was used to prevent the robots from running into any object(s) in front of them, whether it's another robot, a load/unload gate, or in the case of Maker Faire, a child's hand (kids loved the demo, since they could stop the robots by placing their hands in front of the IR sensors). LoL
The Quadrature wheel encoders were used in conjunction with the internal Distance and Velocity PID control algorithms built into the Serializer WL. The Velocity PID control was used to maintain a constant velocity while traveling around the path. The Distance PID control was used to allow the robot to drive up to a load/unload gate and remain back an exact distance. This allowed us to place the blocks in a somewhat repeatable position on the top of each robot (which can be improved vastly).
The basic operation of the Line Following Orchestration Service, which by the way uses the Serializer Services so that it can control & query the Serializer WL components, was to:
- Follow the white line
- Fork onto the alternate inner path (to unload a block) every other trip around, otherwise go straight on the outer path to have a block loaded.
- Constantly look forward for obstacles in the way
- If an obstacle is ahead, calculate how far, and travel that exact distance, minus a buffer distance, and wait for the obstacle to clear.
The Stingers were the only robots to use the Line Following Service. As you can see on the video (see end of article), we placed a flat platform on top of them for which the blocks were loaded/unloaded.
As the Stingers traveled along the path monitoring their line following sensor, they would ultimately encounter a solid white line (see Figure 2 above). This triggered the service logic to make a decision whether to fork onto the inner path, or continue forward on the outer path. It would keep track of which path to take via an internal state variable in the Line Following service, which would toggle between forking, or continuing straight every time the solid white line was encountered.
If the decision was made to fork, then the Line Following service would go into "Forking Mode", and used logic to follow the left side of the white line to properly fork left. It would continue doing so until it encountered solid black, at which point the service knew it was through with the "Forking Mode" critical section, and it would change back to "Line Following Mode". Shortly after the fork was made, the Line Following service would encounter the Unloading Gate, command the robot to drive up to it using the PID Distance algorithm, and stop to be unloaded.
Figure 3 – Prototype Stinger Robot Kit
Traxster Crane Service:
The Traxster Crane Services used the following sensors and components:
- Sharp GP2D120 infrared sensors
- Servos
- Electromagnet
- Loading/Unloading gates
- XP Text to Speech functionality
The Sharp GP2D120 infrared sensors were located on the Loading/Unloading gates, and were polled to notice robots pulling up to get loaded or unloaded.
The Servos were used to control the Tilt and Pan of the Crane, and to raise/lower the Loading/Unloading gates, shown in Figure 4.
Figure 4 – Loading/Unloading Gates
The Electromagnet was used to pick up/drop off blocks off off/on to each robot in the Unloading/Loading stations, respectively. The Electromagnet was connected to one of the h-bridges on the Serializer. Enabling it was as simple as turning on the h-bridge to full power. Disabling it was just as easily achieved by cutting power to the h-bridge. Each block weighed about 2.3 ounces, and the Electromagnet was rated to pick up a maximum of 16 ounces (~1 pound), so it had no trouble picking up the blocks.
Figure 5 – Block with steel washers & Electromagnet
The Traxster you see in Figure 6 was retrofitted w/ a crane (a modified CMUcam2 turret w/ a 3/4" square aluminum tube attached to it) along with an electromagnet (controlled by onboard Serializer h-bridges). Its job was to load and unload the blocks above (w/ metal washers) off of, and on to, the robots as they traveled around the arena using the electromagnet.
Figure 6 – Traxster Crane
The Traxster crane service polled sensors located at the Load/Unload gates to notice robots pulling up to get loaded or unloaded. The basic operating states for loading/unloading were:
- Idle
- Unload - Robot ready to unload, and we don't have a block
- Unload - Robot ready to unload, but we already have a block…so wait
- Load - Robot ready to load, and we have a block
- Load - Robot ready to load, but we don't have a block…so wait
If the service noticed a robot waiting to be loaded, it would go ahead and load it, otherwise, it would wait on a robot to come along w/ a block. If it already had a block that it unloaded, and another robot came along w/ one to unload, it would wait until another robot came along needed the current block loading, etc., etc., etc.
Once the block was unloaded from a robot, it would raise the gate arm to allow the robot to proceed, monitoring the infrared sensor on the gate (same one it used to originally notice the robot), to notice when it was clear to drop the gate arm.
The Stingers would just sit and wait for the arm to raise, since remember they're looking forward for obstacles, and if one is in the way, they will sit and wait for the obstacle to move.
As the Crane service noticed robots, it would use the Text To Speech Service (included in MSRS) to tell you what it was doing (e.g. "Robot ready for block to be unloaded", or "Robot waiting for block"). It would also read our Ambient Air Temperature sensor (back of robot) to read the ambient temperature, and report that periodically. In addition, it would report the current time as well.
Robotics Studio and the Compact Framework
From the beginning, we had planned on running the Line Following Service using MSRS CTP 1.5 running under Windows CE 6.0, on an ICOP Vortex86-6082, located on the robot. This would allow us to have services running locally on the robot under Windows CE and the Compact Framework (CF), it would be fully autonomous, and it would help promote the use of MSRS with the CF under CE.
We spent a few days porting our Serializer Services over to build under MSRS with a Compact Framework project. It wasn't very hard, and George C. on the MSRS team (I can' pronounce his last name) was a huge help! See our forum post here.
We spent two days figuring out how to get the Service to start up automatically under Windows CE (Big Thanks to Jim Y. Wilson!), but it turned out to be really easy.
Unfortunately, time didn't allow us to finish flushing out the configuration bugs w/ the Line Following Services under MSRS and the CF. We were so close…So close in fact the services would start up, but then they would sit and pretty much do nothing.
We had four days until Maker Faire, and I had to go ahead and ship four boxes full of robots and arena gear to San Fran (from Atlanta) so that they would arrive on time. This cost us $800, which we hadn't budgeted, but what are you gonna do? J
Once we arrived in San Mateo and set up, we switched to our backup plan (always have a backup plan – especially when demoing at a Microsoft event! J), and ran two instances of the Line Following Service from our Laptops under XP. The services were communicating w/ our new Serializer WL Robot Controllers via Bluetooth. This meant the services wouldn't be running locally on the robots, but hey, the important point was to put on a good show.
How well did it work?
The Stingers followed the lines for two days straight with minimal problems. Sometimes they would go astray, but for the most part they kept on the path.
We ended up shutting down the Traxster Crane service because the infrared sensor on the unloading station was getting fooled (by infrared light coming in through the front door), so it would try to unload a block from a robot when there wasn't a robot there. That would then confuse the rest of the logic. We realized we had a lot of improvements to make, so we just (unfortunately) shut it down.
Going forward, we'd like to add vision recognition, using RoboRealm services, to recognize the exact location of the block to pick up, and the exact location where the block needs to be unloaded (on the robot).
We also want to improve the Line Following Service logic.
Lessons Learned:
- I'm really glad we had a backup plan (using Bluetooth to communicate w/ robots under XP).
- Don't try to demo your software & products using a CTP…at least one that's less than a month old.
- Keep it simple, stupid (We tried to make too complicated a demo, w/ the limited time we had available).
- While you probably shouldn't test out new prototype products at such an event, our Stinger Robots got quite a testing, running for two days straight with only one glitch, we needed to lubricate the back caster pivot. J After two days of spinning around, it simply needed lubrication to prevent it from locking up. This only occurred on one Stinger, since I did lubricate the other one. After staying up for several weeks for 18+ hour days, I simply forgot to lubricate the second caster. J
- The Microsoft group was great to work with. We also met some cool guys, who put together a cool Drink mixing machine and Disco Dancing Floor.
Crazy TV personalities like to lurk around and ask you silly questions about your demo, such as Jimmy Kimmell.
Figure 7 – Me and Jimmy
Ultimate Vision
My ultimate vision for this demo is to periodically add new stations to the arena, and build it up into a small, automated City, all controlled by the Microsoft Robotics Studio framework. Station ideas include:
- Charging services
- Robot Traffic Routing & Management services(multiple paths)
- Sanitation services
- Fire Fighting services
So, that summarizes our trip to Maker Faire. It was a success in many ways, but we did make mistakes. It was our first big conference and a huge learning experience for us. We have certainly made notes on things to improve…
Jason Summerour
President,
Summerour Robotics Corp
Microsoft MVP
Movies and Photos:
RoboticsConnection Maker Faire 2007 Video (*.wmv 11Mb)
RoboticsConnection Maker Faire 2007 Image Gallery
