Humanoid robot torso A1

[Machine Translated] A larger project in which I work for some time, is a humanoid robot torso. Even if he is not even finished in its basic functionality, I took now the time me, closer to present it here something and to describe.

The project because nothing better occurred to me, I have given the working title "A1". Because that sounds but yet something bad dehumanized for a humanoid robot, he has received the additional name "Adam". After God called so his first attempt, I can finally also do that. Whom a more rationale rather is: you can read Adam also as an abbreviation for Advanced Dual Arm Manipulator"- but this is now also not much more than an ambitious vision is...

A crucial component in a sense even starting point of this project is the robolink joint system of igus, with which I since about mid-2010 experiment. A robolink joint is two degrees of freedom available, a swivel and a rotary movement. The power transmission in the joint is done via cable. The actuators are spatially separated from the degrees of freedom in this and must not be moved. The joints can be connected via profiles so there offering to form a human-like arm from multiple joints. First of all, I have a four axle arm with drive developed, two arms with five degrees of freedom are foreseen for the A1. First an arm including motorization and adequate control should be however completed, once there everything works perfectly, also the second arm can be built accordingly.

A humanoid robot is of course sufficiently complex to provide a huge playground on different technical levels. Accordingly, the project has still a whole range of other construction sites, where I currently work in addition to construction, automation and control of arms. The sensor-head, a mobile head with some sensors and the possibility of the speech is relatively well advanced by the hardware. Also I'm going currently a gripper concept continue to work out, that I already here ever described in its basic features.

This project is of course, if the basic functionality of the torso are again interesting, then we can deal with the realization of - perhaps "intelligent" - behavior. The picture above indicates that (is however).

Here there is somewhat more detailed information to the described projects:

•  A1 sensor head
•  A1 robolink arms
•  A1 gripper

Project Information URL: http://www.mtahlers.de/index.php/robotik/humanoider-torso/humanoider-torso-a1

Also be sure to check out this blog post for an update on all things Microsoft Robotics by Stathis Papaefstathiou, General Manager, Microsoft Robotics.

Enjoy the Show!

John O'Donnell, ISV Architect Evangelist
Microsoft Corporation
http://blogs.msdn.com/jodonnell
http://blogs.msdn.com/usisvde
http://www.twitter.com/jodonnel

Enjoy the Show!

John O'Donnell Microsoft Dynamics ISV Architect Evangelist
Microsoft Corporation
http://blogs.msdn.com/jodonnell
http://blogs.msdn.com/usisvde
http://www.twitter.com/jodonnel

.

• Windows Phone Blog - Terry Myerson - Windows Phone 7 RTM'd
• Dave Anson - LayoutTransformer assembly enables WPF-style layout transformations in WP7
• Indy from Oz - Windows Phone 7 Listbox pagination with MVVM Light and Application Bar
• LessThanDot - Lazy DBA Series shows how to easily import Excel data via SQL Server wizards, via Alvin Ashcraft
• SDL Team blog - Microsoft Security Development Lifecycle to be licensed under Creative Commons
• IE Team Blog - Performance profiling different browser subsystems for popular Web sites
• Coding4Fun - Peter Brownstein & Peter Juchniewicz - Building WEIShare, the Windows and Web app to share Windows Experience Index scores
• Brad Becker - The Future of Silverlight
• Web Camps TV - OData Overview with Jonathan Carter 
• Rudi Grobler - Timeslot Panel - an Outlook-like Calendar, now ported to Silverlight

• Dan's pick: The .NET 4.0 MEF FAQ with hilarious drawings
• Brian's pick: Trossen Robotics - Interbotix Robot Turrets

Enjoy the show!

John O'Donnell Microsoft Dynamics ISV Architect Evangelist
Microsoft Corporation
http://blogs.msdn.com/jodonnell
http://blogs.msdn.com/usisvde
http://www.twitter.com/jodonnel

1. Project overview
2. Developing the phone application
3. Building the robot
4. Creating the phone user experience

Session WPH 314 – Coding4Fun: Learning Windows Phone 7 Development by creating a robotic t-shirt cannon!

We have a chicken or egg issue here. Do we talk about how to build the robot, or about the software needed to run it? Since the hardware choices directly determine how the software will be developed, we have to think about how to make the robot safe and at the same time functional. No one wants a 100lb robot with a pressurized co2 tank and armed t-shirt cannons running wild. This article won’t really talk about code, since that is a different, upcoming article; rather, this article will explain how to build the physical robot, code-named Betty. To find out about the Windows Phone 7 application, code-named Frank, wait for the next article.

WARNING:

This project deals with voltages and amperages that could hurt you and your electronics. Use voltmeters and common sense before randomly connecting and touching wires.

In this multipart article series, we’ll cover:

1. Project overview
2. Developing the phone application
3. Building the robot
4. Creating the phone user experience

Part 9c into Part 143B? What?

For a project like this, there are no real instructions. It is a custom project. If I was asked to build another one, chances are it would look different. I spent a lot of time drawing out and talking to people, figuring out how to get all the parts to play nicely. Only then did I go down to my local plastics place (I recommend TAPs Plastic in Seattle) to give them a technical drawing of what I wanted. The parts will vary depending on the look / feel you want. I wish I could give you part drawings that you could replicate, but I don’t think they would do you much good. What I will do, however, is give you a ton of pictures, which should point you in the right direction.

Research and development

Typically, I research parts and features to death. However, due to the two-week time constraint of being ready for the Mix conference, I went with what I knew worked for my previous projects while focusing on how to make Betty self-contained since requiring Betty to be plugged in would defeat the purpose of having her be a robot. The design of Betty was broken down into a few key parts: driving, aiming, shooting, brains, and power.

Primary part list:

• 1x – Battlekit medium kit with stock batteries
• 1x – Cisco Linksys gigabit wireless router
• 1x – 13” HP Envy laptop
• 1x – Phidget 0/0/4 Relay board
• 1x – Phidget Advanced Servo Controller
• 1x – Servo City Pan-Tilt 985 series
• 2x – Burst 175 T-Shirt cannons (with electronic solenoid values)
• 2x – Odyssey PC680MJ 12V 17AH Batteries
• 2x – Castle BECs (set to 6V) (Battery Elimination Circuit)
• 1x – Castle Pro BECs (set to 12V, has two outputs)
• 1x – 10lb CO2 tank
• 1x – Pressure valve (Able to adjust to 300 PSI)
• 1x – Serial port to USB Adapter

Driving a robot

Without knowing the weight of certain parts, I had to choose a base that could handle the load and be big enough to support everything I loaded onto Betty. From building random, previous robots, I knew of a company, Robot Marketplace, with a ton of internet parts, including full bodies. I decided a medium version complete with stock batteries and motors would fit my needs. The batteries are configured here in series to boost the voltage from 12volt to 24volt. The kit comes with an AmpFlow motor controller, which is actually a rebranded Roboteq controller. This connects to the computer via a serial to USB adapter. You’ll also have to get the Roboteq software to configure the motor controller to work off RS232 (Serial Port).

Shooting and aiming a t-shirt cannon

The cannons are Burst 175 T-Shirt cannons with electronic solenoid valves, allowing them to be fired with the Phidget 0/0/4 Relay board. The cannons are mounted onto a Servo City Pan-Tilt which is controlled by a Phidget Advanced Servo Controller. The pressure on the robot is fixed.

Having a brain and communicating

Since Dan and myself had features in the initial planning that could require heavy processing, we decided it was best to have a laptop control everything, though initially, ideas of using the .Net Micro-framework were put out there as well. We decided on a 13” HP Envy to be the brains of the operation. One thing we loved about this laptop is the extended battery, which snaps onto the bottom to give it a 14-hour life!

We used a Linksys wireless router for getting the phone and the laptop to be able to talk to one another. For the keynote, we had to leverage a wired connection, but we’ll typically use a wireless connection between Betty and Frank.

Powering everything

The battlebot kit comes with batteries to power the motors, but we still needed to power everything else. I went with 2 massive 12volt 17-amp hour batteries, which just barely fit the case, and I wired them in series to boost the voltage. This would give me the massive amount of energy needed to power all of the random electronics. Since nothing on this robot, other than the motors, runs at 24v, we adjusted the voltage. This is where the BEC (Battery Elimination Circuit) came into play. Here is the breakdown:

