Drake: Add a generalized acceleration port to MultibodyPlant

[felixcra]

What is the reason, that MultibodyPlant does not give access to the generalized accelerations?

[sherm1]

@felixcra do you mean why isn't there an output port for the accelerations? You can get the generalized accelerations for a continuous MultibodyPlant by calling EvalTimeDerivatives().

The reason there isn't an output port is that no one has requested one yet. Joint reaction forces are related and were requested recently so PR #12123 added the port. In the process of doing that, generalized accelerations were cached via #12050. However, no port has been added to expose them. Are you requesting that?

[felixcra]

@sherm1 Yes thats what I meant. Indeed it would be useful for my usecase if MultibodyPlant had an output port for the accelerations.

[sherm1]

OK, added to our work queue @felixcra.

[edrumwri]

Hi @felixcra,

There are actually a number of ways to do this in the meantime.

I think the simplest would be to hook up a DiscreteDerivative to the state output of MultibodyPlant (get_state_output_port()). If you're using the discrete version of MBP (i.e., you constructed it using MultibodyPlant(h) with h > 0), you'd construct the DiscreteDerivative using the same h. Then the velocity variables in the output of the DiscreteDerivative would correspond to the generalized accelerations. If you're indeed using the discrete MBP, you'll get exactly the generalized acceleration.

FYI, I haven't tried this and the output might be time delayed by h.

[felixcra]

Hi @edrumwri
Thanks a lot for getting back to me!
I managed to work around this by adding an output port to the MultibodyPlant class.

Offtopic: I have some questions that are neither issues with the software itself, nor well suited for Stackoverflow, but rather about recommendations about how the software is intended to be used for certain things. Where would be a good place to ask these? Is there like a mailing list or so?

[sherm1]

@felixcra:

• the #onramp channel of drakedevelopers.slack.com might be a good place to start
• stackoverflow could also be ok for general advice
• any interest in submitting a pull request to add the acceleration output port to MultibodyPlant in Drake?

[sherm1]

BTW when adding the generalized acceleration port, also add one that reports body spatial accelerations.

[sherm1]

I'm working on adding MBP acceleration output ports.

Question regarding model instance ports: on the input side we provide an actuator port for every model instance, regardless of whether it actually has any actuators. But on the output side we do not create output ports for model instances that have no state. Here is the current port diagram -- the ports in orange are conditional on non-zero-length data while the ones in black are not:

Does anyone remember why we handle model instance ports differently in input and output? It would be easier to code and document if we produce a port per model instance consistently for input and output, even if the corresponding data has zero length. The ports don't cost anything if no one uses them.

cc @edrumwri @RussTedrake @amcastro-tri @rcory @EricCousineau-TRI @jwnimmer-tri

[edrumwri]

I have absolutely no idea why it was set up that way (and I didn't realize it was, even though I've operated in that code base).

[sherm1]

I see that the input port side was changed to generate ports for all model instances (by @edrumwri in PR #10738 in response to issue #10694 due to problem encountered by @mposa).

My proposal would be to do the same for the output ports.

[EricCousineau-TRI]

I'd be on board with that - sounds much simpler.

[edrumwri]

Me too. Thanks for reminding me that I instituted this change to actuator ports @sherm1!

[amcastro-tri]

My proposal would be to do the same for the output ports.

I like that.

[felixcra]

Sorry for not getting back to this questions. I added a pull-request with the code I used in order to acces the generalized accelerations #12353. It's only for continuous time accelerations though.

[sherm1]

See PR #12354 for a more ambitious version.