Posts Tagged ‘Mobile Robot’

1985 – Nuclear Maintenance Robot “AMOOTY” – Tokyo Uni / Toshiba (Japanese)

amooty-toshiba-85c-x640

1985 – Nuclear Inspection Robot "AMOOTY" climbing stairs in a mock-up of a nuclear power plant.

Mooty-78-x640

Before AMOOTY there was MOOTY. No manipulator arm here, just vision and star-wheel propulsion.

amooty-9-deg-x640

Text Source: Inside The Robot Kingdom, Frederik L. Schodt, 1988

If cleverly designed, a robot on modified wheels or tank treads can still have considerable maneuverability. Separate from the ART project, three of the ARTRA members—Mitsubishi, Toshiba, and Hitachi—have been building their own mobile robots for nuclear power plants. Hitachi and Mitsubishi have in the past produced experimental models with modified tank treads that either bend in the middle or reconfigure themselves for stair climbing. Toshiba has created a wheel-based design.
Near Yokohama, inside a mockup of a nuclear reactor that contains stairs, valves, and ladders, Toshiba has experimented with traditional crawler-type robots and even a robot that does nothing but climb ladders. Its current pride and joy is AMOOTY, partly funded by MITI money. AMOOTY (an acronym based on the names of the six men at the University of Tokyo who designed it) is a semi-"intelligent" robot with a vision system enabling it to navigate—a TV camera allows it to recognize specially placed symbols in the reactor and a laser beam measures distance. Instead of a traditional industrial-robot-style manipulator, AMOOTY uses one that looks like an elephant trunk with nine degrees of freedom—two more than the human arm.
The most novel aspect of the AMOOTY robot is its means of locomotion. Inspired, perhaps, by the old stair-climbing carts used by Venetian porters, each "wheel" is in the shape of a clover, with each "petal" of the clover containing a smaller, independent wheel. On flat ground the clovers do not turn—only the smaller wheels do. To climb a staircase, or cross over an obstacle, however, the larger clovers themselves are rotated. AMOOTY still has many problems. Its power is supplied by a cable, its speed is too slow, and it is too heavy and large. But it is a stable design. When engineers in a remote command room (watching through television cameras, with robot positions in the reactor displayed on computer screens as both outline and three-dimensional shapes) put AMOOTY through its paces, the "wheeled" robot lurches right up the stairs.
Professor Hiroyuki Yoshikawa of the University of Tokyo Mechanical Engineering Department led the team that worked with Toshiba to design AMOOTY. "In Japan we tend to neglect research on the basic purpose of our design," he says. "My specialty is design theory, and I consider design to be the science of function. For AMOOTY, for example, we used functional analysis to research the concept of maintenance in nuclear reactors, and came up with a system of locomotion and an arm that does not exist in nature."


bioinspired-amooty-x640

The manipulator arm had 9 degrees-of-freedom.

amooty-arm-x640

japan-amooty-specs-85c-x640

Brief technical specs of AMOOTY.

robot_0017 - Copy-x640

Interesting comment by Hiroyuki Yoshikawa, one of AMOOTY's developers:

Despite Japan’s leadership in robotics, nuclear plant operators assumed that robots would not be needed to deal with an accident. The Times quoted Hiroyuki Yoshikawa, an engineer and a former president of the University of Tokyo, as saying, "Instead, introducing them would inspire fear, they said. That’s why they said that robots couldn’t be introduced."

Even though Yoshikawa, a robotics expert, was among those who built a prototype called Mooty that was designed to handle high levels of radiation and navigate rubble that might be expected as a result of a nuclear accident, the robots were not put into production. Consequently, after the Fukushima accident, Japan had to rely "an emergency shipment of robots from iRobot, a company in Bedford, Mass., more famous for manufacturing the Roomba vacuum. On Friday, Tepco deployed the first Japanese-made robot, which was retrofitted recently to handle nuclear accidents, but workers had to retrieve it after it malfunctioned."

Yoshikawa told the Times that Japan’s rejection of robots designed to respond to nuclear accidents "was part of the industry’s overall reluctance to improve maintenance and invest in new technologies."

Source: Powermag

amooty-1980-x640

