Mechanical rigs with sliding actuators

I am trying to make two rigs where the control is at the end of a linear actuator/piston. The piston can likely be done with a simple stretch to with a limit constraint to stop it at end position, but how do I tie this functionality to the other rotations?
I’ve tried several versions but am not getting close. Here’s the blend file with empty meshes (877.9 KB)

The first rig (left in image) has a piston connected to a quadrilateral linkage. It would be nice if the piston is fully extended before the linkage starts swinging, but that is a nice to have. My main aim is for the piston to extend and the linkage to swing using only one control.

The second rig (right in image) has the piston connected to a simple hinge that can rotate around its own (Z) axis. The control is yet again at the end of the piston. Here I need the hinge to track to the control somehow, while only allowing rotation around its own axis.

For your second one, try the Track To constraint, which will rotate an object to point at another object. For your piston, you may need a Stretch To constraint, which stretches an object to point at and touch another object.

Thank you, but I am not sure how you mean. I tried what you said here (861.9 KB)

I added a track to constraint (for bone Hinge.Tracker), but with no idea of how to isolate this to rotate only around Z axis I had to add a second bone (Hinge) with a transformation constraint.
Now the issue is that I am limited to global coordinates. The rig is a mix of ‘local space’ and ‘world space’ constraints to make it work, causing any adjustments to the Main bone to mess up the rig. Additionally there is something odd with the transformation constraint, and it has discontinuities when the hinge rotates more than ~40deg.

Is this what you’re after? test_rig3.blend (871.6 KB)

2 bone layers, control layer is visible. No stretch to (mechanical things don’t stretch), just damped track and locked track.

Spot on! That solves the second rig at least. Thank you very much! I will have to take this apart and remember your solution.

An unexpected bonus is how the “cylinder tip” follows the control, rather than rotating with the “cylinder base”. I had not thought about this as a need, but it is a very useful function!

Stretch constraint is something you find in many many blender tutorials for cylinders (I originally found it in a very old cgcookie tutorial). In my second post in this thread you can see how the stretched bone affected is used only to guide its children, and nothing mechanical. The trick is to disable inheritance of scale, making it a very useful tool for all things sliding.

Yeah, if you have children with disabled scale inheritance, it’s okay to use for rigid bits. In your file, it’s not set up that way, and it’s not necessary either.

I’m not commenting on the first one because I don’t know what you want. The file for the second one was enough for me to see what you were after.

No both bones ‘Piston.Base’ and ‘Piston.Tip’ have Inherit Scale set to None.
Not that it matters, since the rig fails in about every other way. I like yours more :slight_smile:

The first rig is maybe a bit more confusing. Using two control bones I can get it done, sort of. See my crudely hand animated explanation. It would be nice if the piston control bone could control piston extension as well as the “swinging” motion of the linkage bars - so that I could skip the upper control bone. There is some IK solution hiding here that I just cannot find on my own.
Aditionally it would be nice if the piston is fully extended before the swinging motion starts (like in my movie clip), but that is not necessary.

Oh pardon, I didn’t even see one of those, thought Piston was deforming.

With your first item, part of the issue is there’s more than one solution, given a particular root and control position. I made something that doesn’t exactly meet your demands, but I think it’s probably a little bit better than your demands:

laggedIK.blend (142.3 KB)

It uses an IK with rotation to track the control for the trapezoid. Rather than tracking the control directly, it tracks a bone with a limit distance (inside) constraint, targeting the control, to lag the control. If you tune the distance of the constraint, it will change the behavior.

There are circumstances that wouldn’t be great. There are reachable positions that this won’t reach. It’s just what I ended up making, hopefully it’s good enough for you.

1 Like

It’s briliant. Thank’s again! The solution has its peculiarities, but I’m mostly amazed by how you went about it.

  • I would never have thought to use a distance limited bone act as a delayed driver for a desired function. This I will remember.
  • I will have to read up on ‘damped track’ vs ‘track to’ constraint since I can never get along with the latter, and you have survived solely using the former.
  • About the solution to parent bone ikT to trackLag, and then using ‘copy location’ to a bone at the root of ikT to isolate only the rotational part. I’m equal parts dumbfounded and perplexed. A simple ‘copy rotation’ (plus an added 90deg roll to both ikT and ik3) would have sufficed, but your solution is so elegantly demonstrating parts of the constraints toolbox I’ve never bothered with. Love it!

It’s an overdetermined system, true, so there are of course infinite solutions. With that said, letting the iTaSC solver work it’s magic will often produce very nice results, so I was imagining some solution using only IK constraints. However, even if this is possible it would not be able to provide the desired delay.

It’s frustrating how a system, like this one, can be fairly straightforward to describe with simple trigonometry and conditional movements but requires severe brain gymnastics to describe as a Blender rig. Addictively frustrating!

Difference is entirely in the bone roll. A damped track does shortest-path rotation-- like quaternion interpolation. Or probably more properly, like axis-angle rotation. A track-to is a lot more like a pair of locked tracks, like Euler interpolation. I basically never use a track-to. (I don’t do mechanics though, I do organics. Still, mechanics that get represented by Eulers/track-tos are usually better represented by dividing the rotation into multiple bones anyways.)

Inherit rotation from parent and copy location via constraint, or inherit location via parent and copy rotation via constraint, it doesn’t matter. Same thing.

I’m not sure it’s simple to describe-- at least, it wouldn’t be for me. Any time you have a system that you feel comfortable describing via math, you should think about using drivers instead of constraints, they’ll let you specify things more carefully.

From what I have played around with so far the drivers seem made for ease of use and simpler transforms, and if you require more you’re better of with the python API.
It wouldn’t surprise me if there’s a way to tie python scripts and functions to drivers, but unfortunately my python/numpy is pretty weak.

However, the system here (at least “kinematically” speaking) really is easy to describe based on very basic trigonometry, so I guess I’m just making excuses and that it can be expressed using only the ‘Simple Expressions’ preferred by the drivers.
Still though, there’s something more rewarding about figuring out a rig solution without scripting it!

There’s not such a sharp line between python and drivers-- drivers are python, or at least, can be. I almost always use “scripted expression” drivers. I can fit what I need into a single line (sometimes simplifying some expressions on paper beforehand). I know it’s entirely possible to have a multi-line script, but I’ve never actually found it necessary.