How complex can joints get before Fusion's engine fails?

[dannym9999]

I'm designing a variant of a Stewart platform.  First I created one side with two struts and 1/3 the base and 1/3rd the platform.  All joints have reasonable limits defined on their range of motion.  The 1/3rd of the base is the grounded component.

All the joints move correctly on a side itself.  However,  I do an assembly and bring in 3 copies, connect the base legs into a full base, and then I can't connect things further.  It says there's a conflict and the parts won't attach, the two components are floating with the joint in red.

I approached differently by aligning the top 1/3rd platform in the correct position so nothing has to move, I just placed 3 copies in the assembly and the 1/3rd base and platform are already in perfect alignment so I just do a Rigid Group for the base and another for the platform.

But, at that point, none of the joints are red but they're frozen.  I can't drag the platform around, if I grab a joint and type in a new length or angle it won't graphically move and won't change once I hit enter.  I've reviewed the plan extensively, played with the single side component's joints, it's all legit and valid prior to assembly.  

This is on the heels of a prior rev that *barely* calculated all the Stewart platform joints when one is manipulated.  It calculated very slowly, I could make some small movements but its general tendency was to blow apart, disconnect  all the joints and mark them red.  This was a much cleaner rebuild with better design practice all around but now it just locks the joints up, they're all immobile.

Physically, the geometry should be fine.   But being a Stewart platform, each joint depends on every other joint. There's 33 movable joints in total.  Manually driving  a single joint will not have very predictable results as it finds a valid combination for the other 32 joints, but that would still be OK if it was usable at all.  It's not, it all froze.  This is telling me the Fusion 360 engine to calculate motion simply can't handle this- especially since the prior solution was also nonfunctional due to compute probs.

It really looks like I just hit a hard limit where Fusion just can't calculate how the joint geometry works.

The design is proprietary at this stage and I can't share it.  It's "different" but I'm certain the joints are mechanically correct and not locked because of any legit conflicts.

Is there any way to work around this?

[davebYYPCU]

... but I'm certain the joints are mechanically correct and not locked because of any legit conflicts.

Fusion is just as certain there are conflicts.

Remove all Joint limits, if conflicts remain then it's alignment/s

Might help....

[Drewpan]

Hi,

Proprietry is a pain sometimes. Are you able to create a simpler model that also reproduces the problem and share it?

This method often helps as the modeller realises what they are doing wrong in the first place and goes back and

fixes it, or the forum gets a go to try to help you solve it. We don't need to know what you are modelling exactly, just

the part that doesn't work.

Cheers

Andrew

[TrippyLighting]

As you cannot share your design, I am sharing a very stripped down, simplified version of this. It isn't necessarily the number of joints, but how they interact with each other.

[dannym9999]

it dawned on me this morning.  the config I designed is indeed legit, and easier to compute and drive in the real world.

But I see the problem.  I haven't been able to find the right technical terms yet.  The hexapod is different in that once you know the length of 5 actuators, then the 6dof orientation of the playform is already fixed and there is only one possible length for the  sixth actuator  In reality, this is a significant drawback in the design as any error in geometry creates physical geometric conflicts that result in unnecessary high forces that have nothing to do with supporting the load.

In this case, that design issue is resolved.  But Fusion has a liability in that it has to have a local minima for the calc to close.  This is a better solution designed to have full freedom and thus there are no local minima.  So, while mechanically correct, Fusion will never be able to calculate for this type of system.  It's stuck in an infinite loop trying to reconcile a coherent solution because its algorithm is fundamentally flawed in how it tries to converge on a solution.

Hmm, I think I can draft a simpler example that will expose this vulnerability in Fusion's engine instantly