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.
“Because of what we experienced in this project, it just cements my belief that if you just hack out code, you’re never going to be as reliable as those who have a good process and follow it in a disciplined way.”
- Kenji Yonekawa (MSE '18), Team Mario
RadPiper and Mario
That’s about to change with a project by CMU Robotics Institute: RadPiper. Employing a new "disc-collimated" radiation sensor invented at CMU, the robot crawls through facility piping and takes detailed measurements of 235U contamination, allowing engineers to identify the segments which must be decontaminated and those which can be left in place for demolition.
While the sophisticated robotic platform and sensor array developed by the Robotics Institute (RI) performs its task flawlessly, the platform is not useful without some way for human engineers and project leaders to review, analyze, and store data from the robot itself.
Enter Team Mario, the five-man MSE team tasked with developing a solution to this problem.
After a presentation by the CMU project lead, Dr. Red Whittaker, team members Abdulwahab Almorebah, Antony Durairaj, Bharath Hegde, Vaibhav Walia, and Kenji Yonekawa chose to sign on.
“It was the most exciting project of the bunch because this was a system that was going to be used immediately in a practical setting,” explains Hegde. “RadPiper was actually going to be out there in the world making this task – which is pretty dangerous and time-consuming – significantly safer.”
But moreover, the project had potential far beyond the confines of the MSE program or even CMU. “As Red [Whittaker] was talking to us about the project, it was clear that if this is done right the technology has the possibility of not only helping people but also possibly growing into a real commercial product,” notes Team Mario’s Vaibhav Walia. “There is literally nothing else like this on the market. Being a part of getting this product off the drawing board was really exhilarating.”
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.”
Feel like you are facing down a monumental challenge on the scale of decomissioning a nuclear power plant?
Thats okay: Our student teams love a challenge.
Looking Back
But fast forward to fall 2018: The team is all but finished with their work and those late nights tooling with possible solutions to those challenges are behind them. The RadPiper platform is undergoing its testing at the Piketon site and the members of Team Mario are eagerly looking forward to their graduation in December.
For Kenji Yonekawa, while the exposure to robotic systems was interesting, what he believes he’ll carry with him throughout the rest of his career has less to do with the technology than it does the way in which large development projects are executed. “At the end of the day, we were able to deliver everything we said we were going to not because we’re better programmers but because we thought through the process, we tracked, we documented,” Yonekawa explains. “Because of what we experienced in this project, it just cements my belief that if you just hack out code, you’re never going to be as reliable as those who have a good process and follow it in a disciplined way.”
And while the value of a well-refined, nimble process is not missed by his teammates, Abdul Almorebah points out that it is not just in the process or the tooling that he believes he learned the most. “I am now a firm believer in reflective practice. After every big milestone, we’d sit down and really dig deep on what we did, what worked, what didn’t, and how we can do better the next time,” says Almorebah. “Combining that with good data-gathering practices meant that we were able to demonstrate continuous improvement over time. That's a pretty powerful way to build a product and earn your customer’s trust. I can see that and so many other things I’ve learned here in the MSE serving me really well in the years to come.”