Featured Project: RadPiper

Original Article By Josh Quicksall, Featured in Spring 2019 MSE Update

A clean-up is underway. But unlike household spring cleaning the tidying up in progress by the United States Department of Energy (DOE) poses safety risks somewhat more substantial than a back that’s thrown out while trying to vacuum behind the sofa. That’s because the DOE is in the midst of a decades-long decommissioning of numerous uranium enrichment facilities across the country.

Gaseous diffusion uranium enrichment was an essential process for the production of weapons and reactor grade fissile material for decades. However, its time has passed and the facilities that once produced uranium by this method are being demolished. But before demolition can begin every foot of piping has to be assayed to ensure that the amount of uranium 235 is below safety threshold levels.

Finding these uranium deposits, though, is a monumental task. At the DOE’s former uranium enrichment plant in Piketon, Ohio, workers have performed more than 1.4 million measurements of facility piping. It is expensive, time-consuming, and dangerous work.

A Challenging Build

As pitched by their clients in the Robotics Institute and the Department of Energy, the team had to come up with a solution that would allow onsite engineers to download and analyze data from 200 feet of piping.

And so they did, developing a system that downloads sensor data off the robot via a USB stick, interprets the raw sensor data, performs a series of analyses from which it can generate various reports, and then stores that report for future use in administrative and technical decision making or to feed other high-level systems in the PCAMS or DOE ecosystem.

Sounds simple enough, right? Not so fast.

One of the more significant challenges the team had to face when designing their solution was the constrained nature of working with a large, mature, regulated organization like the Department of Energy. “We really had to think on our feet. There were a number of constraints. For example, we had to figure out how to develop this on Windows – instead of our preferred OS, Linux – because that’s what the existing infrastructure ran on,” explains Mario’s Antony Durairaj. “The issue is that the data from the robot is in the rosbag format, which needs the Robot Operating System (ROS) to unpack. ROS works great on Linux but the version that the robot is using is not supported on Windows.”

After much experimentation and testing, the team settled on a fix that had the system running a ROS/Linux/Windows stack using Linux Subsystem for Windows to bridge the gap.

But challenges that arose from organizational infrastructure constraints weren’t the only thing keeping those five students up at night. “We had to interface the actual core computation code – given to us by the Robotics Institute – into our system,” Durairaj notes. “This is the core calculation sub-system that translates the raw data off the robot sensors into usable measurement data. This was code that we didn’t develop or maintain. It was entirely out of our hands. If we built in too many dependencies, even a small change on their side could break the system.”

But, not to be discouraged, the team addressed the challenge in the most efficient and clever way possible: insulate their system. “We put their code behind an interface. No matter what changes they make to their code, as long as it produces output in the interface’s specified format, our system can easily use it,” explains Mario’s Vaibhav Walia. “This way, now or in the future, we can decouple development work between the systems. It not only cuts down on the chance of miscommunication leading to system failure, but also helps teams work more efficiently since they don’t need to be keeping the other team so tightly in the loop.”