The only English written paper I found on AMOOTY is dated  1985. I don't  know how accurate the caption dates are on MOOTY (1978) and AMOOTY (1980).

T. Arai, H. Yoshikawa, M. Takano, S. Ozono, G. Odawara, T. Miyoshi, K. Shimo, and T. Mikami. A stair-climbing robot for maintenance: "AMOOTY". In Proc. of the Seminar on Remote Handling Equipment for Nuclear Fuel Cycle Facilities, pages 444-456, 1985.

toshiba-aimars-amooty-x640

AMOOTY was further advanced by Toshiba and now called "AIMARS" – (Advanced Intelligent MAintenance Robot System).


See other early Teleoperators and Industrial Robots here.

See other early Walking-wheels here.


Tags: , , , , , , ,

1971 – Manned/Unmanned Lunar Explorer (MULE) Concept – NASA (American)

Manned/Unmanned Lunar Explorer (MULE)

Another Dual-Mode (Manned/Unmanned) LRV for Post-Apollo missions. This one with manipluator arms. Courtesy of one of NASAs system engineering courses.

Source: here.


See other early Space Teleoperators here.

See other early Lunar Robots here.


Tags: , , , , , , , ,

1962 – Unmanned Space Mobot (Concept) – Hughes Aircraft (American)

Hughes Space Mobot concept.

John W. Clark, Ph.D.
NUCLEAR ELECTRONICS LABORATORY
HUGHES AIRCRAFT COMPANY
CULVER CITY, CALIFORNIA
ROLE OF REMOTE HANDLING IN SPACE [c1962]
Orbiting Vehicles
In connection with orbiting vehicles, remote-handling techniques can advantageously be
employed in connection with maintenance and repair, assembly in orbit, and personnel transfer.
Maintenance and repair is, of cause, confined to orbiting vehicles so expensive as to justify the cost of orbiting a repair system rather than orbiting a complete new satellite.
Assembly of large orbiting vehicles may advantageously be accomplished by remote-control techniques. These techniques will permit the assembly of vehicles far too large to orbit in a single payload. Control of the assembly system may be accomplished either from a ground station or from a manned orbiting vehicle.
Personnel transter, as, for example, between a re-entry vehicle and a manned space station may be facilitated by those of remote-control techniques in accomplishing the final contact between the two space vehicles and to accomplishing an airtight closure or junction between these two which will be safe for personnel transfer.
Lunar Applications
Remote-control techniques will find many applications in the exploration and development of the lunar surface for scientific and military purposes. Preliminary operatiins will probably be accomplished by systems committed from the earth. This maybe followed by development of luna sites, also by earth-controlled vehicles.
After the development of lunar sites, manned lunar expeditions may become feasible. Such expeditions will benefit from the availability of sophisticated remote-handling vehicles which can, under control of the pilot of the space ship, accomplish lunar exploration or advance the development of the sites prepared by the earth-controlled Mobots.
Finally, after habitable lunar stations become available, operations of all kinds upon the lunar surface will still be in large part carried out by Mobots under control of the inhabitants of the lunar station.

