search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.34k stars 1.27k forks source link

Discrete input ports for discrete MultibodyPlant #12786

Closed amcastro-tri closed 4 months ago

amcastro-tri commented 4 years ago

The conclusion in #12643 is that when using a discrete MultibodyPlant model of the world, input ports must behave as being "discrete". That is, the dynamics of a discrete system is described as y[n+1] = y(t[n], x[n], u[n]), notice the "discrete" input u[n] evaluated at discrete intervals.

Contrast this to what we have today in MBP: y[n+1] = y(t, x[n], u(t)), which really is a "hybrid" system given u(t) changes continuously.

The only way to remedy the situation to represent y[n+1] = y(t[n], x[n], u[n]) is to make inputs discrete, and therefore to include additional state for t[n] and u[n], emulating a ZOH as described in #12643.

As described in #12643, today we emulate discrete inputs with a "hack" that relies on having caching enabled. This works great most of the time since we do use caching. However, as described in #12643, it stops working properly, and especially during initialization, when caching is disabled!.

Related; old issue #10888 identifies a performance issue stemming from the fact that in the past we were invalidating u(t) continuously, leading to re-computation of expensive contact forces. The solution there proposed is not correct, this updated issue reflects that.

cc'ing @RussTedrake, @siyuanfeng-tri

edrumwri commented 3 years ago

Just as an update. We've been observing a strange issue where MBP (running at 0.001 step size) was pulling our controller at intervals in between the 0.001 step size: think 0.001, 0.002, ..., 0.031, 0.032, 0.033, 0.03333333, 0.35, ...

The 0.033333 is to be expected: we are publishing to Drake Visualizer and contact results are being queried at that time.

What we don't expect is the absence of pulling from our controller at 0.034! That means: a. We're unlikely to get the same behavior on the real robot as we do in the discrete simulation, which is the only one worth a damn at present. Missing a full control cycle is not good. b. MBP is holding onto the actuation result for longer than a delta-t, which cannot impact the stability in a positive manner! c. Debugging this problem was very, very hard- we thought that we had cached something wrong in our system; our code is always more suspect than Drake code. An excellent developer and myself spent a day's work tracking this down. if I hadn't had @amcastro-tri's help pointing me in the right direction, it would have taken longer. Certainly the behavior that we our seeing violates Sherm's Principle of Least Astonishment.

I suggest bumping the priority on this one to "high".

amcastro-tri commented 3 years ago

FTR, as we discussed with @edrumwri and even with @sherm1 back in the day, this seems like a missing systems:: framework abstraction to model discrete inputs, as outlined in the issue's description. Therefore I also added the label "component: system framework".

sherm1 commented 3 years ago

@edrumwri the "missing periodic event at 0.34" problem you described above is reminding me of the missing periodic event bug we just fixed in PR #14663 that you reviewed (merged Wednesday). Is it possible that this is separate from the discrete input ports issue? Do you see that same behavior with the latest Drake from master?

edrumwri commented 3 years ago

I see how you could come to that conclusion based on what I wrote above. However, MBP is updating at 0.034 just using stale input information at 0.0333333.

amcastro-tri commented 3 years ago

I agree, I don't think #14663 would fix @edrumwri's observation. The input port will still be evaluated at 0.0333333 (though I haven't run it myself to double check)

sherm1 commented 3 years ago

Update: Evan and I discussed this. It's not obvious what's causing the problem here. He is going to attempt a repro that we can investigate.