Angle property appears to be erratic

[sslupsky]

I've attached some screen shots below. I created an assembly with two sub assemblies. I constrained the parts using the "Plane Coincident" constraint. The Elements used for the constraint are two sketch circles within each assembly. When I set Lock Angle property of the Plane Coincident constraint to "True" and adjust the Angle property the result appears to be inconsistent / erratic. I've attached a screen cast that illustrates this.

OS: macOS 10.16
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24267 (Git)
Build type: Release
Branch: master
Hash: b2ca86d8d72b636011a73394bf9bcdedb3b109b7
Python version: 3.8.8
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: C/Default (C)

freecad asm3 angle issue.FCStd.zip

[sslupsky]

The initial condition of the angle appears to have an effect as well. So, using the example I attached above, if the initial condition is 0 and you change the angle sequentially to 10, 20, 30, 40, 50, 60, 70, 80, 90 Part001 rotates in clockwise 10 degree steps with respect to the x axis which puts the result in the fourth quadrant. If you start at 0 and pick an angle greater than 45 degrees, the rotation is clockwise with respect to the y axis which puts the result in the first quadrant.

[sslupsky]

I created a line segment in the sketches for each part. The line segment is a radial line from the centre of the circle to the perimeter with a horizontal constraint. When I apply the angle constraint to these two elements, I notice an information message that there is a redundant constraint:

11:28:32  41.742981 <asm3.sys> sys_slvs.py(63): redundant constraints

The DOF was 1 before apply the angle constraint and is now 0. I suspect the angle constraint locks down more than just 1 DOF so that likely explains the redundant constraints. (On a side note, it would be handy if each of the constraints indicated how many DOF is locks down when you mouse over it)

When I set the angle property of the angle constraint to 10 degrees, the solver generates an exception:

11:28:53  606.756386 <asm3.main> assembly.py(3681): solver exception when auto recompute
Traceback (most recent call last):
  File "/Applications/FreeCAD.app/Contents/Resources/lib/python3.8/site-packages/freecad/asm3/solver.py", line 109, in __init__
    self.system.solve(group=self.group,reportFailed=reportFailed)
  File "/Applications/FreeCAD.app/Contents/Resources/lib/python3.8/site-packages/freecad/asm3/sys_slvs.py", line 67, in solve
    raise RuntimeError(reason)
RuntimeError: inconsistent constraints

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 530, in _catch
  File "/Applications/FreeCAD.app/Contents/Resources/lib/python3.8/site-packages/freecad/asm3/solver.py", line 416, in solve
    return _solve(*args,**kargs)
  File "/Applications/FreeCAD.app/Contents/Resources/lib/python3.8/site-packages/freecad/asm3/solver.py", line 386, in _solve
    Solver(assembly,reportFailed,dragPart,recompute,rollback)
  File "/Applications/FreeCAD.app/Contents/Resources/lib/python3.8/site-packages/freecad/asm3/solver.py", line 112, in __init__
    raise RuntimeError('Failed to solve {}: {}'.format(
RuntimeError: Failed to solve freecad_asm3_angle_issue#Assembly: inconsistent constraints

The "inconsistent constraints" error message doesn't seem to shed any light on what the root cause is. The two edges in the sketch are linear edges and it appears that is what is required for the Angle constraint.

I have attached the updated model with the additional constraint.
freecad asm3 angle issue.FCStd.zip

[realthunder]

The angle constraint is internally represented using cosine by the algebraic solver. Therefore, there will be four angle positions that satisfy the constraint. In most cases, the solver will pick the nearest position that satisfied the constraint. There is no real solution to this problem aside from not using angle constraint if you can. You may want to consider using Attachment constraint, which works without using the algebraic solver. Make sure the involved parts are only constrained usingLock and Attachment constraint, or else it might be auto converted to Plane Coincidence constraint and feed to the solver. You adjust the constraining element's Offset property to get the designed angle.

[sslupsky]

Yeah, that is what I suspected was the root cause of the issue.

I did play around with the Attachment constraint. At first I could not figure out how to rotate the part but I think I determined that you can descend into the element and change the rotation there.

[edwilliams16]

There is more to this than the angle constraint actually constraining +-cos(angle), not angle itself. I have a simple case of two objects with a collinear constraint. If I change the constraint angle from 140 to 260, the placement changes to 170.
But cos(260) != +-cos(170) so it is not one of the four valid solutions. In fact cos(260) = -sin(170) which may provide a clue to the bug. https://forum.freecadweb.org/viewtopic.php?f=22&t=58638 is a discussion. I enclose test files that exhibit this. Just change the AxialAlignment constraint.
axle_indicator.zip

[bambukouk]

@edwilliams16
@realthunder

github link doesn't work...
hopefully this works better:
https://forum.freecadweb.org/viewtopic.php?f=22&t=58638

I can understand how Lock and Attachment constraint might work better.
This can be done easily for a simple model.
For my (far more complicated) model, PlaneCoincidence and AxialAlignment constraints further down the line are unavoidable for the assembly to work correctly.
Is this going to cause problems?

[realthunder]

But cos(260) != +-cos(170) so it is not one of the four valid solutions. In fact cos(260) = -sin(170) which may provide a clue to the bug.

This is not really a bug. Since 260 - 170 = 90, they are actually perpendicular. The angle lock is implemented using SolveSpace same orientation constraint with the second normal transformed using the user specified angles. The implementation of same orientation is here. From the code, you can see that the corresponding algebra equations is for the z normals of two coordinate system to be equal parallel, and match either x1 with x2 (i.e. au.Dot(bu)), or x1 with y2 (i.e. au.Dot(bv)).

In other word, there are four possible solutions for a same orientation constraint.

[realthunder]

As to why not use the Angle constraint, it's because the Lock angle option is meant to lock all three angles, and it would obviously overconstrain the system if we use three Angle constraints.

[edwilliams16]

Thanks for the explanation. I can now see why the code behaves as it does, and that keeping increments in the axial angle less than 45 degrees should work around this. I am curious that same orientation doesn't mean both z and x axes aligned, but also allows z's aligned and x aligned with y. What's the rationale/use case for this? In our application, only allowing the first case would give behavior that would be more expected.

[realthunder]

I am not entirely sure. I can only guess that this is to help the solver finding a solution, i.e. smaller search space required.

[eokogbue]

Hello, I've encountered the same issue as discussed regarding the angle property. I would add that in my case if the angle is <0.12 degrees there is no movement in the parts.

I understand the suggested workaround involves using attachment constraints, but my scenario involves additional constraints (besides 'lock' and 'attachment') in the main assembly that complicate this solution.

Given these conditions, are there any recent improvements or alternative suggestions for effectively managing 6DOF placement between two parts within a subassembly? Any guidance or updates on handling such a scenario would be greatly appreciated.

Thank you!