Scratching the ball

[MichaelT_123]

Hi TF360,

I played recently with balls … F360 ball's joints, just to be precise. The sensations I experienced were not pleasant … to say the least.

I still believe I am sane, although I always suspect that it might not be 100%. So, please take it into account.

Let's look at the test exercise, I self-inflicted upon … myself. It is about the creation of basic ball joints -  asBuiltJoint and byJointOriginsJoint types in this exercise.

Dissecting the screencast, which might not be too clear at first glance, brings some observations:

• Both joints (created in a default manner) behave identically
• The pitch position of them is aligned with the Z-axis (as indicated in the creation dialog's field)
• The yaw is assigned to the X-axis
• However, when animating the joints, pitch becomes a rotation (or roll) along the X-axis
• Additionally, yaw is turning on the Z-axis
• It is in the reverse of what is stated in the creation dialog box
• It should be pointed out that all components and the design's coordinate systems are congruent
• Much more, as most balls have three axes of symmetry, the created ball joint has only meagre two of them
• Thus, pitch and roll occupy the XZ plane together, happily married there and taking a bizarre planar 90-degree respective position
• Other than that, they perform the same duties, which are meaningless in the context of the Creator's intentions
• After modifying the pitch and yaw to Z and Y axes respectively, the only difference is that, although they behave as they should, the pitch and roll still cannot divorce …. they change the plane and keep the position though … and that is all.

I am attaching the BallJointTest.f3d files and uploading the short screencast. Please note that I am not reserving any rights to the balls… you can un-scratch them freely… 

THIS IS THE RAMBLING I WAS GOING TO POST ….

… but at the last moment, I had once again searched the F360 Forum …

I checked it before, but perhaps I only searched its subsection. The final search of the whole forum made me delighted, … that so many people have suffered the same itching … so I am not alone! If you ever have such a sensation, look at the fascinating article  Ball Joint Mysteries.

Particularly, Mrs.? kgrunawalt  gave there a very knowledgeable, deep explanation that a ball joint is in reality a gimbal joint!!! It did not cure me, of course, but at least gave me a soothing relief … and the impulse to find a remedy. The beautiful 'Mannequin' by Mr. dcgeorge64L4M also helped!

REMEDY ….

I, as many others, would prefer to deal with a real spherical joint and its intuitive behaviour of rotation around orthogonal axes, as well as a tensor abstraction of its mathematical representation (matrix in F360 terminology), which is very useful in a parametric style design.

The model BallJointTestC.f3d shows how to create an emulation of such a joint. As an example, I use spherical bearing (which triggered the case), but it could be adopted to more advanced scenarios. In verbose terms, the steps are as follows:

• Create a standard ball joint (asBuilt or in the conservative fashion)
• Lock the roll axis of a joint
• Select proper axes for pitch and yaw if necessary
• Create a revolute joint selecting appropriate elements in your design (in the example, the 'Shaft' and 'ShellRing' were used)
• Make sure that the plane of the revolute joint is perpendicular to the pitch/yaw twins
• Apply joint limits as required
• Now you can control the joint in as predictable a way as cloudbase9 would steer a plane.

Here are two pairs of files attached. 

BallJointTest_B, BallJointTest_4K_B.mp4,

BallJointTest_C, BallJointTest_4K_C.mp4,

The files with the postfix 'B' stand for a 'standard' ball joint model and its simulation in the form of a *.mp4 video. The files with the postfix 'C' show the same simulation scenario but with an 'emulated' spherical joint. Stimuli for both simulation runs are the same – continuous roll(0,360deg), pitch(-20,20deg)(0) and yaw(0)(-20,20deg) separately. Of course, roll values drive different roll/rev motion joints.

The difference is very evident. In the 'C' – emulated case, I am in complete control of the joint's position.

In the standard, trivially built ball joint, I can't control rotation (roll). A pitch is problematic, also.

Why, because there is a 'gimbal lock' in place … the joint has only two degrees of freedom …

MY GRAIN OF SALT …  (please consider it as an appetiser)

One must understand the purpose of the gimbal joint (or Euler mathematics)

Mr. Leonhard Euler developed it in an era when there was no electricity, no internet and particularly no YT, FB …

So, people, instead of staring at celestial bodies on computer screens, stared at celestial … stars … using gimbal principle-based instruments. Note that in both cases, 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 Newton and others) when the 'Democratic United Union of Floating Points' has been established … the law states "ALL POINTS ARE EQUAL !!!". Exceptions are only given, amongst others, to astronomers, pilots, cosmonauts, camera holders, drone flyers, and politicians.

F360 follows this law, …  glory (kudos) to F360 … however not on some important occasions …

Ball Joint introduces heterogeneity into the system (in my opinion, at least) and as such, is a troublemaker. 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 … Copernicus preferred to die first. After reaching the destination, he published the proof that IT IS NOT …

SUGGESTION for TF360 (if I may) …

It would be relatively easy to add another member to F360 joints' portfolio – a spherical joint. The creation of a congenital ball joint, a gimbal joint, would also be a good fact, as it would lessen confusion.

Technically, everything is in place already, even the tensor/matrix4x4 representation. What is required? Only a nice interface encapsulation (hopefully better than the jittery ball joint implementation), a set of functions/methods and precise documentation.

Apart from saving us from hours/days/weeks of frustration and removing the gimbal lock obstacle forever, there would be another, which might not be so obvious, benefit. Chances of people making jokes about the new joint could be significantly diminished (although there still will be no certainty)

Regards

MichaelT

[jeff_strater]

Thanks for that extensive, well-thought-out, and helpful article.  I plan to take a look at your models, and explore them more fully.  I think your suggestion of a new type of joint is a good one, and I'll enter it with your explanation in full copied into it.  Of course, I can't guarantee it will get implemented any time soon (if only I had that power...).  I do appreciate the effort that you've put into the analysis.  It's nice to have customers who take that amount of time to understand what is there, and communicate ideas to improve Fusion.

Jeff

[jeff_strater]

One small problem, @MichaelT_123 - the link for the model to "BallJointTest_C" appears to be a duplicate link the the mp4 for that model, not a link to the model itself.  Would definitely like to see that model, so if you could re-post it, I'd appreciate it.

Jeff

[MichaelT_123]

Hi Jeff,

I was just checking the diligence out there … and you spotted it straight away.

… but semi-seriously … even I make mistakes!

Here they are …

Regards

MichaelT