Turning some of the states in a Drake system into inputs

Question

Consider an existing Drake System (for example MultibodyPlant). Is there a way to wrap that System inside a Diagram in such a way as to convert some of the states of the internal System to be inputs instead, i.e. set directly from input ports of the outer Diagram?

The motivation would be essentially to make a change in modeling decisions. For example, a quadrotor is sometimes considered to have its angular rates and collective thrust as inputs, instead of the collective thrust and body moments (or similarly, individual rotor commands).

In a more complex system, perhaps I might assume I have instantaneous control over certain velocities (e.g. internal, fully-actuated joints with fast dynamics), but still want to model the entire multibody system's dynamics accounting for the current choice of velocity in terms of Coriolis terms etc.

What I'm getting at is actually very similar to the modeling choice for the elevator in the Flat-Plate Glider Model - but I'd like to avoid manually implementing a LeafSystem because my system has nontrivial multibody dynamics.

My sense is that this may not be possible since I don't know of any way for a Diagram to interfere with the internal dynamics of a System, so "deleting" a state and promoting it to an input seems impossible. But I thought there might be some clever method to do this.

Thanks in advance!

Answer 1

I agree with your analysis. The simplest answer is "no" -- systems that declare state cannot be post-hoc exploded to have that state come from an input port. But for the specific examples that you mention, there are a few possibilities / related ideas.

The first is the notion of a prescribed motion constraint -- e.g. that one can set the positions/velocities of joints in a MultibodyPlant directly. We don't implement that yet, unfortunately, but it is a reasonable request that we've discussed occasionally (here is one example: https://github.com/RobotLocomotion/drake/issues/14694).

As you say, you could implement a PD controller just outside of the system to achieve the desired effect. The only real difference between this and the way that we would implement the prescribed motion constraint internally, is that we can choose the gains well and inform the solver about that constraint directly.

Another possibility is to implement a force element that works "inside" the plant and accepts an input port. This would allow you to apply forces to implement your modeling ideas even in ways that are not possible through the actuation_input_port (e.g. not achievable by a declared actuator).

The glider example you link is a good one. In that case, I was very worried about having a model that avoided even declaring the velocity of the elevator as state (since our verification methods scale in complexity with the dimension of the state space). For now, that still requires writing a bespoke LeafSystem implementation.