Scratching the ball

[MichaelT_123]

Hi TF360,

I played recently with balls … F360 balls joints to be precise. The sensations I experienced were not pleasant … to say at least.

I still believe that I am sane, although I always suspect that might it might not be full 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 -  asBuildJoint and byJointOriginsJoint types in this exercise.

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

• both joints (created in a default manner) behave identically
• the pitch position of them is aligned with Z-axis (as indicated in the creation dialog’s field)
• the yaw is assigned to X-axis
• however, when animating the joints pitch becomes a rotation (or roll) along X-axis
• additionally, yaw is turning on Z-axis
• it is in the reverse what is stated in the creation dialog box
• it should be pointed out, that all components and design’s coordinate systems are congruent
• much more, as ‘most’ balls have 3 axes of symmetry, the created ball joint has only meager two of them
• thus, pitch and roll occupy XZ plane together, married happily 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 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 last moment I had once again searched 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 will ever have such sensation, look at very interesting article  Ball Joint Mysteries

Particularly Mrs.? kgrunawalt  gave there the very knowledgeable, deep explanation that a ball joint is in the 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 behavior of rotation around orthogonal axes, as well as a tensor abstraction of its mathematical representation (matrix in F360 terminology) very useful in a parametric style design.

The model BallJointTestC.f3d shows how to create an emulation of such a joint. As the 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 (asBuild or in the conservative fashion)
• lock the roll axis of a joint
• select proper axes for pitch and yaw if necessary
• create revolute joint selecting appropriate elements in your design (in the example the ‘Shaft’ and ‘ShellRing’ had been used)
• make sure that the plane of the revolute joint is perpendicular to pitch/yaw twins
• apply joints limits as required
• now you can control the joint in as predictable way as cloudbase9 would steer a plane.

Here, are attached two pairs of files. 

BallJointTest_B, BallJointTest_4K_B.mp4,

BallJointTest_C, BallJointTest_4K_C.mp4,

The files with postfix ‘B’ stand for a ‘standard’ ball joint model and its simulation in a form of *.mp4 video. The files with postfix ‘C’ shows 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. I the ‘C’ – emulated case I am in full 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 ‘gimbal lock’ in place … the joint has only two degrees of freedom …

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

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

Mr. Leonhard Euler developed it in the 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 seat 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 ‘Democratic United Union of Floating Points’ has had been established … the law states “ALL POINTS ARE EQUAL !!!”. Exceptions are only given, amongst others to astronomers, pilots, cosmonauts, camera’s holders, drone flayers, 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 Earth is flat … Copernicus preferred to die first and after reaching the destination he published the proof that IT IS NOT …

SUGGESTION for TF360 (if I may) …

It would be quite easy to add another member to F360 joint’s portfolio – spherical joint. A creation of congenital to ball joint, gimbal joint would also be a good fact, as it would lessen confusions.

Technically, everything is in place already, even 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 a precise documentation.

Apart from saving us from hours/days/weeks of frustration and removing the gimbal lock obstacle forever, there would be another, might not be so obvious benefit. Chances of people making jokes about 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