DESIGN OF REMOTE-HANDLING SYSTEMS FOR SPACE
This discussion excludes consideration of lunar Mobots. It is, of necessity, confined to certain of the problems uniquely applicable to remote handling in connection with orbiting space vehicles.
Vision
The meet important of the senses, vision, requires particular consideration under space conditions. The harsh illumination will require unusual control of the TV cameras, and also may require specially conrolled illuminations an aid to working on the shadowed side of orbiting objects. The lack of background and of vertical reference are serious psychological problems. Consideration may well be given to artificially inserting both background and vertical reference within thee TV system so that the operator's TV monitors present him information similar to that to which he is accustomed.
These requirements are superimposed upon those applicable to any remote-handling system. Sufficient experience has now been gained with operation of Hughes Mobots to make one confident that adequate vision for performing complex or precise tasks can be furnished to a trained operator by the appropriate use of two or more conventional TV cameras. Additional quantitative studies concerning the relative utilily of multi-camera, stereo, and other methods of vision, with specific reference to the conditions existing in space, will be most valuable.
Dynamics of a Gravity-Free Environment
Operations under orbiting conditions present a novel situation since on is  concerned with acceleration rather than velocities and a relatively small system of limited power consumption can direct the motions of quite heavy objects if appropriate consideration is given to their inertia. For example, an arm capable of lifting an earth weight of 40 pounds can impart a useful acceleration to much heavier masses under weightless conditions. This arm can move a 500-pound mass 5 feet in 2.8 seconds in an optimal situation in which a mass is accelerated for one-half the time and decelerated for one-half the time. Clearly, spacial operator training will be required to obtain successful performance under these conditions, so different from those to which we are accustomed.
Command and Data Link
In cases in which control is provided from a manned space craft, the command and data link can be transmitted from controlling  vessel to Mobot via cable. The time division multiplex command system utilizing trinary digital coding is particularly suitable since it requires only two conductors in the cable. This system has been described in detail in an article by Don A. Campbell (ref. 1). Situations in which radio command is required are also well handled by this same system, which minimizes bandwidth required of the communication channel. The data link which conveys vision, sensory, and other analog information from Mobot to command station can employ the same cable as does the command link. In radio-controlled systems a separate data link is required. The detailed considerations, primarily the trade-offs between power and bandwidth, are different in each case. Particular attention must be paid to utilizing TV systems in which minimum video bandwidth is required in comparison with the conventional RTCA• standard system which is quite wasteful of bandwidth.
Arm Geometry
Numerous space applications are best handled by specific mechanisms tailored to perform specific tasks. No general comments can be made about such mechanisms. There is, however, a definite need for general-purpose handling mechanisms. To meet this need, the Hughes Mark 2 Arm has been developed (figure 1). Its three articulations are each capable of +-90deg motion in either plane. The tong rotates continuously. Its parallel jaws open to a 4-inch width or close completely. They will rotate continuously in either direction. This arm is completely self-contained. All actuators and other mechanisms are included within the arm structure. The only auxiliary space required is that occupied bt the command system. This arm is not presented as the ultimate arm design, but is presented as indicative of a general-purpose arm capable of handling a wide variety of manipulative requirements in the presence of obstacles or in cramped quarters.
•    Radio Technical Committee for Aeronautics
Locomotion
In connection with satellite and orbital vehicle handling arms, only two methods of locomotion appear feabible. These are rockets or jets for traversing the space between one orbiting object and another, and auxiliary arms for moving about on or in a large orbiting vehicle. The preliminary sketches of space Mobots (figures 2 and 3[7]) indicate a four-armed Mobot based on this concept. In general, two of its arms are employed for moving it about in connection with its operations on a orbiting vehicle, while the other two are free for performing any manipulations required.
The Space Environment
The space environment (high vacuum, extremes of temperature, zero gravity, etc.) will have controlling influence to the detailed design of the components which make up any space Mobot. Fortunately, adequate design information is becoming available upon which one can base such engineering design. Further environmental test facilities are becoming available in which components or complete systems can be tested to insure their performance in the space environment.
SUMMARY
Concepts
The above discussions of the role of remote handling in space leads to the preliminary concepts shown in figures 2 and 3[7]. These Mobots employ jets or rockets to move about in space. They are furnished with four ams and two "eyes." The four arms, which are identical, can be utilized for moving the Mobot about on the vehicle on which it is working, positioning it during performance of the task, or guiding or manipulating the objects handled. Even a relatively small Mobot, such as those in figures 2 and 3[7], can handle quite  heavy objects in space if the operator is properly trained in the dynamics of space operations as outlined in the above discussion of the gravity-free environment.
These Mobots may be controlled by cable from a manned space ship or from a ground station by radio beams. In the latter case, it may be necessary to utilize orbiting vehicles as relay points for control of Mobots which do not stay within the visual horizon of any one ground station.
CONCLUSIONS
The work performed to date at Hughes on the electronically controlled remote-control systems to perform complex operations has demonstrated the feasibility of this method of accomplishing useful work an a hazardous environment. Work now in progress demonstrates the feasibility of designing mechanical and electronic structures which will perform in a satisfactory manner in the environmental conditions which prevail in space. Space MOBOTS are technically feasible and can be engineered economically and effectively to accomplish any given tasks which may be placed upon them by our Space program,
REFERENCE
1. Campbell, D. A., "Multiplex Circuits for Control of a Robot," Electronics, 22 January 1960.