If you use different parts, you’ll have to pay attention to the voltages. This is one reason why I like the Castle BEC units, I could just alter the voltage instead of buying a new BEC.

I also highly recommend installing on/off switches. If you plug stuff in with this type of voltage, you’ll get sparks, which carbonize the plugs.

Building knowledge brain dump

To mount the top of the robot to the chassis, I had to get a drill press and drill the sidewall of the front and back plate. I decided to save some money and buy a low-end drill press for this, but having a higher end drill press would have made my life a bit less stressful. Drilling it had 1/16^th of an inch on either side to punch through. After drilling, I used a 10-24 tap to put in screw threads so I could use thumbscrews to mount the two together. The two plates were T-6 aluminum, so I used WD-40 to help lubricate both drilling and tapping. If you’ve never tapped a hole before, make sure you go a half turn in and then a quarter turn out. This helps break up the little bits of metal in the hole and so helps prevent the tap from breaking.

One thing to be aware of is the movement of the Pan-Tilt and how this relates to mounting the cannons. We had programmatic stops so the cannons didn’t go too far up or down or rip out any cords by rotating too much.

Another helpful tip is to use extra wire so you can move stuff around. Then, once you figure out final layout, either trim the extra wire or install entirely new wiring.

My final tip, and the tip to follow if you only follow one, is the following: use a Voltmeter before you connect anything together. I failed to follow this advice and had two wires switched, which reversed the polarity of the power. When I turned it on, I had a nice electrical fire break out, which destroyed 3 BECs. This was a hundred dollar mistake, which took a half-day to repair, and it could have been far worse. Verifying and re-verifying the voltage will not only keep you safe, it will keep you from having to buy new parts after explaining why the hallway smells like burnt plastic.

Hey, wait a second, you have a custom part!

Yes, yes I do. It is a part I made to help simplify the wiring on my automated bartender, drinktendr . It is designed to have a single power cord in, the positive wires go to the relay and back again, and have proper power cords go back out to the target device. You can wire this up without the board; it just will be a bit messier. If you want to get the boards created, the file for the PCB is in Codeplex in the source code area in the Files directory.

Pictures should help

I think the two primary areas that will help show the who/what/when/where/why/how are overviews of the top and of the cannon mountings.

Chassis

Cannon

Body Top

Why doesn’t mine look good yet?!?!

It takes time to get all the mountings and wiring installed correctly. We had to demo to the Gu using a robot that had wires all over the place! It wasn’t pretty, but the key thing is that it got the job done. Only after I got the functionality working did I shorten wires and do some cord clean-up. I stated this above, but I’ll reiterate the fact, that having longer wires helped me move stuff around while being able to adapt to new layouts.

Conclusion

Building two Betties was a fun and hard project. By leveraging past projects, we completed the project quickly without compromising functionality.

In upcoming articles, we’ll talk about how to program Betty, as well as how to get the phone to talk to her. Also, if I missed a section of building out Betty that you want me to cover, please comment and I’ll happily explain more of what I did.

About The Author

Clint runs Coding4Fun and is on the Channel 9 team at Microsoft. Clint has yet to have a project he can’t catch on fire J. If you need to get a hold of Clint, his email is clint.rutkas@microsoft.com, his personal blog is at http://www.betterthaneveryone.com and his twitter account is @ClintRutkas.

WARNING:

This project deals with voltages and amperages that could hurt you and your electronics. Use voltmeters and common sense before randomly connecting and touching wires.

In this multipart article series, we’ll cover:

1. Project overview
2. Developing the phone application
3. Building the robot
4. Creating the phone user experience

Part 9c into Part 143B? What?

For a project like this, there are no real instructions. It is a custom project. If I was asked to build another one, chances are it would look different. I spent a lot of time drawing out and talking to people, figuring out how to get all the parts to play nicely. Only then did I go down to my local plastics place (I recommend TAPs Plastic in Seattle) to give them a technical drawing of what I wanted. The parts will vary depending on the look / feel you want. I wish I could give you part drawings that you could replicate, but I don’t think they would do you much good. What I will do, however, is give you a ton of pictures, which should point you in the right direction.

Research and development

Typically, I research parts and features to death. However, due to the two-week time constraint of being ready for the Mix conference, I went with what I knew worked for my previous projects while focusing on how to make Betty self-contained since requiring Betty to be plugged in would defeat the purpose of having her be a robot. The design of Betty was broken down into a few key parts: driving, aiming, shooting, brains, and power.

Primary part list:

• 1x – Battlekit medium kit with stock batteries
• 1x – Cisco Linksys gigabit wireless router
• 1x – 13” HP Envy laptop
• 1x – Phidget 0/0/4 Relay board
• 1x – Phidget Advanced Servo Controller
• 1x – Servo City Pan-Tilt 985 series
• 2x – Burst 175 T-Shirt cannons (with electronic solenoid values)
• 2x – Odyssey PC680MJ 12V 17AH Batteries
• 2x – Castle BECs (set to 6V) (Battery Elimination Circuit)
• 1x – Castle Pro BECs (set to 12V, has two outputs)
• 1x – 10lb CO2 tank
• 1x – Pressure valve (Able to adjust to 300 PSI)
• 1x – Serial port to USB Adapter

Driving a robot

Without knowing the weight of certain parts, I had to choose a base that could handle the load and be big enough to support everything I loaded onto Betty. From building random, previous robots, I knew of a company, Robot Marketplace, with a ton of internet parts, including full bodies. I decided a medium version complete with stock batteries and motors would fit my needs. The batteries are configured here in series to boost the voltage from 12volt to 24volt. The kit comes with an AmpFlow motor controller, which is actually a rebranded Roboteq controller. This connects to the computer via a serial to USB adapter. You’ll also have to get the Roboteq software to configure the motor controller to work off RS232 (Serial Port).

Shooting and aiming a t-shirt cannon

The cannons are Burst 175 T-Shirt cannons with electronic solenoid valves, allowing them to be fired with the Phidget 0/0/4 Relay board. The cannons are mounted onto a Servo City Pan-Tilt which is controlled by a Phidget Advanced Servo Controller. The pressure on the robot is fixed.

Having a brain and communicating

Since Dan and myself had features in the initial planning that could require heavy processing, we decided it was best to have a laptop control everything, though initially, ideas of using the .Net Micro-framework were put out there as well. We decided on a 13” HP Envy to be the brains of the operation. One thing we loved about this laptop is the extended battery, which snaps onto the bottom to give it a 14-hour life!

We used a Linksys wireless router for getting the phone and the laptop to be able to talk to one another. For the keynote, we had to leverage a wired connection, but we’ll typically use a wireless connection between Betty and Frank.

Powering everything

The battlebot kit comes with batteries to power the motors, but we still needed to power everything else. I went with 2 massive 12volt 17-amp hour batteries, which just barely fit the case, and I wired them in series to boost the voltage. This would give me the massive amount of energy needed to power all of the random electronics. Since nothing on this robot, other than the motors, runs at 24v, we adjusted the voltage. This is where the BEC (Battery Elimination Circuit) came into play. Here is the breakdown:

If you use different parts, you’ll have to pay attention to the voltages. This is one reason why I like the Castle BEC units, I could just alter the voltage instead of buying a new BEC.

I also highly recommend installing on/off switches. If you plug stuff in with this type of voltage, you’ll get sparks, which carbonize the plugs.

Building knowledge brain dump

To mount the top of the robot to the chassis, I had to get a drill press and drill the sidewall of the front and back plate. I decided to save some money and buy a low-end drill press for this, but having a higher end drill press would have made my life a bit less stressful. Drilling it had 1/16^th of an inch on either side to punch through. After drilling, I used a 10-24 tap to put in screw threads so I could use thumbscrews to mount the two together. The two plates were T-6 aluminum, so I used WD-40 to help lubricate both drilling and tapping. If you’ve never tapped a hole before, make sure you go a half turn in and then a quarter turn out. This helps break up the little bits of metal in the hole and so helps prevent the tap from breaking.

One thing to be aware of is the movement of the Pan-Tilt and how this relates to mounting the cannons. We had programmatic stops so the cannons didn’t go too far up or down or rip out any cords by rotating too much.

Another helpful tip is to use extra wire so you can move stuff around. Then, once you figure out final layout, either trim the extra wire or install entirely new wiring.

