Driving robots around a field of obstacles might look like fun. But for soldiers in combat, those robots perform the dirty, dusty and dangerous jobs that save lives. As engineer Francis Govers of Elbit Systems says, "Sometimes we manufacturers of ground robots get accused of making toys, but our robots provide soldiers in Afghanistan and Iraq with a first line of defense against improvised explosive devices. We must create a high-quality product, so we take our work very, very seriously."

The increasing demands for sophisticated military robots ratchet up the pressure on designers and manufacturers. To help learn how design teams handle the need for fast turnaround of complicated equipment, engineers at five companies share their insights.

At Howe and Howe Technologies, entrepreneurs Mike and Geoffrey Howe started with a personal project: design the fastest tracked vehicle. Their unmanned Ripsaw vehicle drew the attention of DARPA and led to government funding. And the Army's Armament Research, Development and Engineering Center has started to "weaponize" the company's Ripsaw robots.

"At the start of a project we ask, 'Can we do it? Do we have enough money?' and 'Has someone done it?'" says Geoffrey Howe. "If someone already built a similar device, we won't pursue the idea. We design and build robots that interest us rather than build to a requirement or spec. Then we find a use for them. After we go through a proof-of-concept step, we move our ideas into CAD tools. Our engineering department prefers SolidWorks; the U.S. government prefers Pro/ENGINEER."

Howe and Howe also uses ANSYS tools for simulation and modeling. "We can take, say, half-inch plate steel and apply a force in any direction and determine the yield strength, the break strength and get a 3-D graphic that shows possible failure points," says Howe. "After we model a design and run simulations, we build a prototype and test it to full failure. Computer models provide useful information, but what happens if you hit a rock and the force vector doesn't come in at the angles you simulated? That's why we always run live tests."

On the software side, engineers at Howe and Howe don't create reams of programs in C/C++ for custom controllers. Instead, they use industrial programmable logic controllers (PLCs) and off-the-shelf control equipment along with the RSLogix 5000 programming software from Rockwell Automation.

"People say, 'You use PLC-based logic for robots?'" says Howe. "They have 20 interns writing code for embedded controllers. But when you visit a factory or production line, you see standard PLCs. They're almost foolproof, and thousands of PLC people could quickly get up to speed on one of our systems. We tested our PLC-based robot at the Aberdeen Proving Ground and during four months the PLC never experienced an unintended command."

"At Remotec, we don't do a lot of simulation at the start of a project," explains Phil Bryan, technical advisor to business development. "Instead, we use a CAD system such as Inventor or SolidWorks to create a conceptual model so a customer can see several ideas. We can animate a model to test movements, locate centers of gravity, determine potential weights and so on. CAD packages now provide software that can create those types of animations. Then we and the customer pick the concept that seems most reasonable to take to a preliminary design. But it's still only a paper model; we haven't cut any metal." Remotec, a Northrop Grumman business, created the ANDROS explosive-ordnance-disposal robots used by the military and police bomb squads.

"At that point we have a good feel for how the robot will operate, how much it will cost and how much it will weigh," says Bryan. "Then we'll go back to the customer with the revised design. We spend a lot of time addressing key performance parameters in the original specs."

"We get to a point where the electronics becomes a key factor in a design," says Bryan. "When we plan to include electronics inside a motor housing, for example, our team assigns a size-and-weight budget for the electronics. As often as possible, we look for commercial off-the-shelf electronics. Say the electrical engineers find a motor controller with a reasonable price and size. That provides a starting point for interaction of the mechanical and electrical engineers. Then they are in constant communication."

According to Bryan, even with top-notch CAD tools, final documentation requires a lot of work. "We still have to create a final technical data package so an assembler in a factory knows to put screw A in hole A on a robot. Engineers know how to build a prototype so they don't need that level of detail. We try to treat our factory people like customers halfway around the world so they have adequate documentation. On the other hand, we don't want to create detailed documentation too early for a design that might not go to production. It's a challenge."

Elbit Systems of America manufacturers many autonomous vehicles and military robots, including the Beagle, which operates as a reconnaissance vehicle and in situations that involve chemical, biological, radiological, nuclear and high explosive (CBRNE) hazards. At the start of a robotic project, Govers, Elbit's director of advanced programs, relies on his experience in the motion picture industry. "When we started the Beagle project I drew what I thought the robot should look like, with tracks and an arm. Then I used Lightwave 3D, a polygon modeler and visualization tool normally used for movie and TV show production, to design a prototype."

"Lightwave lets us do all the sensor modeling we can't do in SolidWorks," he says. "Say you have a 35-mm camera with a 52-mm lens that has 7-foot focus range. You can type in those values, mount the camera on the robot and see exactly what the robot camera sees. It takes just seconds. So you can quickly create and test the things crucial to the robot's design. The Lightwave model helps you answer questions such as, 'Where do we put the cameras and the sensors, are they high or low enough?' And you have a high-quality animation that shows the results."