From 1960, Ray Goertz, who invented electrically remote manipulators for the nuclear industry, together with his team at Argonne Nuclear Laboratories (ANL), were engaged by NASA to specify teleoperator configurations for the Lunar space program. The result is illustrated above.

It should be noted that floating vehicles share one problem. This is their inability to stay immobile relative to the object on which they must act. Hence, they are equipped with docking arms, other than the manipulator(s) directly intended to execute the task, to attach them to the object of their task, whether this is another satellite or an underwater oil platform.


Most of the Hughes Aircraft Mobot concepts were based around the Mobot Mk II arm.

Mobot Gripper specification.


Dr. John W. Clark, Manager of the Nuclear Electronics Laboratory at Hughes Aircraft Corporation, headed the Mobot group.


See other early Teleoperators here.

See other early Lunar and Space Robots here.


Tags: , , , , , , , ,

1959 – Lunar Robot Mobot (Concept) – Hughes Aircraft (American)

MACHINE TO EXPLORE MOON

FIRST EXPLORER of the moon may be a machine. Roaming the crust, it would collect samples of rocks and dust with mechanical fingers, under remote control of spacemen remaining safely within a landed rocket ship. Hughes Aircraft company designers say it could be patterned closely after their Mobot, a mobile mechanical manipulator whose dexterity inspired the idea.

Source: Popular Science July, 1959.


Another Hughes Mobot concept showing similar arm configuration.


See other early Teleoperators here.

See other early Lunar Robots here.


Tags: , , , , , ,

1981-3 – Pluto CMU Rover – Hans Moravec et al (American)

CMU Rover (showing camera slide).
The CMU rover wheel drive assembly (simplified cross section).
CMU Rover base assembly (showing wheels).
 
Basic robotics concepts – John M. Holland – 1983

The CMU Rover Fully Independent Drive
At the time of this writing [1983] Dr. Hans Moravec at Carnegie-Mellon University is constructing a new mobile robotic testbed.
This configuration has a similar base arrangement to the synchro drive system, except that each foot is totally independent for both steering and power. The "feet" also have a wheel on each side, powered through a differential. This arrangement greatly improves the flexibility of the carriage system. Each "foot" assembly contains an encoder for both steering and power, allowing the drive computer to precisely control it. Early results indicate that the differential must have limited slip.
The CMU Rover System has joyous degrees of freedom for a wheeled system. It can turn in a mode like the synchro drive, or it can steer its wheels tangentially to the base and spin in circles. The lack of mechanical linkages should provide excellent efficiency, and maintenance should be relatively good. Control is of course more complex, but the CMU machine is being fitted with special low-power-consumption computers utilizing the extremely powerful MC68000, 16-bit microprocessor.
Since the Rover does not have a configurable base of support, its stability is limited. The combination of these wheels with such a base would indeed be powerful, but it was not required for the functions expected of this robot. Perhaps the first law of robotics design should be "If it doesn't need it, don't add it!"
One of the interesting maneuvers that Moravec is exploring"' with this configuration concerns climbing slopes that would normally be too steep for the robot's traction and power (not stability). The robot is made to spin about its own axis as it approaches the ramp. This is somewhat analogous to the zig-zag maneuver performed by a bicyclist on a steep grade. When one wheel is attacking the full grade, another is running relatively level, while the third is moving downhill.
Additionally, the rotational motion of the robot serves to store energy in the same manner as a flywheel. While it seems unlikely that one would want to have factory robots pirouetting wildly about the floor, a subdued version of the maneuver might prove very useful.
This system is in keeping with the general trend away from mechanical complexity in electromechanical devices such as printers and manipulators. The electronic controls associated with these devices are being used to eliminate most of the mechanical intricacies, thus reducing cost and maintenance.

•    Efficiency: Excellent
•    Simplicity of Control: Fair (due to exceptional flexibility)
•    Traction: Good
•    Maneuverability: Excellent
•    Navigation: Excellent
•    Stability: Fair
•    Adaptability: Dynamic adaptability only
•    Destructiveness: Excellent
•    Climbing: Poor
•    Maintenance: Good
 

 
Three Degrees for a Mobile Robot

