Engineering Tools Firmly Grounded in Space Applications

Suggested Event

Automation Technology Expo (ATX) Minneapolis 2023

Oct 10, 2023 to Oct 11, 2023

Although Sean Dougherty spends a lot of time thinking about spacecraft, he has his feet firmly on the ground, usually in a lab, near a test setup or at a PC workstation. Dougherty supervises the mechatronics group at Alliance Spacesystems, Boulder, CO, best known for its creation of the robotic arms on NASA's Mars rovers, Spirit and Opportunity. "We're now working on the two-meter-long arm for the Mars Science Laboratory, which should launch in 2011," says Dougherty. "The arm will carry sensing and imaging instruments."

"We develop and manufacture the arm - including the flex cabling - test it, and then deliver it with the proper connectors and mounting interface to the Jet Propulsion Laboratory in Pasadena, California," says Dougherty. "But the engineers at JPL write the code to control it on Mars."

In addition to its Mars-exploration arms, Dougherty's company also creates specialized robots for other applications and industries. When NASA started to plan for the last repair mission to the Hubble Space Telescope, Alliance Spacesystems designed and built a prototype robot that could remove 111 screws so astronauts could access Hubble's instruments. "We built a prototype robot in about three months," says Dougherty. "Instead of writing a lot of code in C, we used NI's vision-recognition software to locate each fastener and then used an automated screwdriver to remove it. We used NI's LabVIEW throughout and didn't write any custom code, so we could quickly create and test a prototype."

Dougherty made it clear that NI's hardware and software stay on the ground. "NASA customizes everything because its engineers must master every detail. If something goes wrong, they can get down to the minute details. So they write applications themselves in C and use their own software libraries and space-rated processors."

That sounds a lot like re-inventing the wheel. If you have a working system that has used LabVIEW code and NI's hardware, how difficult is it to substitute the code and hardware that goes into space? Recently, Alliance Spacesystems went through the process before it delivered a robotic satellite-service arm to the Naval Research Lab.

"That robotic arm used almost the same architecture as NI's CompactRIO programmable automation controller, which has a processor that runs the VXworks real-time OS, and an FPGA," says Dougherty. "We put an FPGA on our system to handle the low-level motor-control functions. The processor took care of path planning and the user interface. We could have taken the VHDL code for NI's FPGA and ported it directly to the FPGAs in our system."

"We didn't take it to that step, though, because generally people don't yet trust autocoding for space applications, and the code also needs to be highly optimized for these applications," says Dougherty. "Autocoding compiles a program created with a graphical 'language' directly into machine language or VHDL. But as mentioned before, space engineers must understand each line of code and where it came from. Autocoding doesn't let them do that. As people demonstrate the reliability of software-development tools, though, they will go straight from, say, LabVIEW code to C code for a space-flight processor."

To design a robust, modular software architecture, Dougherty and his colleagues often utilize LabVIEW from the start. Then after testing they replace each LabVIEW module with a module they created in C. "We substitute a few modules at a time and test them," says Dougherty. "LabVIEW lets developers freely mix its code with C modules. The actual C coding isn't trivial, but it's also not that difficult, and a library of modules simplifies the process."

"We strive to make things as modular as possible so we can put individual functions in a library," says Dougherty. "New projects require some new modules, but we reuse a lot of software from previous projects."

Another key attribute of LabVIEW centers on its interface with the M files commonly created by The MathWorks MATLAB and other software. "Our robotics and control engineers use MATLAB as one of their main tools, so they like the direct link with LabVIEW," says Dougherty. "Both LabVIEW and MATLAB are standard in industry and many colleges use them as teaching tools, so new engineers feel comfortable with both these tools." In one case, the engineers used MATLAB and Simulink to start an application and directly ported their code to a non-NI processor that ran the VXworks real-time OS. The Alliance Spacesystems engineers also use other modeling tools for mechanical systems and dynamics such as SolidWorks, Energid's Actin, NASTRAN and Adams. So, the engineers have many development options.

Engineering teams still must use a variety of tools to solve different parts of a design problem and sometimes they must re-create a model for each tool," says Dougherty. "You start with a SolidWorks model, then you create a NASTRAN model, and then develop a third control model in MATLAB. We're closing in on a time when you can create one model and use it anywhere, but we're not quite there. That holds us back a bit."

Dougherty stresses the multidisciplinary nature of his team and his team members' ability to use different design tools. "We have mechanical engineers who use LabVIEW and MATLAB just as we have electrical and control engineers who use SolidWorks to study robot-arm kinematics," he says.

Hardware and Software Tools Used at Alliance Spacesystems for Robotic Developments