Monitoring a BBQ Smoker with a Pub/Sub Message System

by Mike Linnen 3. January 2010 20:43

At one of the Charlotte Alt.Net meetings I gave a presentation on how I utilized a simple Pub/Sub messaging architecture to allow for several applications to communicate across machine boundaries.  This blog post won’t be about that system I demoed at the meeting, but it will be about a suggested example that will get the Pub/Sub concept across in a simple way.

Requirements 

The system that is being built to demonstrate the Pub/Sub concept will fulfill the following requirements:

  • Simulate a BBQ Smoker
  • Monitor the temperature of a BBQ Smoker
  • Provide feedback at what temperature the Smoker is currently at.
  • Provide visual Alarm indicators that identify three states of the temperature
    • Low
    • Normal
    • High
  • Ability to have multiple smokers
  • Ability to have multiple monitors monitoring a single smoker

Pub/Sub Infrastructure

The Pub/Sub Infrastructure was taken from a previous MSDN article written by Juval Lowy.  The infrastructure uses WCF as the communications mechanism. The source code I have in my sample project might be a little different than what was in the original MSDN article so I will explain how it is organized in the Visual Studio Solution. 

First a little background on what makes up a Pub/Sub Messaging system.  A Pub/Sub Messaging system has three components: Broker, Publisher and Subscriber.

Broker

The broker is the enabler.  The broker’s job is to connect publishers with subscribers. The broker contains a list of subscribers and what messages they are interested in.  The broker exposes endpoints that allow for subscribers to subscribe to messages and a publisher to publish interesting messages.  In my example solution the broker is a WCF service that is hosted by a console application (Broker.ConsoleHost).  Since this is a WCF service it can also be hosted under IIS or a Windows Service just as easily.

The WCF Contract for messages that the broker accepts for the BBQ Smoker is as follows:

image    

Since the broker also manages what subscribers want to subscribe to a contract also exists for subscribers as follows:

image

Publisher

The only thing the publisher knows is that when it has anything to publish it simply sends the message to the Broker.  The publisher has no idea on the final destination of the message or if there even is a final destination.  This promotes a very decoupled system in that the publisher knows nothing about their subscribers.  In my example solution the publisher is the Smoker device and it publishes the, Smoker Alarm and Temperature Changed messages.  A Smoker Alarm message is published when the smoker reaches a temperature that is too low of too high.  A Temperature Changed message is published when the temperature of the smoker has changed at all. 

Since the Smoker Temperature is simulated by a slider on the UI here is the event that fires when the slider changes and publishes the Alarm and Temperature changed messages:

image

The _publish object in the above code snippet is simply a web service proxy that calls the broker.

Subscriber

A subscriber communicates with the broker to tell it what published messages it is interested in.  The subscriber in my example solution is the Smoker Monitor.  The job of the subscriber is to listen for Smoker Alarm and Temperature Changed messages and display information to the user when these messages arrive.  The Smoker Alarm message will turn the display Yellow when the temperature is too low and Red when the temperature is too high.  The temperature changed message will update the screen with the actual temperature that came from the smoker.

The subscriber needs to register the class that implements the interface (IMessage) that will be the callback that gets executed when either of messages are received.  In my example solution this is done in the constructor of the Form1 class in the Smoker Monitor project as shown below:

image

Additional logic exists in the SmokerAlarm (callback) method that sets the UI components to the proper color and text based on the alarm state as shown below:

image

Conclusion

Since the broker is capable of hooking up multiple subscribers to a single publisher you can run multiple monitors across multiple machines all monitoring the same smoker.  This is very powerful because the monitors could be providing the same feedback to the user just in a different location of the house or the monitor could be providing feedback via a different means. For example another monitor could be created that sent a text message or a twitter message when the alarm is published.  These new monitors can be added without changing the existing contract.  Even a third party could create a monitor that did some special thing on published messages and you could run their monitor without changing the broker or smoker.      

A zip that contains the entire code for the BBQ Smoker Monitor via Pub/Sub messaging can be found here.  Feel free to download the code and look at it in more detail.  Also take a look at the ReadMe.txt for additional information on how to run the application.

I hope to expand on this in a later project that will allow me to create an actual embedded device that can detect the temperature of a smoker instead of using a simulated Smoker Device.  This embedded device will have to be able to publish the messages to the broker so that a PC does not have to be connected to the smoker.

Tags: ,

Hero robot is coming back!

by Mike Linnen 16. December 2007 09:21

Heathkit was an awesome company that supplied electronic kits for educational purposes back in the 80's and 90's.  Their products where a bit on the pricey side but where else could you get a TV in kit form that you had to build.  I bought an Oscilloscope from them and put it all together in several weekends.  I also had a single board computer that was sold by Heathkit that I did not actually build but I used it for teaching myself how to program using machine(Assembly) language.

