Mimic/Maya flipping axis without warning

[rider-rebooted]

This is a massive nightmare for me, although maybe I don’t have a thorough grasp on how Maya/Mimic works.

In order to do an overhead orbit, I’ll wind back the tool so that it almost reaches its axis 4 limit then parent the tool to a target, rotating it until it’s back to the centre of its limits then continue animating for the rest of the program.

The problem I have is that instead of warning me about limits in the latter part of the program, it just flips the axis at the start. When I play it back, the start has errors instead.

It’s also inconsistent. Sometimes I’ll press play or scrub and there will be no errors a the start, just at the end and vice versa.

[evanatherton]

This is due to a limitation in the IK solver - but once you understand what's going on, it shouldn't be too hard to work around.

Long story short, the IK solver can only solve between +/- 180 degrees, even if the robot's limits are beyond that. This is because 182 degrees (for instance) results in the same physical location as -178 degrees (182-360). So in Maya, you'll notice axis 4 (and 6) flipping between +/- 180. We fix this in the postptocessor so that it exports a continuous path. Unfortunately that makes it harder to track what's happening on axis 4 and 6, which typically have larger ranges

The reason the results are inconsistent is it depends on where you start, and how much you rotate. If an axis limit is reached, we try to slide the solution by 360 degrees and check if that makes the path work. I'll give you a hypothetical:

Let's assume your robot has Axis 4 limits of +/- 350 degrees (as most KUKAs do). Let's say you want to do an orbit that causes axis 4 to rotate 1.5 times (540 degrees). If you start with the controller in a position that results in Axis 4 = 0 degrees, then you rotate your controller so that axis 4 rotates 1.5x, Maya will show position 1 as 0 degrees, and position 2 at 180 degrees. When you export, we fix the flipping, so the path will go continuously from 0 degrees to 540 degrees. But 540 > 360, which is an axis limit violation, so we subtract 360 from the path and check again. So now the path goes from -360 to 180. But -360 is also an axis limit.

Now imagine you start your target so axis 4 starts at 11 degrees instead. The path starts out as 11 degrees to 561 degrees. Again 561 violates the upper limit, so we subtract 360. And now it goes from -349 to 201. And that path doesn't violate any limits, so that's the one we export. So you can see just by offsetting your starting point a little bit, you're giving the robot more options. If you're only trying to go 360 degrees and you really want A4 to start at 0, that doesn't give the robot many options.

As an additional note: I made some changes to this behavior recently, so if you're on version 1.4.1 or earlier, you could see different behavior.

This is unfortunately the thing that bugs me most about Mimic, but I've done the best I can to try and work around it. Happy to jump on a call with you sometime and walk you through it if you'd like, just let me know.

[rider-rebooted]

Hi @evanatherton

Thanks for your offer to jump on a call, although I think I now understand what your saying (after reading this many times ha ha).

If this is the case, to avoid inconsistency, would it be possible to pin a preferred axis orientation value for 4 and/or 6 at the initial keyframe? E.g...

I click 'set IK' for my first point and Mimic presents me with a drop down menu of the possible orientations for axis 6 and 4 (including 'dynamic' which would lead to current behaviour). This choice would then dictate how Mimic analyses the program.

Or have I got this wrong, i.e. Making no difference to the scrubbing and playback behaviour?

I wonder if Maya's IK solver can be modified or a custom Mimic friendly IK solver plugin could be developed.

[evanatherton]

In the initial release of Mimic I actually had a whole system for doing this inside Maya with buttons to flip axis 4 and 6 representations. Then you'd set an IK keyframe at the initial position to tell Maya that's the representation you wanted. You can download that version and try it out. Ultimately, for reasons too long to explain, that solution was really cumbersome and some users found it much more trouble than it was worth, so I removed all of that. As a related note: you no longer have to set an IK keyframe for the program to export like I said in the getting started video.

If you use the head of the main branch on GitHub (as opposed to the latest release), I actually added a feature that gives you the option to select which one you want when you post processes. But as you said, this wouldn't make any difference to the scrubbing playback behavior.

That behavior is actually from the Mimic solver, not Maya, and it's a problem all analytic solvers have, because at the end of the day, you have to do an arccos, which only produces results in two quadrants. So it's a math problem unfortunately. Trust me I've spent countless hours and all sorts of things to work this one out :(

[evanatherton]

@rider-rebooted p.s. You can actually unlock A4 and A6 on KUKAs to give you infinite rotation. Then you barely have to think about it. The biggest thing to watch out for (which John just posted about on Slack) is to make sure you unwind the physical robot when needed. And obviously watch out for your cables getting wound up

[aatb-ch]

I think this issue might be solved by the new Check for Redundant Solution feature on Export?

[aatb-ch]

Also side note: The infinite rotation is not valid for all robots. Only on robots with fully mechanical 4-5-6 assemblies with motors on the elbow. Some robots have the servo 6 internally mounted in the axis 4, which means some cables go through and you can only have about +-360deg on axis 4, not infinite.