Bullet Solver Feedback - local space torque?

I am exploring Bullet Solver for the first time in more depth since it’s release and having a fun time of it, but quite stuck on the problem of applying torque in a specific local space direction to an actor using a hinge constraint.

My bigger goal here is potentially building autonomous “creatures” that can eventually learn to walk through random “genetic” iteration of creation parameters etc.

However right now I’m just trying to make a leg work right.


Here’s what I do have working so far. The red block is the “body”, right now I just have it suspended in the air with infinite mass turned on.

The light grey block is a “leg” I guess, and it’s connected via a hinge constraint with limits in either direction.

torqueFlipDirection

While this works more or less, there is a big problem that breaks the system when the parent (red) is rotated manually via Ry parameter.

rotateBodyFlipDirection

When the red block rotates past 90 degrees, you can see how the grey block droops, then when it’s rotated closer to 180, it flips in the other direction.

While I’ve re-simplified my attached TOE file to the problem shown above, I’ve tried a mess of things with matrix calcs, quaternions, and vectors. Maybe I’m overcomplicating it though.

The closest I got was with matrices was putting the leg in it’s parent space, and calculating it’s 2d rotation and comparing it to the “target” 2d rotation giving me an angle. Still broke down once the parent rotated past 180 degrees and the rotation flipped back around.


Is what I’m trying to do possible? Is there an easier way?

Thanks!

bullet solver torque challenge.4.toe (10.2 KB)

You’ll run into odd behavior like that when transforming actors directly because as far as the simulation is concerned it’s just teleporting without momentum/velocity. If it’s occupying the same space as another actor the simulation will displace them accordingly, which is what you’re seeing here with the lag effect.

It sounds like the red body should be moving so I’d recommend making it dynamic and not static, then modify its position indirectly with some sort of velocity. Or, since you want it to move around from torque applied to legs, you may not need to apply any velocity to the red body directly (perhaps if you need it to turn left/right) – it’s velocity can be solved for by any torque applied to the legs + the constraint relationship with the legs.

thanks for the input. When make the red body dynamic, and apply 10 torque it actually causes the whole thing to spin out of control in a way that doesn’t make sense to physically, though I suspect that’s because the torque is sort of applied to the object irrespective of what else is it’s constrained to, and the limits it’s hit or not hit?

torque_fly

It’s almost like the torque is applying some kind of world space force, or wind to the leg, and due to sheer force taking the body with it even though it’s mass is 10x the leg.

bullet solver torque challenge.5.toe (11.2 KB)

The constraint limits don’t stop force/torque from being applied to the body. When it’s body to body the constraint limit is applied relative to both bodies, so when one body can’t move anymore along its constrained axis (due to the limit), then both bodies will begin to spin in the same direction.

What I think would be better is to use impulse torque forces so that force isn’t continuously applied to the leg and red body as a result.

Alternatively you could use a feedback system to modify angular velocity of each leg to move it and then set it to 0 once it has moved enough. You may run into problems clobbering angular velocity like that however, as there may be velocity from sources other than your intervention via feedbacking.

I’m not entirely sure if either of these will give you your desired results since I’ve never tried to build a system such as this, though I am quite intrigued by your project.

1 Like

good to know! That’s what I figured, torque still being applied and all.

Well, before I started this thread I had actually gotten quite far by doing exactly what you were saying about applying torque or velocity (could you explain the difference functionally?) but diminishing it as it reached it’s target.

I essentially generated a “target” leg angle, and extracted the current actual leg angle, so if target was 90, and actual was 70, then I would generate the velocity/torque by 90-70=20, and apply that difference via feedback.

This worked, but introduced a grandfather clock issue where the leg wobbled back and forth continuously never settling on it’s target, but I was able to remedy that nicely by introducing dampening, which really all that means is I scaled the 20 (rotation distance to target) by a factor, say 0.5 or something in the 0-1 range which caused it to not overshoot.

I bet a custom lookup curve would be nice for fine tuning this response strength down the line, but I digress…

This essentially made it to where the constraint limits usually weren’t reached, and the leg would simply flip from one target position to another target position using for now, a key press or button etc for testing.

Below I am driving backlegs and front legs with Q and E respectively.

banana dog

This works pretty well all things considered, except for one massive fatal issue… I am calculating my rotation difference that I feedback to the actor by subtracting one angle from another, but those angles stop meaning what I think they mean as the creature starts to meander off it’s original axis…

aka they are world space, not local space if that makes sense.

So, here’s the creature rotated 90 degrees, you can see that even though I’m pressing keys madly in the beginning nothing happens, then as the drift causes the creatures to rotate just enough the velocity starts to overcome the hinges constraint since it as 5 or 10 degrees towards the functional axis… again if that makes sense:

banana dog struggles

so, I thought ok if I calculate my legs rotation not in world space, but relative to the red block, or in the above gif banana, the rotation will always be oriented to the creatures body, which is what I’d want.

This ALMOST works, the problem now is that rotation matrices when rotated eventually flip the rx/ry/rz values around to the other side because it doesn’t have a way of tracking number of revolutions etc… so randomly after crossing a certain rotational plane, the whole leg system goes bonkers, flips into reverse mode, and will kinda spasm till it moves away from that … matrix “seam” if you will.


So that’s where I’m stuck. Maybe someone more familiar with quaternions would have a dif solution here, since they handle rotation entirely differently.

Also side note, would be cool if the bsolver feedback chop had an extra slot for reference object, like how the object chop has. I tried using the object chop to extract this info as well, but still ran into the same problem, even with “Smooth Rotation” enabled.


If you want to try it out, init, then sim, then use Q and E to move the legs.

bullet solver creatures.33.toe (17.8 KB)

2 Likes

Yeah, it looks like you are quite close to getting it. That’s cool to see.

However the transform issues you’ve highlighted are apparent and I run into them right away when running the sim.

Rotating the leg velocity vector so it’s always along the shared plane of the legs / body would’ve been my suggestion, but it sounds like you may have already tried that from this comment here?

so, I thought ok if I calculate my legs rotation not in world space, but relative to the red block, or in the above gif banana, the rotation will always be oriented to the creatures body, which is what I’d want.

That’s correct! I am doing that but my rotation value that I feed into the feedback gets flipped due to the inherent nature of matricies and how they decompose to rx/ry/rz values. Here’s a different example that shows how ry by itself gets snapped from top to bottom.

transform rotation flip

Normally this doesn’t matter because the resulting orientation/xform of the object is identical, but because it’s a simulation responding to tension in a specific direction, as soon as the creature rotates past that snap point things break down.

I’m going to keep fiddling as I have time. For some reason I feel like vectors may be useful here… though everything I’ve tried results in the same issue.

Maybe I’m missing a reference vector that represents the normal of the shared plane that you mentioned…

Anyhow open to any suggestions! Thanks for going down this rabbit hole with me :slight_smile:

1 Like