Hans P. Moravec

The Robotics Institute Carnegie-Mellon University
Pittsburgh, PA 15213      February 1984

This work has been supported at the Carnegie-Mellon University Robotics Institute since 1981 by the Office of Naval Research under contract number N00014-81-K-0503.

@heading(Abstract)

Our group has spent three years designing, building and struggling to make operational an ambitious mobile robot.  The project was initiated with mixed objectives.  The major purpose was to provide a vehicle for continued work in navigational vision begun at Stanford.  A secondary goal was to build a high performance mobile platform able to act in concert with a future attached robot arm.  The decision to pursue both efforts in a single robot, effectively holding the primary goal hostage to success of the secondary one, was a strategic error.  Achieving the agility desired for a mobile extension of an arm was a much more interesting problem than we had guessed.

We've been working on the vision side of the work during the ordeal with stored images and simulations, and have recently completed a second, much simpler, vehicle to return that effort to the real world.

This paper tells the saga of the secondary goal; why it was undertaken, the problems it encountered, what we have learned from it, and how we are proceeding.  The most interesting aspect is the need to control a highly overconstrained system, a problem occurring (and often ignored) in other areas of robotics, but presented with unique forcefulness by our wheelbase design.  As we discovered in other aspects of mobile robot research, despite surface similarities there are remarkable differences between the problems imposed by mobile platforms and those of robot arms, and solutions for manipulation are rarely directly suitable for locomotion.

@heading(Introduction)

The Stanford Cart was a television equipped but otherwise very simple mobile robot controlled remotely by a sophisticated computer.  From 1973 through 1979, as part of my PhD research, I wrote a program that could drive the Cart through cluttered obstacle courses using the onboard camera to locate and track objects, and, significantly, to visually servo the robot's movements with high accuracy despite terrible sloppiness in its mechanics.  The problem was harder than I had guessed in my early musings, and the final program took no less than five hours to drive the robot over 20 meter routes @cite(Moravec80).

The surprising difficulty of the problem, among other circumstantial evidence, convinced me that working with autonomous mobility confronts one with the key problems of perception and the foundations of intelligence in a uniquely effective way @cite(Moravec83).  This insight greatly encouraged the work, and led me to take extra risks.

The optimism was inflated at CMU when, in 1981, we received an Office of Naval Research contract sufficiently large to develop a very elaborate roving robot system.

Early ideas for the vehicle were pedestrian; a conventionally steered three wheeled platform carrying a camera system similar to the Cart's, but with onboard processing for more precise motor servoing and simple sensing.  The prospect of a plodding continuation of the Cart work left me dissatisfied and I sought to spice the challenge.

Hari Asada, now of MIT, then my office neighbor, shared his concept of robot mobility.  Hari, with Takeo Kanade, had been studying direct drive robot arms, where high torque, gearless electric motors, with low friction and precise torque characteristics promised manipulator speed and precision not possible in conventional designs.  Hari's vision was of a mobile robot at the base of a robot arm acting with the arm in manipulation tasks.  The mobile base would be like a shoulder joint with enormous reach, high strength, moderate speed and modest accuracy.  Limitless applications came
to mind.  He convinced me.

@heading(Conception)

The first major decision was what the wheelbase should be like to best support the manipulation task.  Conventional drive designs  allow instantaneous motion with only two degrees of freedom (DOF); usually forward speed and radius of steering curvature; sideways motion is not possible.

The usefulness to a manipulator would be enhanced if the base could move with a full three degrees of freedom (dubbed omnidirectional motion). Any vehicle with a fixed conventional wheel is constrained to two DOF, therefore an omnidirectional vehicle can have no fixed conventional wheels. Spherical wheels came to mind immediately, but at the time I saw no way of controlling a spherical wheel in two or three DOF without high  frictional losses (a solution has since cropped up, but it is more complicated than competing omnidirectional techniques).  Most straightforward seemed to be to make all wheels of the vehicle steerable.  A round chassis with three steerable assemblies seemed simplest and most general.  The robot, with batteries, motors, mechanical structure, cameras and other electronics would weigh at least 100 Kg.  If each wheel was placed directly under its steering axis, steering while the robot was not moving would be difficult or impossible because of high friction with the floor.  Putting the wheels off-center would alleviate this problem, but the robot would be less stable. I opted for what seemed like a clever idea; a pair of off-center wheels connected by a differential gear.  This basic idea, the need to make everything compact, power efficient and self contained, and the willingness to risk new techniques at any stage (this was basic research, after all), led to the following design.  The first CMU Rover, now named Pluto, was built according to this plan and was substantially finished by 1983. 