My final tip, and the tip to follow if you only follow one, is the following: use a Voltmeter before you connect anything together. I failed to follow this advice and had two wires switched, which reversed the polarity of the power. When I turned it on, I had a nice electrical fire break out, which destroyed 3 BECs. This was a hundred dollar mistake, which took a half-day to repair, and it could have been far worse. Verifying and re-verifying the voltage will not only keep you safe, it will keep you from having to buy new parts after explaining why the hallway smells like burnt plastic.

Hey, wait a second, you have a custom part!

Yes, yes I do. It is a part I made to help simplify the wiring on my automated bartender, drinktendr . It is designed to have a single power cord in, the positive wires go to the relay and back again, and have proper power cords go back out to the target device. You can wire this up without the board; it just will be a bit messier. If you want to get the boards created, the file for the PCB is in Codeplex in the source code area in the Files directory.

Pictures should help

I think the two primary areas that will help show the who/what/when/where/why/how are overviews of the top and of the cannon mountings.

Chassis

Cannon

Body Top

Why doesn’t mine look good yet?!?!

It takes time to get all the mountings and wiring installed correctly. We had to demo to the Gu using a robot that had wires all over the place! It wasn’t pretty, but the key thing is that it got the job done. Only after I got the functionality working did I shorten wires and do some cord clean-up. I stated this above, but I’ll reiterate the fact, that having longer wires helped me move stuff around while being able to adapt to new layouts.

Conclusion

Building two Betties was a fun and hard project. By leveraging past projects, we completed the project quickly without compromising functionality.

In upcoming articles, we’ll talk about how to program Betty, as well as how to get the phone to talk to her. Also, if I missed a section of building out Betty that you want me to cover, please comment and I’ll happily explain more of what I did.

About The Author

Clint runs Coding4Fun and is on the Channel 9 team at Microsoft. Clint has yet to have a project he can’t catch on fire J. If you need to get a hold of Clint, his email is clint.rutkas@microsoft.com, his personal blog is at http://www.betterthaneveryone.com and his twitter account is @ClintRutkas.

Clint,

Scott Guthrie would really like to have a cannon on stage at MIX this year that would allow him to fire t-shirts into the audience.  […]  We thought it might be something that you could build based on the fun stuff you’ve done in the past. […] Do you think you could build something like that?  Do you have the time to work on this for MIX?

So the Coding4Fun team had two weeks to build two robots able to drive, aim, and shoot t-shirts during a MIX10 Keynote demo of unreleased software? Piece of cake.

The following info will explain the who, what, why, and how of the project in order to help you understand the project’s layout.

Picture by Vetala Hawkins - Filmateria Digital

In this multipart article series, we’ll cover:

1. Project overview
2. Developing the phone application
3. Building the robot
4. Creating the phone user experience

Say hello to my little friend

Mid-February, we were asked to build a t-shirt shooting robot for the Mix conference on March 15^th, 2010. This required us to pitch our vision and then research, build, test, and ship our project—all in about 3 weeks. After Scott Guthrie gave us approval based on our SketchFlow demo, we had to divide and conquer the application with only 2 weeks left to build the physical robot, the server software, and the phone software. And on top of all that, since we were consuming an unfinished product, everything had to have backup plans.

Delegating workloads

The work was broken up into logical sections:

• Server and Robot (Codenamed: Betty)
  • Clint Rutkas handled this part
• Phone (Codenamed: Frank)
  • Dan Fernandez worked on this
• The phone user interface
  • Web design company, 352 Media created the look/feel for us
• Camera / MJPEG stream
  • Brian Peek updated his code so it would work on pretty much any platform

But wait, if we had a super-secret project, how did Brian and 352 work on it? We told them they were working on Silverlight out of browser applications! We didn’t tell them it was for the phone! We’re sneaky like that.

Frank and Betty sitting in a tree …

So why did we use code names? Dan and I got a bit confused when referring to certain item ownerships and the codenames allowed us to chat about the project in non-secured areas so it just sounded like we were gossiping about two people, albeit in extremely nerdy conversations and extremely nerdy tones. If memory serves, I wanted to name the robot Frank after the character Frank the Take from the movie Old School, but Dan had for some reason already jokingly referred to the robot as Betty and so the flip-flopped names stuck. During development, Betty and Frank fought and had some communication issues—just like a real couple. You may see references to Frank and Betty in the source code or throughout the series of articles on this project. Just remember, Frank is the phone and Betty is the Robot.

Design decisions

At a conference like Mix or PDC, thousands of people cram into a single room, creating a massive amount of wireless interference. Keeping this in mind while considering the communications aspect of the project, we decided to have Betty make HTTP communication calls while physically wired into the network. This required us to have some type of web server on the robot. Given enough time, I’m pretty confident that I can get the entire robot working without having a computer onboard or being 100% phone powered but we had to be sure nothing would interfere with communication so wireless was out of the question.

Also, since this project was due in an extremely short period of time, a lot of component decisions were based on my past projects. We looked at network cameras that transmit H264, MPEG4, and MJPEG along with the idea of using live smooth streaming from the server onboard the robot. Basically, having a computer on Betty gave us more options in case something didn’t work.

Due to the time crunch, every part had to be either on-hand or off-the-shelf. Creating custom parts takes a lot of time. So basically, my rule was that if it couldn’t be shipped to me in two days, I’d find something different to accomplish the task at hand.

Throughout development, Dan and I met in a SCRUM meeting first thing every morning to figure out what we should get done that day and to discuss any issues that were occurring. Here is Dan’s whiteboard after one of the final meetings before we flew out to the conference:

Betty, you can be a real robot if you try

Betty had to do three tasks: drive, aim, and shoot t-shirts. We used an HP Envy 13” laptop to manage everything and here is the hardware list per task:

• Aiming:
  • Aiming was accomplished with the Servo City Pan-tilt and a Phidget advance servo controller.
• Shooting:
  • Shooting was accomplished with a Phidget 0/0/4 Relay controller, a drinktendr wiring board, and the t-shirt cannons.
• Driving:
  • Driving was made possible the battle-bot chassis by Robot Marketplace, which uses an Ampflow motor controller. This is the motor controller I used on my self-balancing skateboard project and I found out that it is actually a rebranded Roboteq motor controller. I highly recommend using the Roboteq software to configure and upgrade the firmware.

Here is the first time Scott got to drive the robot and fire off a few test shots at real-world pressure all via the phone.

Seriously, you built it in 2 weeks?

Yes, but we didn’t build just one. For redundancy, we had to build two Betty’s. If a part broke or something didn’t work, we had to be able to swap robots without anyone knowing. And for the record, I only had one very small electrical fire, which was due to a crossed wire. Having completed a few projects like this in the past, I knew what I’d get hung up and when I should ask for help. My experience completing previous projects also taught me which part vendors are the best.

The robot was under constant work and my desk / office was literally covered in wires and parts all the time. Since I had such little space, even the robots were covered in wires and parts! I cleaned up multiple times, but within an hour every square inch of space had some type of part on it.

Frank gets a tux for prom

Silverlight and WPF use XAML for the design aspect of the application. Since it allows for an extremely nice separation, XAML gives both the designer and developer great power in creating the application. Dan told the great folks at 352 Media what controls we were using and their Silverlight 3 final product was inserted directly for consumption with minimal change. In the User Experience and Phone articles in this series, we’ll go into more depth.

What it was:

What it became:

What is with the code?

Rather than risk breaking our code, we’re showing you the keynote rev in all its glory. Dan and I know we have some cleanup to do. We are the first to admit this. We were dogfooding the Silverlight on the Phone and issues of course came up. Due to this, our code may look a bit interesting in a few places.

For communication, you’ll notice some of the code looks like it is a WCF (Windows Communication Foundation) service, and this is because it was at some point. We liked the idea behind WCF since it allowed us to lock down the service and prevent someone from sending in outside commands. This also allowed us to create very segregated services that only dealt with the service we wanted. Aim, Drive, Settings, and Shooting each had their own and if we wanted to add in another, it was extremely simple.

But as we got to a point where we were giving the phone tools, we had issues getting it to work and so we had to adapt. We shifted to a simple web project and sent in commands. Rather than refactor stuff, since we thought stuff may be fixed in later builds, we consumed the project as a reference and treated our services as classes. We never did go back and check

The key projects are:

• Coding4Fun.Cannon.Phone
  • The phone application
