Hi Fellows,
… as I have promised in:
https://forums.autodesk.com/t5/fusion-360-design-validate/ball-joint-mysteries/td-p/6301955
I will scribe below my additional divagations about the important compound joint described in F360 as a ball joint, which is, in essence, a gimbal joint.
For the starter, I will rectify/reiterate the remarks I made in:
https://forums.autodesk.com/t5/fusion-360-design-validate/scratching-the-ball/m-p/7567779
One must understand the purpose of gimbal joint (or Euler mathematics)
Sir Leonhard Euler developed it in the era when there was no electricity, no internet and particularly no YT, FB; he could google, ... but only to turkeys in his backyard.
So, instead of staring at celestial bodies on computer screens, people stared at celestial … stars … using gimbal principle-based instruments. Note that observers take the central position (like a pilot on a plane). A point they sit on is unique in the whole universe. Yes, a feeling is nice … but in the modern era of tensor theory (since Sir Newton and others), when the 'Democratic United Union of Floating Points' was established … the law states, "ALL POINTS ARE EQUAL !!!". Exceptions are only given to astronomers, pilots, cosmonauts, camera holders, drone flyers, politicians … and, obviously, some kids, old and new aristocrats, ... and the list goes on&on&on&... !
F360 follows this law, … glory (kudos) to F360 … however, not on some crucial occasions.
Ball Joint introduces heterogeneity into the system (in my opinion, at least) and, as such, is a troublemaker in many instances. It requires jiggling Euler space and cartesian space. Yes, it is possible, but the introduction of unnecessary complexity conforms to something I do not understand … It is like … the final admission by Galileo that the EARTH IS FLAT! However, with his challenging view, Copernicus preferred to die first, and after reaching his destination, he published proof that EARTH IS NOT FLAT.
Fusion360, in its development path … behaves like time stopped in the Middle Ages and the Earth is flat.
The compounded-rotational configuration of the ball joint is Z-X-Z, where Z axes allow measurement of angles between celestial bodies and X, a direction of a flat table (representing flat Earth) referenced to the north … is the strong evidence of it!
Such reference indicator/instrument has limited use in modern engineering practices, which depend predominantly on X-Y-Z axes configuration.
Unfortunately, F360 does not offer a compounded-rotational joint that is thoroughly compatible with the rest of its kernel computational mechanisms … and a modern way of engineering calculus.
The reason for such deficiency is … perplexing!
How difficult would it be to address the issue?
In my opinion, the task is not that arduous!
Disclaimer:
I based the judgement on my FicialIntelligence and the results from penetrating the SF Autodesk basement with my telepathic 6H antenna ether-waves. Please take it into consideration.
How is the current compounded (ball) joint mechanism implemented?
- It is a simple, straightforward matrix algebraic operation.
- Replacement of the used (as an argument) matrix will result in a different joint behaviour.
- The matrix itself is constructed as a non-commutative multiplication of respective rotation matrices along the joint's configured axes, e.g. 𝓡=𝓡(Z)⨂𝓡(X)⨂ 𝓡(Z).
- Although adding X-Y-Z axes configuration would be sufficient to alleviate the current burden …
- Many other rotation axes configurations (even exotic ones with mirrored axes) could also be introduced … in one go.
- mirrored axes? .... rigid mirror in the context of an assembly comes to mind!
- The respective API should be made polymorphic (kwarged with joint type) and defaulted to the current ball (gimbal) joint.
- Minor changes would be required to the current ball joint UI dialogue.
- All of the above … is as simple as building a flail, isn't it?
The simple surrogate solution, built straight in the F360 interface, is presented below. It is important to remember that it is not a substitute for the close-to-silicon technique. Three semi-compounded revolute joints are processed sequentially in the user interface, not as a wholly assembled matrix operation for all axes-rotation-in-one-go-as-ready-solution. The solver consumes them less reliably and might find some singularities on the way. It even behaves differently depending on whether revolutes are configured with limits or not.
I am attaching the F3D file as a template for implementing the X-Y-Z rotational joint configuration. I call the joint – a spherical joint. Obviously, the solution is only for 'despacito para los desesperados'. Professionals who prefer 'quickee-clickee' … must wait for TF360 to implement it in another F360 built, … potentially. How long would it take?
Note the deficiency of UI-based solutions. It is not only cumbersome but also unreliable. Play with the file; only dragging two axes produces the result. You will notice that even simple switching on/off joints limits causes additional problems. Why … I don't know, and I couldn't penetrate the underlying secret fully; I only suspect that the heuristic kernel classified the third axis as a dependent from the other two ... and deactivated it arbitrarily. The other two are also dependent, all three are in the circular dependence! The attached UI-spherical joint template is the plain vanilla generic one.
I am also presenting some visuals with build on top of it, some bijou, and exuberant CADtistic additions. If you still have like-some in your store, please feel free to unleash them on the template file.
Attached files:
SphericalJoint_Plain.fd3 F3D (0.4MB) https://a360.co/49CBH3o
SphericalJoint_plain.png 4K_mono (0.2MB) https://a360.co/47vGmSB
Golden_Hind_mono.jpg 4K_mono (0.3MB) https://a360.co/3QAnRG0
Golden_Hind_arcd.jpg 4K_stereo (0.4MB) https://a360.co/3SCGwDy
Golden_Hind_mono.mp4 4K_mono ( 36MB) https://a360.co/3FZb7E0
Golden_Hind_arcd.mp4 4K_stereo ( 63MB) https://a360.co/47gvU1F
To be viewed on 4K media devices (monitors, UHD TVs, projectors) of reasonable performance. For the best experience, use stand-alone media applications (WMP, VLC) and the native resolution 3840x2160 - full screen. The '_arcd' files require an anaglyph red/cyan glasses, while '_al' is for active shutter glasses 3D hardware (~30 deg viewing angle is recommended). Download the files over a network, where the cost of doing so is not a concern. The files are to be used for private, non-commercial purposes only.
Regards
MichaelT