@heading(The Early Design)

This section describes only Pluto's hardware as it actually existed at the end of 1983.  For other aspects of the grand plan see @cite(Moravec83).

The robot is cylindrical, about a meter tall and 55 cm in diameter (Figure 1) and has three individually steerable wheel assemblies which give it a full three degrees of freedom of mobility in the plane (Figure 2).  It carries a TV camera on a pan/tilt/slide mount.  It contains eight onboard processors for servo control and communication and is linked by serial line to an outboard 68000 and a Vax.

Omnidirectional mobility is achieved by mounting the chassis on three independently steerable wheel assemblies. The control algorithm for this arrangement at every instant orients the wheels so that lines through their axles meet at a common point. Properly orchestrated this design would permit motion in any direction, and control of the robot's rotation about its own vertical axis.  An unexpected benefit of this agility is the availability of a "reducing gear" effect.  By turning about the vertical axis while moving forward the robot derives a mechanical advantage for its motors.  For a given motor speed, the faster the Rover spins, the slower it travels forward, and the steeper the slope it can climb.

To permit low friction steering while the robot is stationary, each assembly has two parallel wheels connected by a differential gear. The drive shaft of the differential goes straight up into the body of the robot. A concentric hollow shaft around this one connects to the housing of the differential (Figure 3). Turning the inner shaft causes the wheels to roll forwards or backwards, turning the outer one steers the assembly, with the two wheels rolling in a little circle.

Each shaft is connected to a motor and a 4000 count/revolution optical shaft encoder. The two motors and two encoders are stacked pancake fashion on the wheel assembly, speared by the shafts. There are no gears except for the ones in the differential.

The motors are brushless with samarium-cobalt permanent magnet rotors and three-phase windings. With the high energy magnet material, this design has better performance when the coils are properly sequenced than a conventional rotating coil motor. The coils for each are energized by six power MOSFETs mounted in the motor casing and switched by six opto-isolators (to protect the controlling computers from switching noise) whose LEDs are connected in bidirectional pairs in a delta configuration, and lit by three logic signals connected to the vertices of the delta (Figure 4).

The motor sequencing signals come directly from onboard microprocessors, one for each motor. These are CMOS 6805s to keep power consumption low. Each processor pulse width modulates and phases its motor's windings, and observes its shaft encoder to servo the motor to a desired motion. The 6805s get their marching orders over a shared serial line from an onboard 68000 that communicates with an outboard 68000 that runs the co-ordinating program.  One other 6805 controls three stepping motors to pan, tilt and slide the camera assembly.

The Rover is powered by six sealed lead-acid batteries.  The motors are powered directly from these, the rest of the circuitry derives its power indirectly from them through switching DC/DC converters.

@heading(Experiments and Experiences)

Experiments with Pluto during and after construction revealed some severe problems. Many of them required repeated disassembly and assembly of the motor stacks.  The nested and stacked design made this a very arduous and time consuming process.