• Coding4Fun.Cannon.Robot
  • Handles all direct hardware communications
• Coding4Fun.Cannon.WCF
  • This will be abstracted out to a new, non-WCF project. It creates a simplified command from the Phone and the web server. A quick example of this abstraction is with the servo code. The servos expect a certain value that isn’t an angle. With this abstraction, the phone can send in an angle and the servos then can do the translation into a value that is meaningful.
    Another big thing that needs to be added in to this namespace is capturing and sending back the photos off the web server. Right now, this logic is all contained in Coding4Fun.Cannon.Web.
• Coding4Fun.Cannon.Web
  • Handles all requests from the phone, it is basic ASP.Net website.
• Coding4Fun.Cannon.MVC
  • In case you want routes instead of query string parameters

Fins make a car go faster, right?

Building this application, we figured out some ways make our application to act faster. We also built out some cool utilities we found very useful in our application, we’ll be abstracting these out into a tool chest project shortly. We will discuss these performance solutions later on in the series.

Conclusion

I hope everyone enjoyed the project and is ready for a more in-depth look on how it was accomplished. This was a fun and exciting project that pushed us by the short deadline and complexity. If you have any questions, please post a comment and we will be sure to address them in the future articles.

Robocode just released a new version of their software which now allows you to use .Net coded robots

To download, head to http://sourceforge.net/projects/robocode/files/

John O'Donnell Microsoft Dynamics ISV Architect Evangelist
Microsoft Corporation
http://blogs.msdn.com/jodonnell
http://blogs.msdn.com/usisvde
http://www.twitter.com/jodonnel

The Micro Framework is one of the newest kids on the .NET block, but it does something really rather wonderful. It brings embedded development within the reach of any C# programmer. If you know C# and love Visual Studio, you can now get started building hardware and controlling it with your software. Moreover, it lets developers achieve one of their most cherished dreams, to control their festive lights using programs that they have written. This project shows you how to do just that and adds an extra magical feature, in that you can make all your festive lights flash red whenever I, Rob Miles, make a new post on that most famous of blogs, www.robmiles.com.

Actually, you can modify the code so that you can make your lights do most anything in response to an event that happens on the web. You could signal home that you are running late, send the weather forecast to your Christmas tree or explore any number of communication options. You might decide that this is so useful that you leave your decorations up all year round.

If you just want to play with the .NET Micro Framework and get a feel for how easy it is to create software for tiny devices you don't actually need to use any extra hardware at all. The project comes with a complete emulation of the lights display so that you can run the whole thing on your computer and learn how hardware and software can be made to work together without burning your fingers with a soldering iron.

However building the hardware will give you an understanding of how some simple electronic components can be controlled from C# and even how serial and parallel data transfer works. It is also great fun.

To get started you will need some hardware and some software. Let's take each in turn.

Hardware

Processor Hardware

The .NET Micro Framework lets you run C# programs on tiny embedded devices. There are a number of these available today, and they are getting progressively cheaper. You can base this project on any.NET Micro Framework device that has a network port and three or more output ports. The ones I'd recommend are:

• Digi Connect-ME: http://www.digi.com/products/embeddedsolutions/digiconnectme.jsp
• GHI Electronics Embedded Master: http://www.ghielectronics.com/embeddedmaster.php
• Devices Solutions Tahoe II: http://devicesolutions.net/Products/Tahoe.aspx

I built the project for Digi Connect board but the code can be customised for any of the above platforms. The beauty of the .NET Micro Framework is that you hardly need to change your program even if the underlying hardware is completely replaced. The only thing you will have to do is adjust the code to target different output pins. I'll flag this part of the program up when we get to it.

The project as supplied runs on a special emulator that runs on the PC and behaves like a .NET Micro Framework device with lights connected, so you can get started exploring the code right away.

Lights

I'm keeping things deliberately low voltage for this project. This means that kids of all ages can have a go at building the hardware without messing around with mains. The lights that I used were supplied as lines of twenty leds wired up as four strands of five leds each. All the leds in each strand were the same colour. The lights were fitted with a little battery box which held three AA batteries and a tiny controller. To get my display I simply removed the battery box and connected the strands to my hardware.

 
Figure 1: My Battery Powered Lights

You can do the same with any low power lighting kit that you wish to use. The drivers that I'm using can handle around 500 milliamps of continuous current and so you can connect a fair number of lights to each strand.

Buying the Lights

The lights I used can be bought in the UK from Lights4Fun: www.lights4fun.co.uk and are called "C-LED-4.5-M 20 Multi Coloured Battery Operated LED Fairy Lights". They are supplied with a battery box and controller that you can remove to connect to the Darlington drivers. I used an old 5 volt mobile phone charger to power the lights. If you search eBay for "led christmas lights battery" you should find plenty of suppliers.

Driver Hardware

We can't connect a .NET Micro Framework device directly to our lights. There are two reasons for this:

1. The Micro Framework device will not be able to switch the amount of current that we need to drive the lights themselves.
2. The Micro Framework device will not have enough outputs to control all the lights that we want to use.

This means that we need to make some hardware that goes between the processor and our lights. I actually don't see this as a problem. Making hardware is great fun, seeing something that you've built spring into life is very nice. The hardware we are going to use will provide a means by which we can control many hundreds of lights from a single Micro Framework board if we wish. It also has the ability to switch reasonable amounts of current, so you can use quite large numbers of lights if you wish. We are going to use two semiconductor components, a CD4094 Shift Register/Latch and a ULN2803 Octal Darlington Driver. A pair of these chips will allow us to control 8 outputs. If you want to control more outputs you simply get more chips and chain them together. For my version of the project I just used one of each chip, you can use as many as you like.The shift registers and Darlington amplifiers can be obtained in the UK from Maplin: www.maplin.co.uk. The chip numbers and part numbers as are as follows: QW54J 4094 Shift Register, QY79L ULN2803A Darlington Driver. In the US you can obtain the components and breadboard from Digi-Key: www.digikey.com.

Serial and Parallel Data

You might be wondering how we can use just three output lines to control lots of lights. We are going to do this by using the three output lines to provide a serial data stream which is converted by our hardware into parallel data that can be used to control our lights. This is a fundamental principle of digital electronics and is how, amongst many other things, computer networks transfer data.

We are going to use three signals which are called clock, data and latch. Each of these can be set high (a voltage is present) or low (no voltage is present) by the .NET Micro Framework device under the control of our software. The signals are connected to the clock, data and latch inputs of our CD4094 shift register so that the program can talk to it.

The clock line triggers the shift register to do two things:

1. Shift all the bits along to make room.
2. Sample the value of the data input and store this value in the space that was created.

To get a feel for how this works, take a look at Figure 2 below. It shows a shift register with a pattern of bits in it. The pattern is 01100001. Note that although this represents a number; it can also be regarded as a pattern of 0s and 1s in the shift register itself. The value 0 means 0 volts and the value 1 means some volts. These are the signals that will be used to control our lights. I'm going to call them 0 and 1 from now on. The Shift Register has Clock, Data and Latch signals connected and they are all set to 1. We can ignore the latch part of the chip for now.

Figure 2: A shift register and latch with some data in it

When the clock signal changes from 1 to 0 this causes the shift register to perform the two steps described above. First the data is shifted along to the right. Note that this means that there is an "empty" location at the start of the register, and that the right most bit in the register "falls off" the register and disappears. Figure 3 shows how this works.

Figure 3: Shifting along the values in the shift register

Once the shift has finished the shift register can copy the data signal into the empty bit at the left as shown in Figure 4 below.

Figure 4: Storing the new data bit

By repeating this process 8 times a program can load a new pattern of 8 bits into the shift register. Then it is time to latch the new value to control the lights. This is the point at which the lights will appear to change. When the latch value is changed from 0 to 1 this causes the chip to copy the value in the Shift Register into the latch, as shown in Figure 5 below.

Figure 5: Copying the shift register pattern into the latch.

The latch is required so that the lights will not flicker as the new patterns are shifted into position. Each of the bits in the latch is connected to an output pin on the CD4094 which is used to switch a particular light colour on or off.

We need to create some C# that will provide the appropriate sequence of signals. It turns out that using the .NET Micro Framework to achieve this is actually very easy. The displayByte method below sends an 8 bit value into a shift register and then latches it into the output. If you read through the code you can see how the clock, data and latch values are all set to true (high) or false (low) to first clock the data out and then trigger the latch to display the pattern on the lights. The input is an 8 bit byte value and the program uses a mask to pick out the value of each bit in turn and set the data output accordingly.

