The Robonaut simulation was developed to bridge a gap between operations and development activities. In theory, the only way to validate control algorithms, grasping algorithms, path planning, etc., is to interface directly with Robonaut. This method is less than desirable for several reasons. Firstly, it is always risky to test unverified control algorithms for the first time on robotic hardware; assurance that no damage will be done to the robot is essential. Secondly, there are far more users vying for Robonaut's time than there are hours in the day. Many of these users are from remote industry and university sites that, in addition to in-house engineers, desire access to Robonaut for research and testing. Finally, a separate platform for developing and refining telepresence interfaces was also desired for safety reasons. A simulation that matched the appearance, kinematics and dynamics of Robonaut could fill this gap in addition to providing the additional capabilities mentioned. During the design phase, the desire was to develop a simulation that would:
- Serve as a platform to test new control theories and configurations without having to construct elaborate and expensive hardware mockups.
- Provide a method for internal groups, as well as select industry and universities, to develop independent projects, theories, and software to control Robonaut.
- Provide a method for Robonaut personnel to validate new control, inverse kinematics, path planning, etc. software with regard to safety and operational concerns.
- Increase situation awareness for the teleoperator; provide overlays of the current robot posture to compensate for limited field-of-view.
- Allow testing and development of new communication protocols and telepresence hardware without risk to Robonaut.
- Allow development of new kinematics and dynamics software control algorithms without risk to Robonaut.
- Perform forward and inverse kinematics on the head, left and right wrist, tail, and fingers for Cartesian space control.
- Permit joint space control within the simulation, as this capability is currently not allowed on Robonaut for certain operations. There are currently 43 degrees of freedom (DOF) on Robonaut with additional DOF already planned.
- Dynamically mimic Robonaut as closely as possible.
- Operate at or near real time speeds on laptop or desk side PCs. A minimum refresh rate would be 15 Hz with 30 Hz being optimal.
- Interface with standard current telepresence hardware such as Virtual Hand Technologies CyberGloves and Polhemus motion tracking sensors.
The current version of the simulation meets most of the criteria stated above. The only criteria it does not meet are finger Cartesian space control and rigid body dynamics. These will be added sometime in the near future. Current dynamics are limited to all 43 joints having hard limits and angular rate limits. This provides realistic motion without resorting to computationally more expensive methods.
A benefit of the simulation development is the derivation of communication protocols between Robonaut and the outside world. Initially, Robonaut was hard wired to all input devices. With the advent of the simulation, protocols have been developed which allow Robonaut to converse with outside control software, thus moving it one step closer to full teleoperation over long distances. The simulation also acts as a situation awareness tool since the simulation can be driven directly by Robonaut, thus showing the actual pose (as opposed to the command pose) to remote operators.
Another benefit of the simulation regards path planning. Now operators can test arm motions on difficult tasks before actual operation of the robot, thus minimizing the risk to the hardware.
The simulation was developed using Enigma Core and specially designed interfaces and IK for the 43 DOF Robonaut. The Enigma Core is a set of libraries developed in-house by NASA/JSC for computer animation and simulation. Enigma runs on Windows 95/98/2000/NT, SGI Irix, and Sun Solaris. It provides animation of shuttle mission operations for flight director briefings and media publications. Enigma also serves as a front-end graphics package for numerous NASA, industry, and university simulations. By using the Enigma Core, not only did we significantly reduce the development time of the Robonaut simulation, but we benefit from being able to record video, mpegs, and stills in various formats. All of the IK was developed specifically for Robonaut. Most of the IK was derived from Robonaut control algorithms such that the simulation would more closely match the actual hardware. All communications are handled through NDDS version 2.3 and specially designed data packets.
The first trial for the Robonaut simulation will be the Texas Fly-High Mentorship program experiment. This experiment will measure the effect of teleoperation on humans within a microgravity environment. The experiment will be conducted on the NASA KC-135 zero-G aircraft, affectionately known as the "Vomit Comet." In order to perform this experiment, the simulation will reside on two laptop PCs with two Virtual Hand Technologies CyberGloves, Polhemus motion sensors, and a telepresence helmet mounted display (HMD). The laptops will provide images for each eye, which in turn, will drive each eye in the HMD. The Robonaut simulation handles synchronization of the hardware and graphics. Test subjects will perform tasks against a virtual task board. It is hoped that this data will provide valuable insight into zero-G teleoperations.
The future of the Robonaut simulation is very bright indeed. Uses for the simulation are continuing to expand. Currently, new control algorithms for various appendages, grasping techniques, path planning, etc. are being developed using the simulation. Rigid body dynamics will be added in the near future. As with all software packages, the simulation will be developed based on the needs of its user group of people.
We used several novel analysis methods to design Robonaut, NASA's humanoid system developed to work in Earth orbit. One of the main goals of Robonaut is matching task requirements with a robot system configuration, synthesized with computational methods, interactive design and 3D visualization. Developed as a program called Optimus, the software's main analysis modules are kinematics, power flow (from electrical input into work and heat), thermal transient endurance modeling, and deflection of the multi- armed system subject to loading on all limbs. This software is then used to analyze specific tasks, with a spectrum of tasks then being considered for overall system optimization.
General Humanoid Model
This figure shows a generic multi-armed system, with N limbs, each with M degrees of freedom, for a total NxM mobility set. The D-H parameter structure is general for each segment, with the forward kinematic model therefore having 4xNxM design degrees of freedom (DDOF). The body, unconstrained, has an additional 6 axes of free motion, with 6 DDOF associated with the relative placement and orientation of each arm's origin on the central structure. The two armed, one legged model shown in the figure (N=3, M=7) has a total of 108 DDOF.
A database of drive train components is used to further refine the manipulator models. Drive train data includes motors (mass, motor constant, resistance, radius, length) and gearing (ratio, radius, torque, length), linked in a parametric model to 3D animation. Selection of drive elements determines joint volumes, masses, and motion ranges, which are then linked to the arm design. This interactive model is then driven by the analysis software modules, displaying candidate robot configurations for the human designer's review and guidance in the optimization process.
For given tasks, the first analysis is a workspace assessment, adjusting D-H parameters to allow the system to meet trajectory requirements, exploiting the self motion null spaces to minimize robot scale. The second step is a power analysis, matching trajectory force-speed requirements to arm kinetics, which are in turn linked to joint loads and a calculated set of motor torques, currents, and ultimately their resulting heating loads. This task analysis is time-based and produces an end-to-end thermal task profile that is used in a transient heat transfer model of the whole robot system. Thermal endurance can then be calculated for a spectrum of tasks, optimizing the robot for a broad class of humanoid service.