Edited by Leslie Gordon
The growing use of PDAs, tablet PCs, and electronic whiteboards has spurred the demand for better freehand-sketching programs that work with CAD, simulation, and animation applications. Why? Because freehand sketching provides a natural, efficient, and convenient way to visually represent ideas. It also mimics drawing with pen and paper, a big advantage over traditional window, icon, menu, and pointer GUIs.
Users can use a freehand-sketching program with almost no training. Further, studies in cognitive science have shown that freehand sketching does not break users’ thought processes. The method is particularly useful in early stages of design where fluidity and ease of construction encourage creativity and the rapid exploration of ideas.
For these reasons, we have developed a freehand-sketching program called FEAsy (FEA made easy) that transforms informal freehand drawings to structured representations. This process is generally termed “beautification.” Users create sketches in the program using any of a variety of devices that mimic the classic pen-and-paper approach, such as a Wacom Cintiq 21UX digitizer or a Microsoft Tablet PC SDK.
Currently, FEAsy only handles static FEA. The rationale for the yet-to-be-finished program is that commercial FEA and simulation packages tend to have steep learning curves. Even the solving of simple 1D and 2D problems demands the user follow tedious processes that usually fall into four main steps: (1) setting up the problem, which involves selecting the element and selecting and defining materials; (2) creating the geometry; (3) defining the loads and boundary conditions; and, (4) meshing, solving, and visualizing results.
Of these tasks, users often find it most onerous to build geometries and specify load and boundary conditions. The ensuing cognitive load causes users to work more slowly and have trouble paying attention. FEAsy’s intent is to let users work just as they would draw on paper with minimal constraints.
Our approach to the beautification of a freehand stroke involves tasks such as resampling, segmentation, recognition, merging, and geometry-constraint solving. Basically, the hardware first samples the raw points comprising a stroke and then resamples them, or spaces them uniformly.
During segmentation, the code recognizes the critical points that divide the stroke into its constituent low-level primitives (in this implementation, arcs, circles, and lines). These critical points are “corners” of the piecewise liner strokes and also the places where curve and line segments connect. After segmentation takes place, the program next recognizes the low-level primitives. The recognition method is based on a form of least-squares analysis.
The initial critical points sometimes contain false positives. To compensate for this, the merging procedure repeatedly merges adjacent segments, if the fit for the merged segment is lower than a certain calculated error. This action determines when to merge two lines into an arc, for instance.
Finally, the program infers and satisfies geometric constraints without much user intervention. Users naturally express geometric constraints such as concentricity and tangency when sketching. Other constraints the program infers include parallelism and perpendicularity.
To date, the program lets users pose problems up to the simulation stage (up to solving and visualization) as they would on paper — naturally and intuitively. The code then exports a unified data file as a set of commands (like a script) specific to the FEA software (here we use Ansys).
Elements in the current implementation are commonly used in structural and static FEA. They are a 2D solid spar — in Ansys, the equivalent is PLANE42 — and a uniaxial tension-compression element. The spar element is defined by four nodes having two degrees of freedom at each node: translations in the nodal X and Y directions. The element properties include Young’s modulus, ε, and Poisson’s ratio, v, as well as geometric information such as cross-sectional area.
The drawing program defines a stroke as a set of temporally ordered sampling points captured in a single sequence of pen-down, pen-move, and pen-up events. Heuristics comes into play to distinguish between text, geometry, and gestures (such as a downward single-arrow symbol to represent force) or symbols (such as a circle to represent a roller). For example, one criteria used to distinguish between text and geometry is that when a shape is less than 0.125-in. high and (or) the gap between continuous strokes is less than 0.03125 in., the shape is a letter or number.
The program lets symbols and geometry be specified in a single stroke or multiple strokes, and there are no requirements that the parts of a symbol or geometry be drawn in the same order every time. To accommodate this and simplify recognition, users switch pen colors (switch modes) when specifying geometry or symbols. Text can be input in any mode. Besides reducing ambiguity, multicolor gives sketches visual clarity.
In general, users begin in Geometry mode and the program classifies the stroke as text or geometry. When a stroke is text, the screen updates the text label. Otherwise, each stroke is translated into a series of low-level geometric primitives.
Next, the program identifies the spatial relationships between the primitives, representing them as geometric constraints which are then solved by the geometric solver LGS 2D. Output from the solver is the beautified shape, which is updated on the screen. Users can continue sketching or switch modes again. The program processes stroke input in Symbol mode in a similar fashion.
Finally, the code groups and associates the symbols, text, and geometry with each other to correctly interpret the context (loading conditions, boundary conditions, and geometric constraints).
Research has shown that users draw related objects in such a way that they are closer to each other. Thus, this is how the software associates and groups objects to provide the context. For instance, a load (downward single-arrow symbol) in a problem associated with F = 100 (text) and point P3 implies that a force of 100 units in the –Y direction is applied at P3.
Similarly, a double-headed arrow associated with 20 units and line L1 implies that a dimension constraint equal to 20 for length of L1 is added to the geometry and satisfied by the geometry constraint solver. (FE solvers such as Ansys do not require any units, but assume the input is consistent. Our system also behaves along similar lines. Hence, users must ensure that input units are consistent.)
After completing the sketch, users click the Output button. A dialog box asks for the material properties, element description, and meshing parameters (if any). A scratching gesture indicates an area needing meshing. The sketch is then suitable for import into FEA software.
A more-concrete example comes from a 2D cantilever beam with a point-load applied at its end. Starting in Geometry mode, the user sketches a rectangle. When the pen is lifted, the program beautifies the input and displays it. The user then switches to Symbol mode to write the boundary conditions, loads, and dimensions. A press of the Process button processes and displays the input. These steps can be repeated to make changes.
Next, pressing the Output button opens a dialog box in which to select a material from the library. For this problem, the user might choose steel with ε = 30e6 and v = 0.3. Similarly, the element type (PLANE 42) and other parameters are input. The program exports the model geometry, boundary conditions, loads, materials, element, and meshing information in the form of a unified file to run in Ansys. This lets users view the result (for this example, a displacement vector sum plot).
Our ultimate goal for FEAsy is that it becomes a freehand-sketching program for 1D and 2D FEA that includes all four steps. Hence, future work will include the addition of a FE solver and visualization capabilities. Also on the agenda is including 3D and other types of analysis besides structural.