private static void displayByte(byte value)
{
    latchPort.Write(false);
    clockPort.Write(false);

    byte mask = 1;

    for (int i = 0; i < 8; i++)
    {
        if ((value & mask) > 0)
        {
            dataPort.Write(true);
        }
        else
        {
            dataPort.Write(false);
        }
        clockPort.Write(true);
        clockPort.Write(false);
        mask <<= 1;
    }
    latchPort.Write(true);
    latchPort.Write(false);
}

The dataPort, clockPort and latchPort variables are instances of the .NET Micro Framework class OutputPort, which provides a method called Write which can be used to control the state of the output signal. We will consider how these are created a little later in the article.

The sample code for this project comes with a software emulator of the CD4094 which shows how it works. Figure 6 below shows that a new pattern is in the process of being shifted into the shift register, while the lights retain the previous one in the latch. The Clock and Data signals are high and the next statement will drop the Clock signal to add the next bit into the new pattern.

Figure 6: The light emulator

This figure also shows that I have two bits in the pattern controlling a strand of each colour. You can single step through the displayByte method above and watch it perform this output.

You can use this technique every time you want to control a large number of outputs using a small number of output pins. The CD4094 has "daisy chain" inputs and outputs so that the devices can be connected in sequence. If I used two devices I could control 16 bits, with three I could control 24 and so on. This would require only minimal changes to the software.

Output Driver

The CD4094 device will produce a signal output, but it is not really powerful enough to drive things like lights. To do this we need an amplifier and the ULN2803 Octal Darlington Driver is perfect for this. It is packaged as a single chip which contains 8 pairs of transistors. Each transistor pair is wired in a "Darlington" configuration and can be used as a switch which is controlled by on output from the CD4094. When the transistors are turned on they allow current to pass through them and this will cause the lamps to light. The lights that I bought used a "pull down" arrangement to make them light up. All of the light emitting diode (LED) lamps had one end wired to a common line that was connected to the positive supply. To make the a chain of LEDs light the other end that controls that chain needed to be pulled down to the ground level. This is a common arrangement with lights like these. The ULN2803 driver has the transistors wired in an arrangement that allows it to pull signals low in this way. Figure 7 shows how this arrangement works. The resistor shown is actually wired into each LED in the set of lights that I used.

Figure 7: Lighting the LEDs

Complete Circuit

The complete circuit shown in Figure 8 simply links each output of the CD4094 shift register to an input on the ULN2803 Darlington Driver. Note that there is no reason to link any particular bit with any other, the diagram shown is one which will translate most easily to a prototype "breadboard".

Figure 8: The Complete Circuit

The diagram just shows four lights connected to OUT1 from pin 18 of the ULN2803, the other 7 channels are connected in exactly the same way. Some of the pins can be left unconnected. Pins 9 and 10 of the CD4094 are only required if you are connecting multiple shift registers together and the common connection on pin 10 of the ULN2803 is not required. The Latch, Data and Clock signals on the CD4094 are connected to the output signals from the Micro Framework device.

Figure 9 shows the completed circuit built up on a prototype breadboard. The chip on the left is the CD4094 and the one on the right is the ULN2803.

Figure 9: The Completed Circuit

The red wires carry the positive voltage from the power supply, which is connected to the top left of the circuit. The green wires are ground. Other coloured wires are used for signals. The Clock, Latch and Data signals are brought out to a connector which will fit a Digi-ME prototyping board.

Selecting Lights

Each bit in the value sent to the displayByte method and then into the shift register will be mapped to a particular chain of lights. The mapping of these is not particularly important, since you can use program constants to represent particular values. I wired the red signals to output pins 4 and 8. To light up just the red lights I used the value 0x88 which is the appropriate bit pattern. I then set up constants for all the other colors:

const byte GREEN = 0x11;
const byte BLUE = 0x22;
const byte YELLOW = 0x44;
const byte RED = 0x88;

Setting Up the Hardware

The .NET Micro Framework provides a set of classes that can be used to represent the hardware in a system. The program uses instances of the OutputPort class to represent the output pins. These are created in the method that sets up the hardware:

const Cpu.Pin clockPin = Cpu.Pin.GPIO_Pin0;
const Cpu.Pin dataPin = Cpu.Pin.GPIO_Pin1;
const Cpu.Pin latchPin = Cpu.Pin.GPIO_Pin2;

static OutputPort clockPort;
static OutputPort dataPort;
static OutputPort latchPort;

private static void setupOutputs()
{
    clockPort = new OutputPort(clockPin, false);
    dataPort = new OutputPort(dataPin, false);
    latchPort = new OutputPort(latchPin, false);
}

In this version of the hardware I have connected pin 0 of the processor to the clock, pin 1 to the data and pin 2 to the latch. If you use different pins you can change the settings above.

Software

Now that we have working hardware we can consider how the software is to work. Note that this version of the program works correctly but lacks exception handlers that would make it truly robust. I've left these out to simplify the explanation. To make sense of this description you will need to have a copy of the program itself available for reference.

You can develop the code using Visual Studio 2008 Express edition, which you can download from http://www.microsoft.com/express/

The software is written for the .NET Micro Framework 3.0 which you can download from http://www.microsoft.com/downloads/details.aspx?FamilyID=9356ed6f-f1f0-43ef-b21a-4644dd089b4a&displaylang=en

Reading the Blog

The program reads the RSS feed from a blog and looks for the <pubDate> value. This contains the date when the feed was last updated. Whenever this date changes the lights must flash red for a few seconds before resuming a random display. Users of the full .NET Framework can use the HTTPRequest class to build a GET command to be sent to a server. Unfortunately the .NET Micro Framework does not support this, so we have to access the web feed using socket based communication. This part of the program is heavily based on the SocketClient example supplied with the .NET Micro Framework.

// This method requests a page from the specified server.
private static String GetWebPage(String server, string webPage)
{
    const Int32 c_httpPort = 80;
    const Int32 c_microsecondsPerSecond = 1000000;

    // Create a socket connection to the specified server and port.
    using (Socket serverSocket = ConnectSocket(server, c_httpPort))
    {
        // Send request to the server.
        String request = "GET "+ webPage + 
             " HTTP/1.1\r\nHost: " + server + 
             "\r\nConnection: Close\r\n\r\n";
        Byte[] bytesToSend = Encoding.UTF8.GetBytes(request);
        serverSocket.Send(bytesToSend, bytesToSend.Length, 0);

        // Allocate a buffer to receive HTML chunks
        Byte[] buffer = new Byte[1024];

        // 'page' refers to the HTML data as it is built up.
        String page = String.Empty; 

        // Wait up to 30 seconds for initial data 
        // Will throw exception if connection closed
        DateTime timeoutAt = DateTime.Now.AddSeconds(30);
        while (serverSocket.Available == 0 && 
               DateTime.Now < timeoutAt)
        {
            System.Threading.Thread.Sleep(100);
        }

        // Poll for data until 30 second time out
        // Returns true for data and connection closed
        while (serverSocket.Poll(30 * c_microsecondsPerSecond,
                                 SelectMode.SelectRead))
        {
            // Zero all bytes in the re-usable buffer
            Array.Clear(buffer, 0, buffer.Length);

            // Read a buffer-sized HTML chunk
            Int32 bytesRead = serverSocket.Receive(buffer);

            // If 0 bytes in buffer, then connection is closed, 
            // or we have timed out
            if (bytesRead == 0)
                break;

            // Append the chunk to the string
            page += new String(Encoding.UTF8.GetChars(buffer));
        }

        return page;   // Return the complete string
    }
}

This method is called to fetch the journal RSS feed from my blog:

string address = "www.robmiles.com";
string name = "/journal/rss.xml";

string html = GetWebPage(address, name);

You can use it to download from any RSS feed or page on the web. It will throw an exception if the page cannot be read. This version of my program does not perform exception handling however.

Getting the Published Date

The date is held in the form:

<pubDate>Wed, 05 Nov 2008 22:38:52 +0000</pubDate>

It would be enough just to record this content and check for changes in the text, but I decided that I might want to use the date information in a later version of the program and so I created some small helper methods to read numbers from the input string and a larger method to read the publish date itself:

