Motor Control for Physics-Based Character Movement

[Aardwolf]

This question is a bit different from the usual "How do I simulate X?" that gets asked on here... I have the simulation aspect working, and am trying to figure out how to control it, i.e. "what values do I need to send to the motors to produce Y behavior?"

If there's another forum that would be more suitable, let me know. Otherwise, here goes:



Introduction:

I have a simulated biped with bones and joints like this:



I am trying to come up with a control algorithm for it, so that it can do all of the things the player character in an FPS needs to be able to do. Yes, I know this is more sophisticated than what most (any?) FPS games bother to do, but this is the project I have chosen.



(section added 2016 July 16)
Problem Formulation:

Given:

• The state of the Dood (that's what I named the class)
• Scalar control states "yaw" and "pitch" (in radians), "forward" and "sidestep" (fraction of max walk speed in a direction, from -1 to 1) and boolean "jump" (doubles as jetpack control)
• Any other information about the world which might be useful, e.g. nearby terrain geometry

Find:

• Torques to apply on each axis of each joint; there are currently 19 joints = 57 degrees of freedom, subtract 4 because the knees can only rotate/torque on 1 of their 3 axes
• Forces to apply at each of the jetpack nozzles; there are currently 10 (3 in each shoulder and 2 in each foot)

How I define "satisfactory" is subject to change, but the important things are the ability to match target values for the following:

• Head orientation; forward vector is higher priority than other axes
• Gun orientation and position; again forward vector is top priority; other axes of orientation, and position relative to the eye point, are lower priority
• Net acceleration as determined by forward and sidestep controls; eventually if 'jump' or jetpack is engaged it should also account for vertical acceleration

Other intermediate goals may be devised to help satisfy the above. Some possible intermediate goals might be:

• Position and orientation for each foot, and of the pelvis
• Position and orientation of each of all of the bones; alternatively this could be expressed in terms of desired forces and torques on each bone
• Trajectories in joint angle space (I've seen some papers that work in these terms)

However, I am always cautious (perhaps overly so) about the possibility that introducing intermediate goals might over-constrain the problem.



The Upper Body Algorithm:

I have an algorithm that works reasonably well for the upper body, allowing him to look and point his gun in various directions, but which relies on being able to dump "extra" torque into something. For example in this video the pos/ori/vel/rot of the pelvis bone is being reset at the beginning of each simulation step:

https://youtu.be/9Tr52MN3Qjs
(warning: the gunfire sound effect is sudden and loud; consider turning your volume down before watching)

However this algorithm is not generalizable to the lower body, because it relies on being able to sink that extra torque into something.



Lower Body Algorithm?

I had a solution that worked for the lower body, under a narrow range of initial conditions, but I have made no progress generalizing it. I tried posting on gamedev.net asking for help, but the subject matter seems to be too advanced for anyone there. Description of the algorithm that sort of worked can be found in that thread: Motor Control Redux.

Also Motor control for physics-based character movement for previous discussion of the problem.



Help Pls?

I am at a loss as to how to proceed (but I am too stubborn to give up and do it the "gamey" way).

Any assistance will be greatly appreciated.

[bone]

Isn't this what inverse kinematics is for? I believe that's what is used for robot motion planning, and that's essentially what you're doing (except your "robot" is purely virtual).

[Aardwolf]

Inverse kinematics (or any sort of motion planning) will give me per-bone x, v, a, θ, ω, and α, but a simulated character cannot manipulate any of these quantities directly. What I have control over is the per-joint applied torques τ.

Consider the seemingly mundane task of maintaining the initial pose, assuming the character starts out in a stable standing pose. No motion planning is required, but it's still non-trivial to figure out what joint torques I need. I can compute the per-bone F and τ needed, but those are the per-bone F and τ coming out of the constraint solver, and I only have control of the per-joint τ going into the constraint solver ... and there are less joints than bones.

[bone]

OK, fair enough. I'm not familiar with controlling robot motors, but don't they eventually need to be given power to apply some goal torque or something? Or is it just some PID control on a goal location/angle? If so, could you simulate such a PID yourself?

[Aardwolf]

I realize I relied too heavily on the links to do the summarizing for me. I have updated the OP to include a "Problem Overview" section (and also section names).

When I said "motors" I meant it figuratively; I don't actually use volts/watts/amps. I control the torques directly for each of 3 axes of each joint (except the knees which have only 1 axis), and I'm trying to come up with an algorithm to determine what values to use for those torques.



PID ... from the papers I've looked at on the subject*, people generally don't use an integral term. I think it's because you often end up with the controller trying to accomplish something impossible for an extended period of time, and then the goals change and suddenly it's doing something totally undesirable because of all that built-up integral term.

I tried PID once, a couple of years ago ... granted that was before I started looking at papers. At the time I got frustrated by a) the problems with the integral term, and b) the fact that my goal quantities weren't specified in terms of joint orientations, they were in terms of bone orientations. But now I'm wondering if I can rely on the feet loosely "constrained" to their orientation by virtue of the contact forces with the ground, which if it remains consistent would mean I can specify the goal ankle orientation as the goal lower leg ori relative to the constrained foot orientation, and so on up the skeleton until all bones' goal orientations are dealt with. So maybe I will give PD another shot.



*There are papers, I just can't understand them well enough. For example:

• This is so far the only paper I understood well enough that I thought I could implement it ... and ultimately I failed. But it got me started on the QP idea which eventually led to the first and so-far only marginally-working lower-body solution (see Motor Control Redux)
• This one I discovered more recently and haven't spent as long trying to understand it, but it also looks relevant, and perhaps simpler than the one above.

[Erwin Coumans]

You can use Inverse Dynamics, a constraint solver or PD to compute joint/motor torques. You can control joint motors in position, velocity and/or torque control. When using position or velocity PD control, you can also use constraints to achieve the goal (set the desired joint position and/or velocity). For articulated figures, such as characters and robots, it is convenient to use reduced coordinate multi body simulation, for example using Featherstone articulated body algorithm. Bullet has this implemented, including contact and joint motors that lets you set position and/or velocity targets with P/D tweak values. See https://github.com/bulletphysics/bullet ... intMotor.h

Also, Bullet has some example that compares inverse dynamics based computed torque control with PD control, see the Bullet Example Browser:

inverse_dyn.png

[Aardwolf]

Wow, a lot has changed in Bullet since I was last using it.

I ended up ditching Bullet in 2012 because of performance reasons (no offense, Erwin). When I dropped 2000 balls on a terrain heightfield, no matter what I did to tell the collision detection code "these objects cannot collide with one another", it always ran at 2fps, and IIRC most of that was in collision detection.



Featherstone... someone mentioned that to me in a PM on the gamedev forum but when I tried to research it I couldn't find a simple enough summary. Reduced coordinate system, you say? So iow it actually removes the degrees of freedom for things like "joints coming out of their sockets"? Neat.



I gave PD controllers another try this weekend, this time with GA for tuning (versus manual tuning when I did it a couple of years ago) and it's working surprisingly well. For the task of maintaining an initial pose, at least.

I feel stupid for not trying it again more recently... although, the justification I gave myself was that the goal quantities were not in terms of relative joint angles, so it didn't make sense to use PD controllers to map joint angle trajectories to joint torques... and I hadn't realized that if I treat the foot orientations as constrained (by virtue of the contact forces), the orientations of the remaining bones of the character can be expressed in terms of joint angles.



So for now I'm going to stick with GA+PD, and maybe try to implement some of the other components mentioned in MvdP's Generalized Biped Walking Control paper.