Algebraic Constraints

SketchIT produces output in the form of a BEP-Model, a parametric model with constraints that ensure the desired behavior. Serrano and Gossard [44] describe a system called MATHPAK that is suitable for solving the constraints of a BEP-Model.⁴ Similarly, Serrano [45] describes a system for eciently solving systems of algebraic

4DesignView, the system we actually use to solve the constraints of a BEP-Model, is based on MATHPAK.

8.11. ALGEBRAICCONSTRAINTS 153 constraints like those contained in a BEP-Model.

Another approach to solving the constraints of a BEP-Model is to use a numerical optimizer. This would nd a solution to the constraints that also maximizes some objective function. Orelup et al. [40] describe one example of an optimizer that could be used.

Chapter 9 Discussion

9.1 Contributions

This work produced four main results:

We produced a computer program that can turn a sketch of a mechanical device into working geometry by using a description of desired behavior as a guide.

We built a computer program that can speak the engineer's natural language, sketches.

This computer program can also produce design variants.

We created qualitative conguration space as a particularly powerful represen-tation for these tasks.

On the way to achieving these main results, we solved several important subprob-lems, including:

We developed a library of parameterized faces with constraints that ensure the faces implement monotonic interactions.

We developed ecient qualitative simulation techniques.

9.1.1 Turning a Sketch into Working Geometry.

We demonstrated that a computer program, using a description of the desired behav-ior, can turn a sketch of a mechanical device into working geometry. We did this by developing computational techniques to perform this task, and testing them with an implemented computer program called ^SketchIT.

To our knowledge, no previous work has addressed the task of automatically turn-ing sketches into workturn-ing geometry.

155

To perform this task, ^SketchIT uses a paradigm of reverse engineering fol-lowed by synthesis. During reverse engineering,^SketchIT identies what role each part of the sketch plays in achieving the desired overall behavior. During synthesis,

SketchIT generates geometry that implements the identied role of each part.

SketchIT works in the domain of xed-axis devices whose behavior is well ap-proximated with quasi-statics. We chose this domain because it is a large and use-ful class of mechanical devices, and because it is suciently tractable to facilitate our progress. Although our work focused on a particular class of mechanisms, the reverse{engineering{and{synthesis paradigm is applicable to a much larger class of design problems. For example, the paradigm could be applied to designs that rely on friction and inertia to achieve their behavior (see Section 9.2.1).

9.1.2 Speaking the Engineer's Language

When engineers communicate with each other, they frequently use sketches because they are a convenient way to both record and communicate design information. By creating a computer program that can interpret a sketch and transform it into working geometry, we have moved one step closer to CAD tools that speak the language that engineers speak to one another.

Traditional design tools are often dicult to use because they require the designer to use languages optimized for the program's convenience rather than the engineer's (e.g., nite element analysis tools require the engineer to describe a device as a mesh).

As a result, these tools often go unused until the later stages of design where they are used for analysis and documentation. A CAD tool that speaks the engineer's natural language would likely be used throughout the entire design process, in much the same way one would use a human assistant.

9.1.3 Design Variants

SketchIT produces two kinds of design variants: It produces the rst kind by re-placing rotating parts with translating ones and vice versa. It produces the second kind by selecting alternative implementations for the pairs of interacting faces in the device. We have demonstrated that the designs ^SketchIT produces include novel designs.

SketchIT represents each of its designs with a BEP-Model, a parametric model augmented with constraints that ensure the device produces the desired behavior.

The constraints in each BEP-Model represent the regions in parameter space (i.e., the space spanned by the geometric parameters) that provide the desired behavior. Thus they dene a familyof design solutions that the designer can explore in order to satisfy other design requirements, such as requirements on size or cost. We demonstrated that the BEP-Model's family of designs includes a wide variety of design solutions.

Because the BEP-Model's constraints prevent changes to the geometry that are

9.1. CONTRIBUTIONS 157 inconsistent with the desired behavior, the BEP-Model makes it easy for the designer to explore the design space.

During conceptual design a high premium is placed on examining as many design alternatives as possible. By producing many alternative designs,^SketchIT has the potential to greatly improve the conceptual design process.

9.1.4 QC-Space: As a Representation

SketchIT's primary tasks are to turn a sketch into working geometry and to produce alternative implementations. ^SketchIT uses the problem solving paradigm in Fig-ure 9-1 to perform these tasks. This paradigm is essentially abstraction followed by re-synthesis. ^SketchITrst performs abstraction, instead of going directly from the original design to new designs, because an abstract representation simplies the rea-soning process: A sketch contains an enormous amount of geometric detail, much of which is irrelevant to the behavior. The abstraction process strips away the irrelevant detail to expose what is essential.

QC Space

Reverse Engineer& Generalize Reverse Engineer& Generalize

Synthesize

Original

Design New

Designs

Figure 9-1: ^SketchIT's problem solving paradigm.

The question is, what is the right abstraction? For mechanical devices, the be-havior is achieved through interactions between component shapes. Hence, it is not the shapes themselves that are essential, but rather the interactions between them.

We suggest therefore, that the right abstraction is one that captures interactions but

strips away their implementations (i.e., strips away individual component shapes).

Qc-space provides precisely this kind of abstraction.

Because qc-space explicitly represents behavior, it is an ecient representation for mechanical design. Given the intimate connection between shape and behavior, design of mechanical artifacts is typically conceived of as the modication of shape to achieve behavior. But if changes in shape are attempts to change behavior, and if the mapping between shape and behavior is quite complex [2], then, we suggest, why not manipulate a representation of behavior? Our qc-space is just such a representation.

We suggest that it is complete and yet oers a far smaller search space. It is complete because any change in shape will produce a c-space that maps to one of the qc-spaces that our program will consider. Qc-space is a far smaller search space because a single change to qc-space maps to many changes in shape.

All of this would be for naught if the mapping from qc-space back to imple-mentation were dicult. However, this turns out to be a relatively simple problem:

Implementations for interactions can be cataloged; our interaction library is an ex-ample. By constructing catalogues with multiple implementations for each kind of interaction, it is possible to exploit this mapping as an opportunity to produce design variants, as indeed we do.

Our system is an existence proof of the value of qc-space as a representation. We used qc-space to construct an implemented computer program, and that program successfully turned sketches into working geometry and produced design variants.

9.1.5 The Library

Using libraries in design tools is not a new idea; the novelty here is in cataloging mechanical interactions. Conventional design libraries contain either complete com-ponents or small assemblies of comcom-ponents (e.g., [52]) that are concatenated to pro-duce complete designs. Our library, on the other hand, contains implementations for mechanical interactions. Because interactions are at a ner level of granularity than components or assemblies, our library provides much greater expressive power than does a conventional library.

9.1.6 Ecient Simulation

Our simulator employs several innovative techniques that reduce ambiguity in force balances. By reducing ambiguity, we reduce the amount of search (branching) re-quired to simulate a device, and hence reduce the amount of computation rere-quired.

We represent forces by their projections onto the degrees of freedom of the bodies to which they are applied. We can make this simplication without introducing inaccuracies because the projections are the only components of a force that aect the motion of a body. The advantage is that by simplifying forces to their projections, we greatly reduce the ambiguity in force balances.