Massless, position-controlled control surfaces

[blandry]

A position-controlled control surface that is massless could be supported in the URDF the same way we do wings with a _forceelement. Instead of a wing inner tag, the _forceelement would have a _controlsurface inner tag. The _controlsurface would have the same attribute as the wing (chord,_nominalspeed,profile,span, _stallangle). The main difference is that the parent link of the _forceelement would not be the link corresponding to the control surface itself, but of its actual parent (for example the parent of an aileron would be the wing link).

Then in the parser, instead of creating a RigidBodyWing, we create a RigidBodyControlSurface which is a child class of RigidBodyWing. RigidBodyControlSurface inherits all of the methods of RigidBodyWing and only needs to override computeSpatialForce. computeSpatialForce does the following:

-Forward kinematics of the RBM (which doesn't include any control surface) -Forward kinematics of the control surface only -Compute aerodynamic force on the control surface -Returns the force as an external force

Now the problem with this approach is in computing the forward kinematic of the control surface. This depends on the input, which we don't have access to from inside computeSpatialForce (we only have access to the state). Any suggestions?

[RussTedrake]

Excellent. Thanks for starting this discussion. I totally agree with everything you’ve written here.

The computeSpatialForce not taking u is a subtle thing. If we allow it to take u, then the manipulator dynamics are no longer control affine… which is a very important feature of the manipulator dynamics that is used in a lot of places. I should say - this is not a problem with the computeSpatialForce, but a problem with the entire idea of using a position command directly as an input. (btw - i love that the class hierarchy alerted us to this detail). To say it another way - i can’t actually represent these dynamics in the form H(q)*v + C(q,v) = B(q,v) u.

I’m not sure yet what the best way to deal with this is. One solution (though I really don’t like this) might be to add a separate class to the hierarchy which has some, but not all, of the RBM structure. (e.g. H(q)*v = f(q,v,u)). And only allow control surfaces for that class (which would presumably have to be a superclass of the RBMs).

On Apr 30, 2014, at 9:50 AM, Benoit Landry notifications@github.com wrote:

A position-controlled control surface that is massless could be supported in the URDF the same way we do wings with a force_element. Instead of a wing inner tag, the force_element would have a control_surface inner tag. The control_surface would have the same attribute as the wing (chord,nominal_speed,profile,span, stall_angle). The main difference is that the parent link of the force_element would not be the link corresponding to the control surface itself, but of its actual parent (for example the parent of an aileron would be the wing link).

Then in the parser, instead of creating a RigidBodyWing, we create a RigidBodyControlSurface which is a child class of RigidBodyWing. RigidBodyControlSurface inherits all of the methods of RigidBodyWing and only needs to override computeSpatialForce. computeSpatialForce does the following:

-Forward kinematics of the RBM (which doesn't include any control surface) -Forward kinematics of the control surface only -Compute aerodynamic force on the control surface -Returns the force as an external force

Now the problem with this approach is in computing the forward kinematic of the control surface. This depends on the input, which we don't have access to from inside computeSpatialForce (we only have access to the state). Any suggestions?

— Reply to this email directly or view it on GitHub.

[blandry]

I also really like working with actual RBMs. This is what is allowing us to leverage a lot of the tools built for Atlas. Also we might want to think about the fact that if we had a continuous model with position control, there would be nothing already implemented that would stop our solvers from finding input trajectories that make control surfaces "jump" from one position to the other, the velocity limits are only implemented in the LCP solver as far as I know.

So I guess we could try to narrow down the reason(s) why we want to do position control in the first place. Of all the possible reasons I can see right now there is:

• Reducing the number of states
• Have joints that don't affect the dynamics other than the aerodynamics
• Have massless/inertialess joints that don't start spinning as soon as we apply torque to them
• Make the mapping Drake output -> real-world plane input easier

Maybe narrowing down our goal a bit more will make this possible.

[RussTedrake]

I talked to ani about this this morning. Another proposal (that I made; I would say Ani is only luke warm to the idea) would be to linearize the contribution of the control surface. (the aero forces can be nonlinear in all the state variables, but only linear in control input). It’s again not great, but perhaps the best solution I can think of so far.

On May 2, 2014, at 10:33 AM, Benoit Landry notifications@github.com wrote:

I also really like working with actual RBMs. This is what is allowing us to leverage a lot of the tools built for Atlas. Also we might want to think about the fact that if we had a continuous model with position control, there would be nothing already implemented that would stop our solvers from finding input trajectories that make control surfaces "jump" from one position to the other, the velocity limits are only implemented in the LCP solver as far as I know.

So I guess we could try to narrow down the reason(s) why we want to do position control in the first place. Of all the possible reasons I can see right now there is:

Reducing the number of states Have joints that don't affect the dynamics other than the aerodynamics Have massless/inertialess joints that don't start spinning as soon as we apply torque to them Make the mapping Drake output -> real-world plane input easier Maybe narrowing down our goal a bit more will make this possible.

— Reply to this email directly or view it on GitHub.

[blandry]

This sounds reasonable although it would be nice to at least have a metric of how much error the linearization would introduce. The other thing I can think of is something like

1) Simulate the initial guess with position control backed by LCP 2) Disable position control on the plant, make the initial guess for the input to position-controlled joints 0 3) Run trajectory optimization which will find torques 4) Re-enable position control 5) Build the input solution for the position-controlled joints using the states solution, ignoring the torques we actually solved for

[RussTedrake]

That would work for trajectory optimization, but we're looking for a more general solution - for simulation, analysis and feedback design as well as optimization.

I agree we want to understand the error from linearization. But remember, the idea that our original inertial model of the control surface is still a gross approximation - for instance treating it as an independent airfoil even though it's physically attached to another wing.

On May 2, 2014, at 1:46 PM, Benoit Landry notifications@github.com wrote:

This sounds reasonable although it would be nice to at least have a metric of how much error the linearization would introduce. The other thing I can think of is something like

1) Simulate the initial guess with position control backed by LCP 2) Disable position control on the plant, make the initial guess for the input to position-controlled joints 0 3) Run trajectory optimization which will find torques 4) Re-enable position control 5) Build the input solution for the position-controlled joints using the states solution, ignoring the torques we actually solved for

— Reply to this email directly or view it on GitHub.

[RussTedrake]

FYI - Asked some of the aerodynamics profs about this, and they seemed to think that the linear version is not only standard, but that it's relatively hard to do better.

[RussTedrake]

Just asked Mark Drela about this. First of all, he said that there is no simple answer - that you really have to do wind tunnel testing to get anything accurate.

If we choose to use xfoil, it sounds like we can add a flap in xfoil and extract the Cl, Cd etc for different deflection angles, then interpolate them ourselves. He recommended polynomial / tri linear interpolation. And also reminded me that it will not give useful answers after the stall angle, and that we should enforce the basic trivial periodicity constraints (and the 0 lift at 90 deg).

[RussTedrake]

this is being addressed in the new c++ rigid body system design.

[RussTedrake]

may revisit in the future, but not immediately relevant in the c++ code.