# Using the geometric constraint solver

V-REP's geometric constraint solver functionality operates in a similar way as the kinematics calculation module, with the difference that the solver will try to automatically identify kinematic chains, and handle them in an appropriate way (automatic constraint adjustments, loop closures, etc.). Typically, the user has to tell the solver:

• which objects (dummies) should coincide (in order to close a loop for instance)
• what mechanism has to be handled by the geometric constraint solver
• which additional constraints should be applied to the mechanism
• Following section explains each of above items in details:

 Specifying closure constraints

Closure constraints can be seen as constraints that require two object's configurations (position and orientation) to be identical. The idea is illustrated in following figures (representation is limited to 2 dimensions for clarity's sake):

[The geometric constraint solver closure constraint]

[Closing action of the geometric constraint solver (1) intermediate situation, (2) final situation]

The geometric constraint solver will try to overlap the position and orientation of the two objects WHILE trying to keep the mechanism coherent (i.e. by only adjusting the joints in IK mode in the mechanism to reach that overlap situation). The objects that the geometric constraint solver uses to specify closure constraints are dummies. To this end, two dummies need to be marked as closure pair. This can be adjusted in the dummy properties by selecting the opposite dummy as Linked dummy and specifying GCS, overlap constraint for the Link type. Following figure illustrates two linked dummies specifying a geometric constraint solver closure constraint:

[Two linked dummies specifying a closure constraint]

 Specifying the mechanism to be solved

Next, the geometric constraint solver needs to be informed which mechanism it has to handle. Is considered one and same mechanism all objects that can be reached from a given object, by following a path that can go:

• from one object to its parent object.
• from one object to its child objects.
• from one dummy to its linked dummy (however only links of type GCS, overlap constraint)
• Two object trees that don't share any common parent objects (referred hereafter as elements), can also be part of the same mechanism if two linked dummies join them. This is illustrated in following figure:

[One mechanism composed by 3 elements (object trees)]

The last parent object of the object that is chosen as the starting point of the mechanism exploration (path exploration) is referred to as the base object of the mechanism. When the geometric constraint solver tries to solve a mechanism, it will try to do so by keeping the base object of the mechanism in place. This is important to remember. To specify a mechanism to be solved, select an object parented with the base object of the mechanism and in the geometric constraint solver dialog click insert new object. One same mechanism can only be registered once for solving. Mechanisms that do not include at least one joint in IK mode will not be handled by the solver.

Additional positional constraints can be specified for a mechanism. This can be done with two linked dummies that form a tip-target pair (specify GCS, tip/GCS, target as Link type in the dummy properties). Following figures illustrate two linked dummies, where one is marked as target (representation is limited to 2 dimensions for clarity's sake):

[The geometric constraint solver position constraint]

[Position constraint action of the geometric constraint solver (1) intermediate situation, (2) final situation]

The dummy marked as target is not considered as part of the mechanism and therefore will not move during geometric constraint resolution, while the other dummy will try to reach the same position as the dummy marked as target. An analogy can be made with the tip-target dummy pair in the kinematics calculation module. Following figure illustrates two linked dummies, where one is marked as target:

[Two linked dummies where one is marked as target]

 Geometric constraint solver operation

When building a mechanism that will be solved by the geometric constraint solver, make sure that the mechanism is coherent and that constraints are not impossible (i.e. that there are enough degrees of freedom for the mechanism to work).

Following figures show an example of a mechanism and its resolution:

[(1) Mechanism containing 3 elements before and (2) during simulation]

[Same mechanism, but different base object (1) before and (2) during simulation]

[(1) Mechanism containing 2 elements before and (2) during simulation]

During simulation, a mechanism that was previously registered to be solved with the geometric constraint solver can be manipulated in a flexible way with the mouse, when the mechanism navigation mode is selected. That mode can be enabled via following API call: sim.setNavigationMode(sim.navigation_ikmanip)

Simply click and drag any shape object that is part of the mechanism, and the solver will try to take into account that additional position constraint. Following figure illustrates such a drag operation:

[Mechanism with two additional position constraints]

It is good practice to build your mechanism as a tree structure (i.e. where all objects in the mechanism have at least one common parent object) and have linked dummies be in charge of closing certain tree branches. By doing so you reduce the mechanism's complexity, you simplify the mechanism's scene hierarchy representation, and you will be able to handle the mechanism as a model.

The geometric constraint solver functionality is very appropriate for simple mechanisms too, where direct and flexible interaction with the user is sought. Following figures give some such examples:

[Mechanism manipulation drag operation for simple mechanisms]

### Recommended topics

• Geometric constraint solver
• Geometric constraint solver dialog