Well Heathkit is back in action and one of the best products they offered is also back.  The Hero Robot of the 80's is now called HE-RObot.  Back in the 80's you could get this robot in kit form or fully assembled.  I was never able to purchase one but I worked for a company repairing electronic equipment and the owner's son ended up getting one.  It was one of the coolest things I saw and it probably was one of the reasons I became so interested in robotics in the first place.  I don't remember all the specifics of the original robot but from what I remember it had sonar ranging, optical wheel encoders, light sensors, current sensors, and sound sensors.

Well the new Hero is a partnership between White Box Robotics and Heathkit.  The new HE-RObot comes with an onboard PC with an XP operating system and Microsoft Robotics Studio as the programming environment.  Finally a product is in the market place that combines both of my passion's: Robotics and Microsoft .Net.  This is a very powerful robot but I do not see too many details on what sensors will be offered.  On the web site it looks like it will include IR, Web Camera, and Audio.  I sure would like to see a few more details on what other capabilities it will have as far as sensors go. 

The web camera is going to be real powerful as a sensor.  I was fortunate enough to evaluate an ER1 robot from Evolution Robotics.  I wrote an article about this experience called 30 Days of ER1 back in 2003.  The live video pattern recognition routines put a whole new meaning to navigating your environment.  I am pretty sure White Box Robotics has licensed the software that handled pattern recognition from Evolution Robotics so the HE-RObot will have the same capabilities.

How to build a Maze Robot

by Mike Linnen 15. December 2007 12:48

Overview

The following article was originally posted by me on the Phoenix Area Robotics eXperimenters web site.  I moved the article here on my blog as I no longer belong to the Robotics group.  You can find the original article on the PAReX site.

Building a Maze Robot

My maze robot DR X took first place in BotBash’s 2000 Autonomous Maze competition. The competition consisted of three mazes with different configurations. The robot that completed all three mazes in the shortest time wins the event. Each robot had five chances to complete all three mazes. The shortest three times where summed up for the final score. DR X was the only robot able to complete all three mazes in the allotted time frame. This article was written as an attempt to explain the techniques used to allow DR X to accomplish first place.

There are several techniques that can be used in solving mazes:

  • Random
  • Wall Following
  • Mapping

Random navigation does not seem like a very elegant way to master a maze so my choices were mapping or wall following algorithms. Mapping a maze can be very difficult to do and this competition did not really reward such a task. So that leaves wall following as the best bet to complete the maze.

Wall following can be best explained by imagining yourself in a maze with your eyes closed. If you could place one hand on a wall and never let the hand leave the wall you will eventually find the end of the maze as long as the finish is not an island in the middle of the maze. It is very important to follow only one wall until you reach the end.

The following drawings show right and left wall following paths for a given maze.

wallfollow

Notice that in some cases it is better to choose one wall to follow over another. Here the shortest path from start (S) to finish (F) is via the right wall. So it is good practice to be able to command your robot to follow one wall over another before it is set in the start box. This can be accomplished by using the left and right bumper switches. Tapping the left or right switch before the start commands the robot to follow the left or right wall.

So I set out to build and program a maze robot to follow one wall. I choose to use a differential drive system on a round body. This would allow me to control the robot rather easily and prevent it from getting hung up on maze walls. I mounted two GP2D02 IR Sensors on a single shaft on top of a servomotor. The sensors were positioned 90 degrees apart. The servomotor allowed the robot to look straight ahead and the left or right wall at the same time.

DR X First Prototype

drxPrototype

In order to tell if the robot was getting closer or further away from a wall a minimum of two sensor readings would have to be taken over a period of time while the robot was moving. I had some difficulty in fine-tuning the reactions needed to prevent the robot from touching the walls. I quickly realized that this sensor arrangement had some shortcomings. I needed to be able to look at a wall and determine if the robot was parallel to it without moving forward. If I could achieve this, the robot would always start off parallel to a given wall. So I made some sensor placement changes that would not require the robot to be moving in order to determine if it was parallel or not.

DR X Second Prototype

drxPrototype2

I found out some other advantages of this sensor arrangement. While the robot was following a wall and it approached a doorway of the maze the first sensor would detect the opening (doorway) very easily. Once the second sensor detected the doorway I knew the robot was directly in front of the entranceway. A 90 degree turn towards the entranceway would position the robot perfectly for passage through the door. Passage through the door would also be easily detected. As the robot moved forward, the door jam could be detected by both sensors. The robot could successfully determine when a door was found and navigate through the door rather easily.

The following drawings show the robot navigating through a doorway.

The robot approaches the doorway

door1

The robot passes the doorway

door2

The robot turns left 90 degrees

door3

The robot moves forward into the doorway

door4

The robot is almost through the doorway.

door5

The robot is through the doorway.

door6

DR X Front View

drx_front

DR X Side View

drx_side

Improvements

Well this solution certainly has room for improvement and it is not the only way to solve a maze. One major enhancement that I saw was DR X needed a sensor that could look in front of the robot while it was attempting to follow a wall. This would have prevented the robot from having to collide with a wall before it realized it needed to stop and turn.

Conclusions

Well this project sure was a gratifying experience. To watch my little creation navigate the maze was a great thrill. A lot of last minute hard work went into this robot but come event day it all paid off.

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List