Newport News Shipbuilding Pipe Cutting Robot

Newport News Shipbuilding is the nation's only manufacturer of nuclear powered aircraft carriers, and one of only two manufacturers of nuclear powered submarines.  The Navy did a study about what areas of manufacturing could be changed to save the greatest amount of money, and the results showed that improving the way pipes were made would yield significant savings.  Submarines in particular contain a large amount of piping per tonnage of the vessel. The Navy mandated that the shipyard address this area as a high priority in plant modernization.  My part in this project was to provide a controller for an automated pipe cutting robot, interfacing with other company computers to obtain schedule and design data, and to handle all peripherals for part tagging and tracking.

Previously, all pipe in the shipyard was cut by an experienced pipefitter.  Consider when two pipes intersect at right angles. the contour of the joint is a circle in projection, but is has a saddle shape on the wall of the pipe.  In order to provide for a secure weld, the edges of each pipe must be given complimentary bevels, and while the angle is constant the orientation of the bevel varies around the cut. When done manually, this is accomplished in several stages. First, the pipe is cut to length.  Then, using the diameters of the two pipes in the joint (which can be different) a template for the cut is selected.  This is positioned in it's proper location from the end of the pipe.  The pipefitter cuts a hole in the pipe to the inside edge of the joint using an oxy-acetylene torch. Slag which adheres to the inside pipe wall must be reamed out.  Then, a grinding wheel is used to enlarge the cut and provide the proper bevel to the outside diameter of the joint, based on the thickness of the mating pipe.  When this operation is complete, the cut must be inspected to assure it is accurate and within tolerance. If the cut is outside of tolerance in any way, the pipe must be recut, or discarded and done over depending on the severity of the error. This is a difficult and time consuming operation even in the simplest cases.  When two or more branch pipes must meet at overlapping points on the trunk pipe, the complexity of the operation increases drastically.  The time and expense of producing and inspecting each cut, and the failure rate, goes up with the complexity.

To solve this problem, a five axis pipe cutting robot was selected.  The five axis were travel along the length of the pipe, rotation of the pipe (equivalent to rotation of the cutting head around the pipe), radial angle of the head in x and y, and distance of the head from the pipe center.  This high degree of freedom allowed any geometry to be cut in a single pass.  The cutting itself was remarkable clean, due to the physics of the plasma beam that the cutting head produced. Unlike the conventional flame that emerges from the tip of an oxy-acetylene torch, the robot used high voltage electricity to ionize the cutting gas, and then focus and emit this gas in a narrow beam, much like how a particle accelerator works.  The resultant plasma has an equivalent temperature of 50,000, far hotter than the chemical reaction of burning acetylene.  On contact with the pipe, the metal wall is vaporized without spending enough time in the liquid state for heat to flow through to adjacent areas of the pipe.  The pipe stays relatively cool, eliminating ripples at the cut line and producing a clean cut with sharp edges.  Further, sputtering of liquid metal is minimized, and is typically of such small size that it cools before encountering the opposite wall of the pipe, and so does not adhere.  The dusting of metal power could then be brushed out instead of being ground out.

There were some encountered problems with this robot.  Thin walled pipe and small diameter pipe could not be cut with this device, so the software filtered out any such pipes from being scheduled on the robot.  That was a simple issue to deal with.  More complex were the problems with electrically grounding the pipe, since the plasma beam deposited so much charge into the pipe.  Without good grounding, the current flowing through the pipe could cause arcing at any single point contact the pipe made with other conductive materials, causing undesirable pitting or spot welding.  The original grounding device was a set of conductive pads attached to expanding scissor joints, which we called the "Christmas tree."  This would be inserted into one end of the pipe and expanded until the connection was secure. This device was heavy, and could cause the other end of smaller pipe to lift off the rotating bed, or at least could skew the rotation rate unless it was carefully balanced. It also had to be places so that it was not directly under any cuts, lest it be damaged.  As a suggested improvement, I designed a grounding strap consisting of three layers or metal rollers, decreasing in diameter outwards from the pipe, held in place on the sides by pivoting plates and covered on top with a stationary fine metal mesh.  This could be permanently attached to ground at one end, and simply laid over the pipe and pinned to the chassis on the other end.  Two such straps at either end could hold the pipe to the bed even if an unbalanced force was somehow applied.  The rollers provided low friction contact, and distributed the electrical contact along multiple lines, hopefully enough to eliminate arcing.  I provided a detailed drawing of this strap to the technology team, but left the company before finding out if it was accepted and used.

Another concern was that due to security constraints, the link between the design mainframe and the robot controller was only allowed to be one way. This was solved by setting up the PC-based controller to appear as an RJE printer, preventing it from submitting any requests or commands to the mainframe.

The software for this project went together fairly smoothly from a technical perspective, but encountered some logistical problems. The Shipyard wanted a stand alone computer to control the robot directly on the factory floor, and yet a large mainframe was unnecessary.  Because the Shipyard had established purchasing relationships with IBM, they were the vendor selected.  The smallest system they had at that time was a Series 1, and this was selected for the project.  The Series 1 was normally used as a switching router in telephone concentrator nodes, so it was deemed suitable to handle the communications requirements of this project. This was not the best decision, and for other applications, it was an unusual choice. This made support for it problematic, as the operating system the computer used was not general purpose.  I attended special training classes in Atlanta on the system, and these convinced me further that computer maintenance was going to be one of the most difficult aspects on the project. Also, obtaining standard compilers for software development was a challenge.  I argued for implementing the project on a PC (an IBM AT with 128K RAM a 40 megabyte hard drive was the most advanced PC available at the time), but these were not considered serious computers by management, so my proposal was rejected. However, since the robot vendor was in California and the Shipyard was in southeastern Virginia, I was allowed a PC to use as a prototype platform to simulate the Series 1 on trips out west, and to simulate the robot for use in developing the Series 1. Further, since lead time on the purchase of the Series 1 was about four months, I could also use it to begin developing communication interfaces with our design mainframe.

Having developed rough simulators for these three components, it became apparent that in fact this represented a complete implementation of the project.  Interfacing these separate simulators together and polishing off the resulting code met all of the requirements of the robot controller.  Further, it was trivial to use the PC to drive the steel tag printer (a device that embossed thin steel plates about the size of a credit card with part number and control information that was tied to the pipe after cutting) and a paper printer for writing report logs on the robot's activity. This allowed the software development to be completed ahead of schedule and in a language that was commonly known by software engineers.  With these results documented, a new proposal was made to management seeking approval for using the PC as the project platform.  For the first time, representing a significant policy shift, a PC was accepted for use in a production environment at the shipyard. This decision should also have allowed the Series 1 to have been sold back to IBM for an additional savings of fifty thousand dollars, but unfortunately in the time between when the proposal was made and purchasing acted on the recommendation, IBM released a chipset that allowed a PC AT to act as a Series 1, and the resale value of the computer plummeted.  In any case, that did not change the cost effectiveness of the decision.

This robotics project had the potential to save the Shipyard large amounts of money very quickly by drastically improving their manufacturing methods, compressing schedule time and improving reliability, and reducing overhead.  However, there was one obstacle that resisted any technical solution. Union rules forbade the elimination of any jobs or the displacement of any workers due to automation.  This meant that additional robots could only be brought in when existing pipefitters left the company for their own reasons.  At an estimated annual savings of thirty million dollars per year per robot, these were eagerly anticipated.  However, due to the fairly high number of people working in this area, their relatively high turnover rate, and the cessation of training for this job by the Newport News Shipbuilding Apprentice School, additional robots were phased in within a few years of the project's completion.