October, 2010 – August, 2011
If information is the life blood of a modern corporation, then its Data Centers are the hearts. They vary in size, but all include racks arranged in narrow rows where equipment can be affixed. While doing work, Data Center equipment generates lots of heat. A combination of air and liquid cooling approaches are common. Effective monitoring of the temperature and humidity levels throughout a Data Center are critical for maintaining healthy equipment. The general trend is to increase power density which increases the heat concentration pockets within a Data Center. Therefore thermal design is one of the key challenges for any Data Center. Data Center power usage and thermal management will be the No. 1 infrastructure concern facing IT executives over the next three years. The trends of virtualization and consolidation offer many benefits, but only aggravate a thermal management issue because they increase compute density.
To address this issue, I built Mercury. Mercury is a low cost, autonomous robot designed to navigate through a Data Center and capture temperature and humidity levels throughout a Data Center environment so it can be monitored and compared with historical data. My first attempt
was a ground-based line following robot. This worked well, but had some limitations. My second attempt was to build a flying version that could adjust its altitude to capture the temperature at different heights in the data center room (including way up at the ceiling where the hot air collects).
Mercury v2 is based on the DIYDrones Arducopter. It is a quad-copter configuration to allow stable short-range flight for the sensor array payload. Mounted on the platform is an array of sensors that come with APM Autopilot module, along with some additional sensors for capturing the environmental data and navigation. I heavily modified the community contributions for the APM Autopilot configuration to meet my needs. Finally, it uses an Xbee Pro module for communication back to a central PC which captures the data and stores it in a SQL Server database.
Mercury v2 is designed to be autonomous and require minimal maintenance. It auto-launches on a pre-set schedule to automate capturing temperature and humidity data at different times of day. Once a run has concluded, it returns to a special docking station that uses gravity to help align the battery leads for re-charging. I’ve been successful in having Mercury run without any intervention over a period of 1 week. Longer duration are possible, but since I use this primarily as a short-term diagnostic tool for my clients, I’ve not had a chance to test beyond that duration.
Once the data has been captured, I use custom-built software to represent the data in a graphic heat map. I use color coding to help users quickly identify hot and cold spots, and allow the user to compare different runs to see how the thermal profile of the data center changes over time. Currently, this is a basic 2D image, and I’d like to eventually evolve this to show a 3D image.
One of the challenges with this design as the need to navigate indoors in a tight space. Without a line-of-site to the sky, GPS was not an option. I got the idea to use the Xbee mesh network in order to assist in the navigation. I place Xbee radio beacons at key places inside the data center to help the robot navigate to inside way-points. Mercury uses signal stregnth to navigate close to the beacon, and then an IR sensor for fine tuning. Once at a way-point, it performs a spiral manuver that captures the environmental data at different altitudes from floor to ceiling.
Another challenge was the inevitable bump/touch that happens whenever I fly in close proximity to an object. Added to that were the invisible, strong air currents that came from special tiles in the floor to circulate air inside the data center. To address this, I added a set of bumpers around the rotors (like the AR Parrot drone) and did some fancy coding to dynamically adjust the PID to achieve stable flight. I’ll admit that Mercury is not the most graceful thing inside the data center (more like a bull in a China shop), but it does get the job done.
A final challenge was capturing the temperature data itself. I started off using the same sensor in Mercury v1 – a LM335. Unfortunately, this was not responsive enough for my needs. It would require me to hover in one spot for several seconds to let the ambient air adjust the reading on the sensor which was not feasible. Also, I was concerned that the prop wash might be impacting the temperature readings. To solve this, I switched to an Infrared Temperature sensor. This gave me very fast and accurate responses, and enough range that I could scan past the edge of the prop wash to get an accurate reading on the computer rack.
With the support of my company, I was able to submit this idea for a Patent. The product became US Patent Pending in April, 2011, and EU Patent Pending in August, 2011. This was my first attempt at a patent, and I was grateful for my companies assistance in drafting the claims and submitting the paperwork.
I’m certain that I’ll continue to evolve this platform over time and include new features and functions to make it even better.
The Mercury project logo, created by my brother.
An overview of the gravity-assisted charging station
A screen shot of the result viewing software
A picture of the quad coter