Mercury v1

July, 2010 – October, 2010

I had this idea rattling around in my head for years.  After building a few robot kits, I thought I’d take a shot at building one of my own designs.  I knew I still had a lot to learn about robotics, so I researched and invested in the Stinger kit from Robotics Connection.  These guys had already figured out all the tough stuff about how big the motors should be, how to mount them, all the RF electronics, etc.  This allowed me to focus on the software programming.  I selected the Robotics Connection platform primarily because they published a .NET API set and met my budget.

My idea:  Build a robot that roams around a computer data center to capture temperature and humidity data from various points around the data center and send them back to a database where it can be graphically represented for the operators.  The robot was self-charging, so could be scheduled to run multiple times per day to get a profile of the data center over time as equipment was added/removed and as they ran at different loads at different times of the day.  My thinking was not to mass-produce this robot, but to use it as a consulting tool for health-check purposes for my clients.

I came to learn that the #1 problem facing CIOs in the next 10 years will be thermal management inside data centers.  Once upon a time, companies were worried about rack space capacity inside data centers.  However, thanks to virtualization, and high-density server blades, this was no longer the primary concern.  The primary concern became providing enough power to run these high density compute platforms.  With increased power came the problem of highly concentrated heat generation.  We began borrowing power from adjacent empty racks to feed the needs of the equipment.  Data center just weren’t designed for this kind of configuration.  The result is intense hot-spots within data centers that can cause major issues if cool air is not circulated properly.  While the huge chillers that provided the cool air to the equipment had thermostats, they were always positioned on the periphery of the data center floor and could not get an accurate gague on the actual heat signature of a data center.  Distributed temperature sensors are available, but are expensive and introduce challenges.

My robot, named Mercury, in reference to his thermal sensing capabilities, could provide a visual representation of the thermal characteristics of a data center at a tiny fraction of the cost of the distributed temperature sensor solutions available on the market.  Not to mention the “wow” factor of having robots scurrying about inside the corporate data center.  🙂

So, I proceeded to assemble Mercury using a variety of components from Robotics Connection:

  • Stinger Chassis which included the wheels and motors with build-in encoders
  • Main board
  • Line following I2C sensors
  • A pair of XBee Pros for mid-range wireless communication
  • The push-button IO board

In addition, I source the following components from other stores:

  • A sonar range sensor (used to detect obstacles and avoid collisions)
  • 3 Ambient Temperature sensors (mounted on the mast)
  • 1 Ambient Humidity sensor (mounted on the mast)
  • A bunch of LEDs (mounted on the mast for safety)
  • An aluminum flange (for mounting the mast to the robot chassis)
  • A magnetic sensor
  • An extendable aluminum pole (the mast)
  • A rechargeable battery
  • HDPE – 1-foot square panel – I used this to build the automated charging station.

The automatic charging station was quite novel.  I used the HDPE platform to hold a pair of copper strips straddling the black line the robot followed.  I strategically placed a magnet to one side.  So, you put this plate down in line with the robot’s path.  He uses his line-following sensors to drive up on top of it.  When he senses the magnet, he stops. The magnet stops him right over the copper strips which connect to a matching pair of strips under the robot.  Mercury knows to stop moving and let the battery recharge for a period of time before auto-launching for another trip around the data center.

I then went to work building the “brains” in Visual Basic .NET and SQL Server 2008.  I built 2 main apps:

1.  Mercury Controller- reads the sensors, automatically navigates, allows manual override, uploads the data to the database

2.  Mercury Viewer – reads the database and displays the results of the robot’s data collection.

After a lot of testing and fine-tuning, I took it into my office and tried it in our mini-data center, and…  it worked!  Holy cow!  It got a lot of attention at work and I was strongly encouraged to patent the idea.  After some research from my company’s patent lawyers, they concluded that a patent already existed that might cover something similar a few years back.  They were concerned that the Patent Office would reject the patent due to the fact it was an obvious extension of a product already patented.  I read the existing patent closely and just didn’t see it – mine was autonomous and theirs was a cart that was manually positioned.  So, I pitched another idea to the patent lawyers and they agreed that it was different enough to be patented – so, the idea for Mercury v2 was hatched.  I’ll share the rest of the story in the next post.

DSCN0734 DSCN0733 DSCN0732    DSCN0735Mercury ViewMercury SoftwareMercury Control

Advertisements

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s