Unable to correctly model motion of a universal joint ?? What ??? What is wrong here?

lee_harrison288

See this simplified demo please

https://cad.onshape.com/documents/bb6a496ef5cfc5b2f1385f9c/w/8538187e0d2974595389bb07/e/b6ee2a5a23b5d009cdeec44f?renderMode=0&uiState=68ed72b3cdd2d7c9826b7d6e

This is on a public account called "DemoMotionProblem" so you can copy it and play with it if you want to.

This is just a demo of the geometry of the bog-standard universal joint. In this demo one "shaft" is simply fixed: the light blue at the bottom. The spider is in dull red and the free shaft is in dark blue. The parts are mated with two revolute mates, and this is the symmetric universal joint (aka gymbal) where the two axis shafts are orthogonal and co-planar. If you view from the right and grab the spider (red) it will pivot properly (ditto with the angular motion control), and the free shaft will follow as it should. But if you grab the free shaft (dark blue) or use the motion control on it … it's locked in this axis. The assembly works properly in the other.

Obviously this is kinematically wrong. Is this some error on my part? If so, I don't see it. There are dirty sort-of work-arounds for this with a combination of a ball mate and some other constraints … but why would I need to explore those? My real application requires the system not be co-planar (you can see there is another bore in the spider to test this case too) It doesn't work either, and I don't see any path to faking that.

GregBrown

The kinematics will work out fine if you don't overconstrain it. In my edit here I have unfixed the light blue block and given it a cylindrical mate to origin. The end of the dark blue free shaft is a ball mate (to a position off-vertical just for a better demo). I've used the non-planar spider setup. Note that the light blue shaft needs to have a bit of translational DOF (hence the cylindrical mate.)

lee_harrison288

I greatly appreciate an answer … yet "did this answer the question" doesn't have any intermediate "not really" … so I checked "no." This isn't quite my application and it also raises many more questions in my mind. My application is actually a gimbal mechanism rather than a drive-shaft universal (so the base is actually fixed), and I will need to examine your answer carefully … but it is in the flavor of "dirty work arounds" I mentioned. I may be able to "make something work…." however it is within a more complex but very common real system, that I am modeling, and my purpose of modeling all of this is writing a rather extended application note, a bit more about that below.

Further, I was/am hoping to really understand Onshape's mating and kinematics … I don't want to be obnoxious but I am a PhD engineer/scientist and a skilled numerical analyst and programmer who was originally trained in flight dynamics — I sure should be able to do this kinematics; in principle could write the algorithms to do all of this … but of course that's a very big job to do generally .. as Onshape does it.

If one considers the system with revolute mates as an abstract constraint, it is clearly not "over constrained." Gimbal tables work … have worked since Galileo's time at least. I have a suspicion I do know the answer for what is going on here … is the Onshape solver doing it differentially with Euler angles and rotation matricies (rather than quaternion rotators) … and experiencing gimbal lock? I am not being snotty — this isn't a trap question I created … you can see my application here in the following system — that is the most common way simple aircraft controls are built. If you substitute a ball mechanism for the universal "it all works" in Onshape, and some aircraft systems do use a ball joint, but the ball angles needed are fairly large and commonly (often due to component acquisition/certification problems too) the small universal is preferred.

https://cad.onshape.com/documents/e6747512928fce5f1533c57b/w/a9f9fd506022ed3cbff7aed4/e/b134a4e17b4704894b535adb

Also, just to explain a bit further … the point of the little monograph I am writing is to explain the issues of Vee-tail mixers — the kinematics and dynamics of controlling an aircraft that has a Vee-tail rather than a conventional one, as for various reasons (drones a big one) these are coming back into fashion but much of the knowledge about them is not widely known, and there are subtle dangers and issues. Here is a well-designed Vee-tail mixer done in Onshape, and it works kinematically as mated:

https://cad.onshape.com/documents/e6747512928fce5f1533c57b/w/a9f9fd506022ed3cbff7aed4/e/1be2a95f8901ca1dfd2bedeb

In terms of my monograph I can substitute a "magical ball joint" and get on with it showing the universal alternative and explaining that kinematically animating it isn't straightforward … that's OK, but I do want to be sure I am not being a dummy about Onshape, and also would like to understand Onshape more deeply … and the documentation isn't written for people like me.

***

Also, as an aside … re your comment about "a bit of axial freedom" the system already has axial freedom in that the blue shaft is free, so I don't understand that at all?

S1mon

The internal calculations have some slight floating point errors. If multiple mates are all trying to constrain something in too many degrees of freedom it can cause issues with the kinematic solvers.

eric_pesty

At first I thought the issue you are running into is due to the mate connectors defined at the assembly level… I did get it to work briefly as it was but I have found it needed "something" to cause it "look" for the next degree of freedom and adding a limit to the roll axis causes the pitch to "wake up":

I wonder if it's a "recent" optimization as I hadn't run into this before even though I have created similar "U-joint" geometry before…

You can always relocate the triad axis to allow movement though the triad but it's not as "natural":

eric_pesty

Just to add…
I went back to an older doc where I had a U-joint and it allowed me to move it along both directions by dragging even without limits. I do wonder if it will start behaving differently after the document is updated to the latest library version…

It was an example doc I created for this video:

https://www.youtube.com/watch?v=lIwuF4WdSxw

john_lopez363

@lee_harrison288 …something like this…maybe?