private static DateTime getRecentPubDate(string html, string startTag)
{
    int index = html.IndexOf(startTag) ;

    if (index < 0) 
        throw new Exception("Missing tag " + startTag);

    index += startTag.Length;

    // spin past the name of the day
    while (index < html.Length && html[index] != ',') index++;
    if (index == html.Length) 
        throw new Exception("Short publish date");

    int dayValue = getInt(html, ref index, ' ');

    string monthName = getString(html, ref index, ' ');
    int monthValue = getMonth(monthName);

    int yearValue = getInt(html, ref index, ' ');
    int hourValue = getInt(html, ref index, ':');
    int minuteValue = getInt(html, ref index, ':');
    int secondValue = getInt(html, ref index, ' ');

    return new DateTime(yearValue, monthValue, dayValue, 
                        hourValue, minuteValue, secondValue);
}

The main body of the program uses this method to extract the date out of the RSS feed. When a new date is found it is time to update the lights.

Lights and Threads

My first version of the program flashed the lights for a while and then checked to see if a new blog post had been made. This worked OK, but the process of loading the RSS feed from the server and checking the dates can take a few seconds, which meant that the flashing lights would freeze every now and then. This did not look very good, and so I decided to use two threads instead. One is in charge of flashing the lights in a random pattern and the other loads the RSS feed from my blog and checks the date of the most recent publication.

Note that the threading I am using is exactly the same as threading in the full .NET Framework.

Thread Communication

The two threads communicate by means of a single boolean variable which is set to true when the blog alert is to take place. The display thread reads this flag and flashes the lights red if it is time to alert.

public static bool alert = false;

public static void flasher()
{
    setupOutputs();

    while (true)
    {
        randomDisplay(400, 10);
        if (alert)
        {
            alert = false;
            flashRed(600, 20);
        }
    }
}

The methods randomDisplay and flashRed do exactly what you would expect. Each of them gets two numbers to control the lights. The first number gives the delay in milliseconds between flashes (a few hundred milliseconds giving best results). The second gives the number of times that the lights should be flashed before the method finishes. RandomDisplay displays random colors, whereas flashRed is simply flashes the red lights. The alert flag is cleared before the red lights are flashed so that the system will resume normal display after the alert.

The second thread in the system performs the blog download and date test behaviour. This all happens inside the Main method:

public static void Main()
{
    flashThread = new System.Threading.Thread(flasher);

    flashThread.Start();

    string address = "www.robmiles.com";
    string name = "/journal/rss.xml";

    String html = GetWebPage(address, name);

    DateTime lastUpdate = getRecentPubDate(html, "<pubDate>");

    Debug.Print("Initial Update Value : " + lastUpdate.ToString());

    while (true)
    {
        System.Threading.Thread.Sleep(10000);

        html = GetWebPage(address, name);

        DateTime blogUpdate = getRecentPubDate(html, "<pubDate>");

        if (!blogUpdate.Equals(lastUpdate))
        {
            Debug.Print("Updated at : " + blogUpdate.ToString());
            lastUpdate = blogUpdate;
            alert = true;
        }
    }
}

To reduce the load on the network the system only checks the blog feed every 10 seconds.

Future Work

The program itself works fine, but the error handling is not wonderful. Although some of the methods used throw exceptions these are not caught anywhere, causing the blog reading thread to terminate. This does not stop the lights flashing, but it does mean that there will be no more alerts. However, it is not too hard to create a version which contains proper error handling and even flashes the lights different colors to indicate the alarm conditions. I have created a version that flashes the lights yellow every now and then if the network connection fails. There is also considerable scope for reading other web based sources and changing the output accordingly. Feel free to do all these things and make sure that you have fun.

Thanks