In addition to creating a robot model, Govers also built a 3-D house and drove the robot through it. "I had it look into trash cans, peer over a countertop, see into a sink and look under a bed. It took only two days to create the model on a Dell laptop."

Govers could be a bit loose with dimensions in Lightwave, but not in SolidWorks. "That was the secret of Lightwave - I can eyeball the whole thing and say, I want a section to measure about 18 inches long, about five inches high and so on. We did that sort of thing quickly in Lightwave and had something to try. Then we would go back and fine-tune the dimensions before we put them into SolidWorks, which is a solid-object modeler."

"My mechanical engineer, Connor Meehan, and I used a lot of 3-D prototypes produced for us by Stratasys," says Govers. "They make fused deposition modeling (FDM) systems, and their materials were strong enough to make production pieces. So we rapidly prototyped all the plastic parts: camera housings, pieces for the robot arm, elbows, connection boxes and so on. Stratasys has a subsidiary, RedEye, that creates parts on demand. We sent them a SolidWorks file and two days later we had the part."

"We had some help with the chassis from a company called The Machine Lab," says Govers. "They produce an off-the-shelf rolling chassis and we added all the parts that make it a robot. Basically, we went from a paper concept to a running robot in under 60 days."

Engineers at QinetiQ North America have designed the Talon family of military robots that handle explosive-ordnance disposal (EOD), CBRNE, hazmat and SWAT operations. These engineers rely on a variety of design tools. "We create mechanical designs in Pro/ENGINEER and when essential use the ANSYS toolbox for finite-element analysis," says Dan Deguire, senior program manager for unmanned systems. "Our electrical engineers use PSpice to simulate circuits, OrCAD for schematic capture and PADS for PCB layout. Usually we move quickly to a prototype of electronics system so we can run emulators and start unit-level tests."

"If our mechanical engineers have concerns about electromechanical actuators, servo control systems or other subsystems, often we'll fabricate test apparatus to do a proof of performance before we integrate something into a formal system design," notes Deguire. "It's sometimes difficult to bring everything together for the first time because of all the design trade-offs. A robot can't weigh too much, for example, but its batteries must be large enough to supply power for a specified time."

"We have used Simulink to model a system such as our powered fiber-optic reels," says Deguire. Those motor-driven reels must pay out fiber-optic cable and reel it back in under control of a cable-tension sensor. That complex electromechanical system must work in the worst possible environments."

Deguire has two requests for design-software companies. First, simplify the design of wiring harnesses. "When it comes to packaging wiring harnesses for a moving vehicle, things become difficult," says Deguire. "Pro/ENGINEER has a wire-harness toolbox, but it has a long learning curve and if you don't stay proficient in it, you have to get back up to speed for each new project. We can't justify dedicating an engineer to harness design full time."

Second, ease the movement of bill-of-material (BOM) information from one software tool to another. "All our electrical and mechanical CAD systems generate incompatible bills of materials," says Deguire. "And we still have to transfer the BOM information into the company's enterprise resource-planning (ERP) system for material resource planning and inventory control and tracking. Unfortunately, it often becomes a manual task."

"Before we start to design a robotic system, we might go to a simulation," says Hiten Sonpal, director of engineering at iRobot(R), which manufactures the iRobot Warrior and PackBot. "A customer could ask for a system that will look over a 2-foot-high table and climb stairs eight inches tall and 10 inches wide. Those types of specifications require a simulation that also addresses where we place actuators, the size of the head of the robot, the width of the wheel base and so on. Simulation lets us understand how the system will shape out."

"We generally use a physics-based simulation tool such as Open Dynamics Engine, an open-source, high-performance library for simulating rigid-body dynamics," says Sonpal. "Two or three requirements start to define your robot's performance envelope and the sooner you can show that you can or can't achieve it, the better. Then you can talk to the customer and say either the robot will cost more or you can meet the cost, but only by trading off requirements."

"At present our electrical tools don't extend into the mechanical area and vice versa," says Sonpal. "But when overlap occurs, such as in motor controllers, we simulate a portion of them on the electrical side and a portion on the mechanical side. At some point you reach a threshold where the simulation might cost you more than actually building something and testing it."

"After we run simulations, we create models in a CAD system," says Sonpal. "Then we can see what the product will look like. We might go back to a simulation and change something because the component or assembly hasn't come out exactly as we had planned. We try to minimize those iterations, though.

"After we have a complete model we can move on to rapid prototyping, which we do fairly early on in the design cycle," says Sonpal. "When we have something risky or something we haven't used before, we prototype one or two of them so we can test them and understand whether our simulations or our models actually represent reality."