1
Overview of Field Robotics

1.1 Introduction

Practical Field Robotics comprises the design and fabrication of machines that do useful work on their own, for the most part. Field Robotics separates us from robotics done in a protected laboratory environment. It is also somewhat removed from theoretical robotics that underpins much of what we do, but may not employ in the realization of machines. Laboratory machines may walk like a human1, or simply perform useful tasks that humans do in other ways.

When asked to describe a "robotic dishwasher," new students often elaborate on a machine that picks up one dish at a time and does the washing the same way a human would. This approach ignores the success of pumping scalding water around in a sealed box. The former approach expresses limitations that were never imposed by the question.

The robotics literature abounds with examples that expressly imitate how humans are built, rather than what they aim to do. Since our hands and eyes evolved to allow us to swing from trees and pick fruit, they may not afford the best characteristics needed for a more modern task2. We should not be tempted to imitate and then automate things we ought not do in the first place. For example, Elias Howe has been quoted as saying that he was inspired by watching his wife sewing in his work to invent the sewing machine3. Analysis of how people sew and how his machine sews shows that this could not be the case. Our methodology will steer us away from these pitfalls.

A successful design should always consider such constraints as artificial and aim for the function to be performed4. We will see (Figure 1.1) an expression of high-level functions that not only informed the development of our case studies, but also suggested the layout of the chapters in this book.

Figure 1.1 The beginning of the FBD for a practical field robot for nuclear service

We will explore three examples of systematically designed field robotic systems, each illustrating key points of the design procedure and important lessons learned in the field. The first example is a mobile robot system, actually a pair of cooperating robots, used for field repair work in the commercial nuclear power plant area. This system was developed over time by several design teams considering the functions to be performed, and we will illustrate them here. Details of the system design remain proprietary but we can address the higher-level decision-making processes by reference to a patent issued to the author5. We will see that fully automatic control was not employed, but rather the concept of teleoperation, in which there are personnel in-the-loop at all times6,7. Special-purpose equipment and tooling were employed to create a level of autonomy for some subsystem tasks.

The second example involves the design and operation of the largest autonomous mobile robot ever built, to our knowledge. Its mission is to haul coal from an underground mine. Its field versions weigh hundreds of tons and span lengths of 160 m from end to end. Briefly, it comprises a continuous miner at the head end, a number of linked conveyors, and telescoping tail piece. While one terminal end does need a human driver, the balance of the system is autonomously driven through the mine, needing only periodic observation of its segments to ensure that no personnel come within its vicinity.

Finally, we present a detailed account of the design process and the operation of a low-budget mobile robot for automatically mowing a lawn at an affordable cost. To our knowledge this has not successfully been done until now. We initially examined six approaches to this problem, and each will be discussed before delving into the details of the selected concept.

1.2 Methodology

For all of the design examples, a common tool will be employed: the process of Value Engineering. The literature is replete with many examples of its use in both military and commercial designs4. We have included Appendix A to explain the process in detail, but will touch upon its major themes in this introduction. In summary, it expresses functions in a structured way such that the intent of the designer is made clear to all parties to the exercise. We do this by expressing each function of our design at successively higher levels of detail as we scan a page from left to right. The graph created by our consideration of intent and challenges is called a function block diagram (FBD). Also as we scan the page, the rightmost functions answer the question "how," and the leftmost answer the question "why."

Each function, in turn, is expressed with a single active verb and a single measurable noun, placed in a little box. A decision or artifact is shown in a rounded-corner box. Figure 1.1 shows a part of such an expression of the high-level function Service Exchanger, along with successively higher levels of detail in a tree-like hierarchy. The arcs connecting each function block can be read as "and." To give more meaning to the terms in use, the system to be discussed in the next chapter involves the servicing of the primary heat exchangers in a power-generating installation, but not the reactor itself. As mentioned, the rubrics of Value Engineering represent functions with verb-noun combinations. Attached to these may be allocations that specify quantitative constraints, which are not functions. Thus, in order to Service Exchanger we need to do two things: Meet Schedule and Prevent Leakage. These may seem obvious in hindsight, but functions rarely are. These early decisions have the most profound effects on the design details and express our unique choices. We emphasize that there is no single "correct" function diagram, but that the design team agrees that it is valid.

As we will discover, from the more detailed functions at the extreme right-hand end of the abbreviated FBD, we could have chosen to avoid any teleoperation and decide on the aggressive development of more "robotic" approaches. We put "robotic" in quotes to distinguish this enterprise of Field Robotics as the realization of a more intelligent automated process. We employ the term "practical" to mean that what we design and build must work and do so according to constraints. While we may slip into some philosophical discussions along the way, the leading emphasis is on practicality in terms of functionality and limited cost. In fact, Value Analysis was originally conceived as a cost-containing measure, but its adoption easily leads to innovation as well.

1.3 High-Level Decisions

We should mention here that function logic, the means by which we reason our way from general to specific, is not normally encountered in the iterative cycle of "analysis, synthesis and evaluation"8. It coexists with our "normal" way of thinking, and offers a great deal in terms of organization and expression of our designs to others. A functional map of a product or process is far easier to understand by those on the "design team" with separate interests and other skill-sets, than would be a stack of engineering drawings. Moreover, we can use it to innovate by simply supposing that a certain function is restricted, prescribed, or dependent on a specific technology that should be avoided.

The adoption of hierarchical functions to describe the intent of the design also serves to guide the discussion of the design and implementation. Rather than present a detailed description of what each portion of the robot is, we will explain what each of its functions do. The order in which this will occur follows the function diagram itself, beginning at a high level of abstraction, and gradually exposing more and more detail. In this way, the reader is not faced with synthesizing an entire system in his/her mind, but can "drop in" at any desired level of detail to learn why and how the robot was conceptualized and realized.

The practical decisions expressed in Figure 1.1 will guide us through the ideation and realization of practical examples of field robotics. Unlike Elton John, who sang9,

And each day I learn just a little bit more.

I don't know why, but I do know what for.

we will know precisely "why" a choice was made by simply looking leftward on the page. We will also know "how" by looking to the right. Unlike a flow chart, common to business and software planning, we will have an expression of the raison d'être rather than just a prescribed sequence. Incidentally, a vertical reading of any column of functions will also express, roughly, an operational sequence too10. In addition, the functional method also keeps us from falling into familiar patterns of thought. For example, the phenomenon of Einstellung11, choosing a familiar good idea and neglecting unfamiliar better ideas, is reduced since the entire design team is empowered to contribute to the high-level functions, at least.

Problems

1. 1.1 Consider the manual task of sorting mail into letters, flats, and packages. How might this be done robotically?
2. 1.2 Describe at least one teleoperator now popular with consumers.
3. 1.3 Please describe the...