Thanks go to Ian Mitchell of Ormston Technology (http://www.ormtec.co.uk/) for doing such a great job of hardware design and build.

RDS 2008

In the new version RDS 2008, there are now several new features, including:

• Increased runtime performance. Performance is improved 1.5 to three times faster in message throughput between services, and services now load two times faster. Developers can now also define more specific message communication between services, reducing network utilization and optimizing the processing of data.

• Improvements to the Visual Programming Language (VPL) tool. The simple drag-and-drop-based visual programming tool now includes a simple method for defining and configuring distributed applications, making it easier to create applications that can run across networked devices.

• Improvements to the Visual Simulation Environment (VSE) tool. VSE now includes the ability to record and play back simulations, which allows for easier review of simulation experiences. VSE also adds a new floor-plan editor to simplify the definition of interior structures, and three new sample simulation environments (apartment, outdoor and urban) that enable developers to better test their robot applications. Another new feature is support for importing content from DS SolidWorks^® 3-D computer-aided design (CAD) software and Microsoft trueSpace 3-D modeling software.

• Greater development flexibility. This new release provides support for both Microsoft Visual Studio 2005 and Visual Studio 2008, which makes it accessible to a broad audience of developers. Improved support for running VPL and VSE on 64-bit Windows platforms provides more flexible installation options.

Along with the new release, ABB, a supplier of industrial robots and robotics software, is offering a connectivity package known as ABB Connect to Microsoft Robotics Developer Studio 2008 (ACM). ACM lets robotics students work in a virtual environment in order to design and implement virtual robotics. The package contains all the services needed to build a complete virtual robot controller.

Challenges for Robotics Devs

So now that you have the software, what can you do with it? Visit RoboChamps, of course! At Robochamps, there are a series of challenges for developers which are based in simulation, thus removing the barriers to entry that normally exist when writing code for robots…things like cost and deep hardware knowledge, for example. RoboChamps is built on top of the simulation functionality provided in Microsoft Robotics Developer Studio 2008, which means that participants can program their robots using the .NET languages they are already familiar with.

For an example of one of the challenges you could compete in, check out The Mars Rover Challenge, where you get to navigate Mars collecting data.

Microsoft Robotics Developer Studio 2008 Standard Edition ($499.95 U.S.) is available at http://www.microsoft.com/robotics. Microsoft Robotics Developer Studio 2008 Express Edition will be available for no charge and downloadable from http://www.microsoft.com/robotics.

Check out the Microsoft ISV site for more information related to partnering with Microsoft.

House, Robot

Those of you who know me or who have read my previous Coding4Fun article Home Automation with Windows Workflow, know that I'm nuts about home automation. I'm even more passionate about robotics and I've wanted to try out some things with Microsoft Robotics Studio since the very first version. Recently I had a long weekend, so I spent a few hours putting together some simple home automation examples using Microsoft Robotics Developer Studio 2008 CTP April. Check out the Microsoft Robotics Developer Center for details on how to get the CTP.

The examples in this article duplicate what I did using Windows Workflow in my previous article, but instead use the Decentralized Software Services (DSS) approach of Microsoft Robotics, and Microsoft Visual Programming Language (VPL) for a simple way to write automation tasks. The Microsoft Robotics Developer Center contains a lot of detailed information about DSS, VPL, and the other technologies found in Microsoft Robotics Developer Studio. For now, let's just cover some basics. To get further along with the code in this article, you'll want to check out some of the excellent tutorials presented by the Microsoft Robotics team.

Services, Messages, and Ports

A DSS Service is the basic component upon which Microsoft Robotics applications are built. In fact, DSS services are a generic construct that can and have been used outside of the context of robotics. DSS services contain state and the service state is manipulated via messages sent to the service on a service port.

Messages sent to a service are structured .NET classes that may contain a message payload that determines how or even if state will be modified, or what part of a service state should be retrieved. There are also message that do not directly manipulate state, but may have some other side-effects. Services respond to messages such as CREATE, LOOKUP, UPDATE, etc. In addition, you can define messages that extend the semantics of the core messages.

Ports are the mechanism through which services communicate. Ports accept a set of message types that are defined by the service itself. In addition, ports are also used for outbound communication in situations such as subscribing to event notification from a service.

Again, there are excellent online resources for learning the details of Microsoft Robotics, DSS, and the underlying technologies for Microsoft Robotics developer Studio. You'll probably want basic familiarity with the Microsoft Robotics architecture including the Concurrency and Coordination Runtime (CCR) along with the notion of Arbiters and iterators.

Robo-Moose

The security and automation system in my house is centered on an Elk M1G alarm panel from Elk Products Incorporated . This panel allows for up to 208 input zones in the form of contact switches, motion sensors, and so on. It also allows for up to 208 outputs, on-board task scripting and many other features. One of the key features for my use is the capability of being able to monitor and control the panel via an Ethernet adaptor. So, my first order of business was to write a DSS service – the ElkService – to communicate with the Elk M1G via sockets. This ElkService exchanges messages with the Elk M1G via an ASCII protocol that is documented here.

The code that the ElkService uses to read from the Elk M1G hardware is shown below. Note that the code looks sequential, but is actually asynchronous. The StreamAdapter.Read method sets up a task to do an asynchronous IO operation and the line “yield return (Choice)ioResultPort;” returns this task to the runtime which is iterating over all tasks returned by ElkReader.

/// <summary>
/// ElkReader opens a socket connection to the hardware panel. It then
/// enters a loop that
/// </summary>
/// <returns></returns>
public IEnumerator<ITask> ElkReader()
{
    Connect();

    // Send a request to the Elk panel get a report of the entire zone status.
    SendElkMessage(RequestStrings.ZoneStatus);

    byte[] buffer = new byte[256];

    int bytesRead = -1;
    Exception ex = null;

     do
    {
        var ioResultPort = StreamAdapter.Read(networkStream, buffer, 0, buffer.Length);

        yield return (Choice)ioResultPort;

        ex = ioResultPort;
        if (ex != null)
            throw ex;

        bytesRead = ioResultPort;
        if (bytesRead != 0)
            ProcessRawElkMessage(Encoding.ASCII.GetString(buffer, 0, bytesRead));

    } while (bytesRead != 0);
}

When the ElkService receives a packet from the hardware panel, it converts the packet from a string to a custom message containing the raw sensor data and posts the message to the main port of the ElkService itself. For example, when the service receives a “ZC” message from the hardware, it converts this to an UpdateRawZone message that contains the raw data from the security panel. This happens in the method ProcessRawElkMessage. Here is a fragment of that code:

public void ProcessRawElkMessage(string message)
{
    string messageType = message.Substring(2, 2);

    switch (messageType)
    {
        case "ZC": // Zone status change
            var zoneState = new UpdateRawZoneRequest
            {
                Id = byte.Parse(message.Substring(4, 3)),
                State = byte.Parse(message.Substring(7, 1),
                              NumberStyles.HexNumber)
            };

            var updateZoneMessage = new UpdateRawZone();
            updateZoneMessage.Body = zoneState;

            _mainPort.Post(updateZoneMessage);
            break;
…

UpdateRawZoneRequest is the message payload and is used to send data about a zone change event to a subscriber. UpdateRawZone is the actual message type that is transmitted on the port for the ElkService.

[DataContract]
[Description("UpdateRawZone Request Message Payload")]
public class UpdateRawZoneRequest
{
    [DataMember]
    public byte Id { get; set; }

    [DataMember]
    public byte State { get; set; }
}


/// <summary>
/// Update Elk zone status
/// </summary>
[Description("UpdateZone request message")]
public class UpdateRawZone : Update<UpdateRawZoneRequest,
        PortSet<DefaultUpdateResponseType, Fault>>
{
}

The message processing code can also be written a bit more compactly as:

public void ProcessRawElkMessage(string message)
{
    string messageType = message.Substring(2, 2);

    switch (messageType)
    {
        case "ZC": // Zone status change
            var updateZoneMessage = new UpdateRawZone
            {
                Body = new UpdateRawZoneRequest
                {
                    Id = byte.Parse(message.Substring(4, 3)),
                    State = byte.Parse(message.Substring(7, 1),
                          NumberStyles.HexNumber)
                }
            };

            _mainPort.Post(updateZoneMessage);
            break;
…

UpdateRawZoneHandler is a message receiver that is active on the main port and which responds to the update message by updating internal state, and notifying subscribers of the change in state.

[ServiceHandler(ServiceHandlerBehavior.Exclusive)]
public IEnumerator<ITask> UpdateRawZoneHandler(UpdateRawZone message)
{
    _state.ZoneStates[message.Body.Id - 1] = message.Body.State;

    SendNotification(_submgrPort, message);

    message.ResponsePort.Post(DefaultUpdateResponseType.Instance);

    yield break;
}

In the Zone

The ElkService represents the core service that communicates with the Elk M1G hardware. The next service – ElkZoneSensor – represents a higher level “sensor array” that is attached to the Elk hardware. ElkZoneSensor “partners” with the ElkService. This means that the ElkZoneSensor relies on the ElkService to function. The DSS infrastructure will ensure that the ElkService is started if needed when starting the ElkZoneSensor service.

The ElkZoneSensor subscribes to updates from the ElkService for changes in the hardware zones. When these changes occur, the ElkService notifies the ElkZoneSensor which updates its state and notifies any of its subscribers. The ElkZoneSensor uses a higher level message – UpdateZone – that contains a sensor ID and an enumeration that describes the state of the sensor.

[DataContract]
public class Zone
{
    [DataMember]
    [Description("The Elk hardware zone id of the sensor")]
    [DataMemberConstructor]
    public byte Id { get; set; }

    [DataMember]
    [Description("The Elk defined state of the sensor")]
    public ZoneStatus Status { get; set; }
}

Candlepower

The next services that we need for the robotic house are services to control the lights. In this case, I started with a generic contract for the DSS service. A generic contract in DSS terms just defines the set of messages to which a service will respond and defines the port type on which those messages will be sent. The generic contract does not contain code to actually implement the service behavior. One of the benefits of a generic service contract is that you can specify the contract, write algorithms that use the contract, and later connect the generic service contracts to code that actually implements the behavior. This is very much like programming to an abstract interface in the object oriented world, and having multiple classes that actually implement the interface.

We start off with a generic service called the GenericDimmer that represents a dimmer switch and we implement two concrete services: the SimulatedDimmer and the ZWaveDimmer. SimulatedDimmer just logs a message to represent its state change. The ZWaveDimmer actually controls the lights via a hardware Z-Wave controller.

Here's what the GenericDimmer contract looks like:

namespace Robotics.GenericHouseControls.Dimmer
{


    /// <summary>
    /// GenericDimmer Contract class
    /// </summary>
    public sealed class Contract
    {
        /// <summary>
        /// The Dss Service contract
        /// </summary>
        [DataMember]
        public const String Identifier = "http://schemas.tempuri.org/2008/04/generichousecontrolsdimmer.html";
    }

    /// <summary>
    /// The GenericDimmer State
    /// </summary>
    [DataContract]
    public class GenericDimmerState
    {
        [DataMember]
        [DataMemberConstructor(Order = 1)]
        public int Id;

        [DataMember]
        public int Level;
    }

    /// <summary>
    /// GenericDimmer Main Operations Port
    /// </summary>
    [ServicePort(AllowMultipleInstances = true)]
    public class GenericDimmerOperations : PortSet<DsspDefaultLookup, DsspDefaultDrop, Get, HttpGet, On, Off, SetLevel>
    {
    }

    /// <summary>
    /// GenericDimmer Get Operation
    /// </summary>
    public class Get : Get<GetRequestType, PortSet<GenericDimmerState, Fault>>
    {

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get()
        {
        }

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get(Microsoft.Dss.ServiceModel.Dssp.GetRequestType body) :
            base(body)
        {
        }

        /// <summary>
        /// GenericDimmer Get Operation
        /// </summary>
        public Get(Microsoft.Dss.ServiceModel.Dssp.GetRequestType body, Microsoft.Ccr.Core.PortSet<GenericDimmerState, W3C.Soap.Fault> responsePort) :
            base(body, responsePort)
        {
        }
    }

    [DataContract]
    public class OnRequest
    {
    }

    [Description("Turn the switch on")]
    public class On : Update<OnRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }

    [DataContract]
    public class OffRequest
    {
    }

    [Description("Turn the switch off")]
    public class Off : Update<OffRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }

    [DataContract]
    public class SetLevelRequest
    {
        [DataMember]
        [DataMemberConstructor]
        public int Level { get; set; }
    }

    [Description("Set the dim level")]
    public class SetLevel : Update<SetLevelRequest, PortSet<DefaultUpdateResponseType, Fault>>
    {
    }
}

This code defines the contract only. Now to implement that contract we can run the DssNewService utility with the /implement switch and generate a service based on this contract. For example:

dssnewservice /s:SimulatedDimmer /n:Robotics.HouseControls.SimulatedDimmer /i:GenericHouseControls.Y2008.M04.Proxy.dll

will generate a new service called SimulatedDimmer in the .NET namespace Robotics.HouseControls.SimulatedDimmer. The service will have a stubbed out implementation of the GenericDimmer contract including service startup code, state, and stubbed out message handlers.

Here's what the main service file looks like for the simulated dimmer after I added logging to the generated methods. I've also deleted some of the using statements for easier reading.

using pxdimmer = Robotics.GenericHouseControls.Dimmer.Proxy;

namespace Robotics.HouseControls.SimulatedDimmer
{


    /// <summary>
    /// House Controls Service
    /// </summary>
    [DisplayName("Simulated Dimmer")]
    [Description("The Simulated Dimmer Switch Service")]
    [Contract(Contract.Identifier)]
    [AlternateContract(pxdimmer.Contract.Identifier)]
    public class SimulatedDimmerService : DsspServiceBase
    {

        /// <summary>
        /// _state
        /// </summary>
        [ServiceState]
        [InitialStatePartner(Optional = true)]
        private pxdimmer.GenericDimmerState _state = new pxdimmer.GenericDimmerState();

        /// <summary>
        /// _main Port
        /// </summary>
        [ServicePort("/simulateddimmer", AllowMultipleInstances = true)]
        private pxdimmer.GenericDimmerOperations _mainPort = new pxdimmer.GenericDimmerOperations();


        /// <summary>
        /// Default Service Constructor
        /// </summary>
        public SimulatedDimmerService(DsspServiceCreationPort creationPort) :
            base(creationPort)
        {
        }

        /// <summary>
        /// Service Start
        /// </summary>
        protected override void Start()
        {
            base.Start();

            // Add service specific initialization here.
            LogInfo(string.Format("Dimmer State => Id:{0} Level:{1}", _state.Id, _state.Level));
        }

        [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
        public IEnumerator<ITask> OnHandler(pxdimmer.On update)
        {
            LogInfo(string.Format("Simulated Dimmer => Id:{0} On", _state.Id));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);
            yield break;
        }

        [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
        public IEnumerator<ITask> OffHandler(pxdimmer.Off update)
        {
            LogInfo(string.Format("Simulated Dimmer => Id:{0} Off", _state.Id));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);
            yield break;
        }

        [ServiceHandler(ServiceHandlerBehavior.Exclusive)]
        public IEnumerator<ITask> SetLevelHandler(pxdimmer.SetLevel update)
        {           
            _state.Level = update.Body.Level;
            LogInfo(string.Format("Simulated Dimmer => Id:{0} Level:{1}", _state.Id, update.Body.Level));

            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);            
            yield break;
        }
    }
}

Check the code download for the implementation of the ZWaveDimmer. You'll find that it's pretty straightforward. It should be simple to write similar code if you use a different technology for lighting control. You just write a service that matches the GenericDimmer contract, and you should be able to configure the GenericDimmer using a manifest to point to the actual dimmer service. Check out the documentation in Microsoft Robotics Developer Studio for more information on manifests and how to use the manifest editor.

Bulb On, Bulb Off!

The “Hello, World” application for any home automation software that I've tested in my house has always been the automating of my pantry light. The pantry has a Z-Wave light switch inside and the pantry door has a contact switch that is connected to the Elk M1G. When the door is open, we want the light to turn on, and when the door is closed we want the light to turn off. Now that we have all the pieces for this, here's what the VPL diagram for this looks like:

As you can see, it was also a relatively easy matter to add text-to-speech to announce the opening and closing of the pantry door. You may find out quickly that this is an annoyance to those in the testing areas – for me that was my kitchen – so it's nice to know that two quick hits of the delete key will also remove the text-to-speech. This is part of the beauty of the Microsoft Robotics programming model!

The second example shows how you can use a motion detector – in this case connected to zone 19 on the Elk – to trigger a light. The light comes on at a level that you control from the VPL code, and stays on for a duration that you can also control from the code. For the example, I set the timer to a pretty low level, but you can customize it. You could also add additional rules to only turn on the light at certain times, or better still connect an ambient light sensor to decide whether you should turn the light on.

In this diagram, if motion is detected – that is zone 19 is triggered with a status of ViolatedOpen – the light is turned on at a low dim level and a timer is set. When the timer completes, the light is turned off. If, however, there is more motion before the timer completes, the SetTimer message will cancel the old timeout and restart the timer.

There are more VPL examples included in the download including an extra service that you can use to send email from your VPL code. I'm experimenting with using the email service to send me a text message whenever my alarm is armed or disarmed.

Miscellanea

Since I haven't had a lot of time to study the testing framework and simulation environments used by Microsoft Robotics, I included a service called the ElkTestDataPlayback service that allows me to replay the contents of a text file to simulate the ElkService getting actual data. This works pretty well for testing. The contents of the file are merely raw data captures that I made from the data sent by the Elk M1G panel. To use this service in VPL, you just drop it onto your diagram, configure it's TestDataFileName via “Set initial configuration” to point to a data file, and send it a message to start playback.

Important: If you have the Elk hardware, you will want to uncomment the SpawnIterator(ElkReader) line in the ElkService.Start method. I know this is a hack for now. It would probably be better to write a SimulatedElk service based on a generic service contract. If I have time, I will do that in the future. That would involve a lot more work than I had for this weekend project!

TODO List

Since this was my first foray into Microsoft Robotics Developer Studio and I had limited time to really explore the features in depth, there are a few things that I've left unimplemented. Here are some of the things that I would like to expand on in the future:

1. Support for more of the Elk features: Currently, I only support Zone Change notifications. Fuller support of the Elk hardware would not be difficult and would be beneficial to anyone wanting to use this on an ongoing basis. There's some stub code for a few other notifications if you want to add to the service.

2. Generic contracts for the Elk M1G: I didn't base the Elk services on generic contract because I'm not familiar with enough other types of security and automation panels to make the needed generalizations. It would be interesting to try to come up with something more generic. I thought about using the Generic Contact Sensor array, but I'm not sure that it models what we need. For example, a door contact is considered violated when it's open, but a water sensor is considered violated when it's closed.

3. Additional Z-Wave features: I've left out notification for lighting level changes, support for scenes and a host of other features. There's so much more that's possible with full Z-Wave support.

4. Refined Generic Contracts: Generic contracts allow developers to write code that is independent of the final hardware. That is one of the major benefits of the model used by Microsoft Robotics. You could for example have a generic light switch for simulation and testing, and based on configuration you could plug in a Z-Wave switch or an Insteon switch when it's time to deploy the actual solution.

5. Simulation Support: One of the major benefits of Microsoft Robotics Developer Studio is the simulation environment. For example, if we had a motion detector in the simulation environment, we could test some of the algorithms that I presented above by having a simulated mobile robot “violate” the motion detector's zone and trigger the corresponding VPL code.

6. Exception Handling: As I build more on the code in this article, I'll add exception handling and retry logic. Microsoft Robotics has some extremely robust features such as Causalities that make handling exceptions in a concurrent environment much easier.

7. HttpHandlers: I have a start at code for handling HTTP requests in the ZWaveController service. Handling HTTP requests is handy for building client applications that access your services without themselves having to be DSS services.

Other experiments that might be fun to try include integrating your Microsoft Robotics controlled home with remote control applications that are based on WPF or Silverlight, or perhaps integrating control from a Windows Media Center PC or Windows Home Server.

I hope you enjoy Microsoft Robotics Developer Studio as much as I have. I look forward to seeing what other people build with this fantastic technology. If people are interested, I can continue to share my home automation experiments. I think Microsoft Robotics Developer Studio will be the major tool in my home automation toolbox for quite some time.

Project Settings Note:

You will have to modify the project settings for the projects included in the House.Robot solution since your installation of Microsoft Robotics Developer Studio will be in a different directory than mine. The DssProjectMigration.exe command line tool will make short work of this. Just run it with a parameter that specifies the directory you want it to search, and it will find all of the project files in that directory and subdirectories and convert them to be buildable with your installation settings.

If you use the ElkTestDataPlayback service, in the examples, you'll need to set the path to the location of the test data file either in the initial configuration for the component, or in a manifest that configures the component. Make sure that you do not put quotes around the path name. I included a test data file from my system.