@begin(itemize)
@i(Malfunctions of the wheel assembly shaft encoders, including breakages of the glass encoder disks.)  The differential wheel assemblies had an unexpected amount of motor shaft runout when weight was removed from the wheels. The modular encoder disks are attached to the shafts, while the optical sensor and electronics are attached to the shaft, with a required clearance of only 0.05 mm, on the wrong side.  We solved the problem by replacing the encoders with a type that can be mounted upside down to accommodate the runout without damage.  We still noticed occasional loss of calibration and damage in some of the encoders.  We built sturdier encoder mountings, and assembled the stacks more carefully.  The encoders seem to be holding for now, but are still a source of worry. We are considering a new design with different, pre-assembled, encoders and flexible couplings should any fail again.

  @i(Loss of traction of the differential wheels on slight floor irregularities.) Each of the three wheel assemblies had two wheels connected by a differential gear.  Three points define a plane, and the rover often encountered situations where most of its weight was borne by one wheel of each differential, resulting in loss of traction because of the nature of the differentials. We tried different tire materials, but failed to solve the problem this way.  We did succeed by a radical alteration; removal of one wheel from each assembly and locking of the differential gear.  By slightly reducing the wheel diameter we were also able to decouple drive motor from steering torque, improving the servo characteristics.

   @i(Burnout of the motor driver field-effect transistors.) For compactness, power efficiency and in hopes of giving the mobile base the precision and controllability to provide three degrees of freedom of motion for a future attached manipulator, I chose a direct drive design using samarium-cobalt brushless motors. To contain motor switching noise, the driver circuitry is in the motor case optically coupled to the outside and uses power FETs for their high current gain. The FETs were new and the largest available when I chose them in 1981, and their specifications (12 amps, 60 volts) seemed adequate for the motors (10 amps, 24 volts). Initial testing turned up no problems. Sustained runs of the completed rover proved otherwise. We destroyed about one transistor for every half hour of operation of the six motors.  We did extensive bench testing, but found it difficult to re-create the problem; all our measurements were within spec, and our transistors survived.  Recent data from the manufacturer told us the problem.  The ratings in the old specs are at 25 degrees C; at 100 degrees the ratings drop by a factor of three.  Our drivers approach the higher temperature only after sustained runs at high loads. Fortunately FET technology was marching on.  The largest FETs available now have three times the capacity of the 1981 variety.  We installed the new ones, and have had no problems since.

@i(Severe oscillations and other errors in servoing the drive and steering motors.) We put much effort into simulations of the wheel motors in order to develop servo code for the motor processors before fabrication of the motors was complete.  Most of this early effort went for naught because the simulations inadequately modeled backlash and other non-linearities and also because the motor processors were too slow to implement the algorithms with sufficient time resolution.  We re-iterated much of the development in a bench setup with an actual motor and processor, and developed code that seemed able to servo position and velocity @cite(Muir84).  We found the robot could be driven reasonably well with this code if only one wheel assembly was energized (the other two steering-locked and freewheeling). With all three running the robot mostly shook and made grinding noises. Something strange was going on.  We tried simplifying the loops, with a position servo on steering and a velocity servo on the drive motors.  The robot now moves, but unsteadily and with oscillation.  The persistent problems triggered an insight; we had an unexpectedly interesting problem.
@end(itemize)

@heading(Too Much Control)

I had chosen the original control configuration, a processor for each motor all orchestrated by another processor, partly in imitation of the successful controller for Unimation's PUMA manipulator. The apparent correctness of this choice was amplified by a co-incidence.

In 1981 after the basic design for Pluto had been specified, I learned of a Unimation funded Stanford mechanical engineering project building an omnidirectional robot nearly the same size and shape as ours @cite(Carlisle81).  The machine achieved omnidirectionality in a different manner; three motors driving three symmetrically placed wheels of strange design. Each wheel had rollers in place of tires that allowed the wheel to be passively rolled sideways as well as driving backward and forward under motor control @cite(La81).  The robot used a slightly modified PUMA controller to drive its wheels. By 1983 the Stanford/Unimation design was built and its controllability verified.

Our experiences indicated emphatically that there was a fundamental difference between our design and the Stanford one. The problem was in the interaction of the six servo loops.  In the Stanford/Unimation design, where three motors control three degrees of freedom, the interaction is small and can be ignored with only moderate loss of performance; similar considerations apply to manipulators.

Pluto's drive system, on the other hand, with six motors, is overdetermined (or overconstrained).  In addition to moving the robot forward, sideways and spinning it about its axis, the individually drivable and steerable wheels are able to  attempt to twist, compress and stretch the floor in various interesting ways.  Our naive control method excites these modes, and the robot shakes and rattles in a way we cannot ignore.

