Reducing Search

The brute force approach|exhaustively enumerating all possible values for the lo-cation and slope of each qcs-curve|is clearly impractical in any non-trivial design task. As a result we have identied two sources of knowledge that allow us to prune the search space: knowledge about the mapping from the sketch to qc-space and knowledge about trajectories in qc-space.

3.3.1 Mapping to QC-Space: Small Targets

There are circumstances in which small variations in the geometry of the sketch pro-duce qualitative changes in the behavior. When the program detects these conditions, it asks the designer well focused questions about his intent.

One such circumstance occurs when a numerical cs-curve is nearly vertical or nearly horizontal. If the cs-curve really is vertical or horizontal, the interaction is stop behavior (i.e., one body limits the motion of another); but if the cs-curve is sloped even very slightly, the interaction is pushing behavior (i.e., one body pushes the other). A small change in the slope of the cs-curve produces a qualitative change in behavior. Thus, when the program identies a numerical cs-curve that is nearly vertical or nearly horizontal, it asks the designer if the interaction is intended to provide stop behavior.

Another set of circumstances occurs when the end points of two numerical cs-curves are coincident, or nearly so. This is likely to have been intentional, because it corresponds to a common and useful piece of behavior: if two cs-curves connect end to end, the device can slip from one engagement pair to the next with no disengagement in between. Henceif two numericalcs-curves (nearly) connect end to end, the program asks the designer if a smooth transition between engagement pairs was intended.

The \V" in the top of Figure 3-1 illustrates the use of these questions in the circuit breaker example. The program notices that the cs-curve for the lever-stop engagement pair is nearly vertical and asks if we intended stop behavior; in this case we did. The program then asks if the end points of the lever-stop cs-curve and the cam-follower cs-curve are intended to be coincident; again they are, in order to allow the device to slip from one pair of engagement faces to the other without disengaging.

Finally, the program notices that the other ends of the two cs-curves have a coordinate

3We implemented only the rst and last of these, because that was enough for the three examples we used to test ^SketchIT, and because computing c-space curves is a relatively well understood problem that was not a focus of this work.

3.3. REDUCINGSEARCH 59 in common and asks us if this was intended, but this is just coincidental. The \V" in the gure reects our answers to these questions.

The program asks questions when it detects small targets in c-space, but notice that these questions are very sharply focused. For example, when the program notices a vertical or horizontal curve, it does not ask the user \what did you mean?", but rather asks the very specic question, \is this intended to be a stop?"

The generator examines the c-space of the sketch for the presence of small targets before it abstracts the c-space to qc-space.

3.3.2 Debugging Rules

In Section 2.2.4 we demonstrated that the behavior of a device can be described as a trajectory through c-space. For example, Figure 2-6 shows the trajectory describing the behavior of a device composed of a rotor and slider.

Because we can describe the behavior of a device as a trajectory through c-space, we can describe the desired behavior as a desired trajectory. The topology of the c-space can have a strong inuence on whether the desired trajectory (and hence the desired behavior) is easy, or even possible. This is equally true in qc-space.

We have begun exploring the use of (but have not yet implemented) debugging rules that examinewhy a particular qc-space fails to produce the desired trajectory, based on its topology. If we can diagnose these kinds of failures to produce the desired trajectory, we may be able to generate a new qc-space by judicious repair of the current one. Several of the debugging rules we have explored are:

If the qc-space has a funnel-like topology that \traps" the trajectory, the qcs-curves should be moved to eliminate the funnel.

Any qcs-curve that is never touched by the trajectory is useless, and should be moved.

If a trajectory terminates at a spring neutral position before it reaches a desired encounter with a particular qcs-curve, the neutral position should be moved to the other side of that qcs-curve.

Another kind of debugging strategy is to try to determine which qcs-curves are likely to be correct (i.e, provide a suitable behavior), so that the modications can be focused on the other qcs-curves. One approach to this strategy is to simulate each arc of the state transition diagram individually to determine which arcs produce the desired transitions (i.e., for each state in the diagram, check if the external inputs for the arc leaving that state causes a transition to the next state). The qcs-curves used to achieve the desired transitions are likely to be correct. Modications should be focused on the other qcs-curves.

Chapter 4