Similar problems have been encountered in the context of walking machines @cite(Orin81) and manipulators doing pushing operations like inserting a peg in a hole with tight tolerances @cite(Mason82).  The Ohio State University walking machine group has suggested two solutions.  One involves solving a large linear programming problem in the servo loop to minimize a total energy function.  It requires a presently unavailable amount of real-time computer power.  Their other solution is easy to implement, and involves putting a torque term in each feedback loop error expression.  This effectively puts a damped spring in each axis, limiting the forces that redundant actuators will exert on each other in case of small disagreements.  The price paid for this is a softness in the control, for instance a sag when climbing a slope.  Neither approach entirely solves Pluto's problems.

@heading(An Approach)

Controlling Pluto's overconstrained wheelbase has thus become an interesting research problem in its own right, one we have just begun to investigate.  Its now seems to us that six independent servo loops on six motors is a fundamentally wrong way to control three degrees of motion. It is necessary in some way to eliminate the conditions that permit pairs of motors to engage in tugs of war while trying to drive the robot.

One idea we will be investigating is a system that mathematically combines the six direct motor motions to produce abstracted variables, three representing desirable modes of operation, and the other three being undesirable floor stretching modes.  Servo loops will control these derived variables, trying to zero the undesirable modes and to drive the robot with the others.  The error signals generated by these loops will be transformed by a mathematical operation inverse to the one by which their variables were derived, producing drive signals for the motors.  The desirable modes might be the X, Y and angular velocity of the robot as a whole, or alternatively the direction, speed and radius of curvature of its trajectory.  Undesirable modes would involve discrepancies in steering angle and in drive speed of the different wheel assemblies.

One of the most serious bad modes is a castering effect that happens when one of the wheels falls behind the motion of the robot as a whole.  The assemblies now have only one wheel each since we did away with the differential, and this wheel is placed to the side of the steering axis. Once the wheel falls back a little, robot motion produces a force that drives the steering even further off the correct heading.  This mode can be countered both by torquing the steering motor for the wheel and by accelerating the drive motor.  This mode will have to be stiffly servoed since it gets worse if left alone. Other undesirable modes, such a differing toruqes on different drive wheels would need less stiff servoing since they passively correct themselves.

@heading(Conclusion)

We built Pluto primarily to continue our work in computer vision, but decided to incorporate interesting new capabilities, and to utilize interesting new techniques.  The interest level rose higher than we had bargained for, and we spent three years battling severe interlocked problems.  As the dust settles we are left with an interesting and important control problem that we look forward to systematically solving. Until it is solved, Pluto will be unsuitable for vision work.

In the meantime we have built a very simple mobile robot for the vision work.  Neptune uses synchronous motors driven off line frequency to sidestep the servo issue completely, and was fully operational three months after we started work on it. It has already visually servoed its motion and avoided many obstacles.

I suppose this might be called the divide and conquer problem solving strategy.

@heading(Acknowledgment)

In the last year Pat Muir has uncomplainingly suffered through Pluto's woes, valiantly trying to write a control thesis on a machine that blew transistors and mangled shaft encoders every few days and that required weeks of his labor to disassemble, assemble and recalibrate to repair those problems.  The new control insight is due entirely to Pat's efforts.  Gregg Podnar completed the Pluto's electrical system, and took care of the many of the redesigns and retrofits this sickly machine required. Gregg also designed and built Neptune's body in record time. Karen Hensley designed all the major mechanical components of Pluto, as well as the door opening arm we didn't even mention in this paper.  Mike Blackwell has done all our microprocessor designs, except for the earliest ones which were done by Andy Gruss.  Neptune carries one processor for motor timing, Pluto has eight, the better to shake with.  Kevin Dowling built Neptune's electrical system and the camera moving circuitry for Pluto. Larry Matthies and Chuck Thorpe developed and improved the visual obstacle avoiding code that now runs Neptune. Alberto Elfes wrote a high level control program for the robots that we don't use yet, as well as a Sonar mapping program that will be used soon.  Richard Wallace joined us recently and has been fooling around with path planning and manipulation graphics.

This work has been supported at the Carnegie-Mellon University Robotics Institute since 1981 by the Office of Naval Research under contract number N00014-81-K-0503.


Pluto with its younger, more sophisticated brother – Neptune.


As it is today at the Computer History Museum.

Tags: , , , , ,