sketch for AutonomousHybridSystem

[RussTedrake]

In last_sha_with_original_matlab, we had HybridDrakeSystem that was a workhorse for models like the ones we get reasoning about walking robots in their minimal-state hybrid systems. We can certainly implement this type of system in the new drake, but that class played two important roles that are so far missing: 1) it made it easier to construct simple hybrid systems correctly, and 2) it provided an interface to write algorithms against those systems, with a common api for modes/guards/resets, etc.

As I've been writing more of these systems in the new System API, I have been thinking about how this might look today:

• proposed name/location: systems::primitives::AutonomousHybridSystem (autonomous ==> that the hybrid nature is due to internal guards/resets, as opposed to mode switches that come from external input... like changing gears in a powertrain)
• probably not a collection of Systems. The matlab version did this, where addMode() was roughly equivalent to our DiagramBuilder::AddSystem(). But our systems are more complex now, and I don't think we want to be in the business of writing another Diagram.
• instead, AutonomousHybridSystem would simply add an abstract integer state for the mode, and could offer a default DoGetWitnessFunctions based on a series of calls to AddTransition. The state of the different modes would all be mushed together in the single Context. (this was missing before, but often modes share some of the state).
• additionally, it would offer documentation recommending the basic pattern for writing e.g. DoCalcTimeDerivatives with a switch(context.mode); making sure to always set the remaining derivatives to zero.
• ideally it would also offer a "mask" declaring which subsets of the Context were relevant in each mode (e.g. the other states can be safely ignored). Not sure how to do that yet (it was easy in the subsystem version, but inefficient in carrying around potentially redundant sub-contexts.)
• Similarly, we want an API for getting the subset of relevant SystemConstraints per mode.

cc @sherm1 @edrumwri @hongkai-dai

[edrumwri]

Looks pretty good. One thought:

For multi-point rigid contact, it can be easier to write the logic for transitioning than to build the transition diagram as you're describing above. For example, I can say that "if there is an impact at any point then call the impact resolution method". Also, I'm not sure how you would build the transition diagram (since the system is presumably const) if the number of contacts is not bounded, though this would seem to be resolvable.

---

Evan Drumwright Senior Research Scientist http://positronicslab.github.io Toyota Research Institute Palo Alto, CA

On Mon, Apr 8, 2019 at 3:48 AM Russ Tedrake notifications@github.com wrote:

In last_sha_with_original_matlab, we had HybridDrakeSystem https://github.com/RobotLocomotion/drake/blob/last_sha_with_original_matlab/drake/matlab/systems/%40HybridDrakeSystem/HybridDrakeSystem.m that was a workhorse for models like the ones we get reasoning about walking robots in their minimal-state hybrid systems. We can certainly implement this type of system in the new drake, but that class played two important roles that are so far missing:

1. it made it easier to construct simple hybrid systems correctly, and
2. it provided an interface to write algorithms against those systems, with a common api for modes/guards/resets, etc.

As I've been writing more of these systems in the new System API, I have been thinking about how this might look today:

• proposed name/location: systems::primitives::AutonomousHybridSystem (autonomous ==> that the hybrid nature is due to internal guards/resets, as opposed to mode switches that come from external input... like changing gears in a powertrain)
• probably not a collection of Systems. The matlab version did this, where addMode() was roughly equivalent to our DiagramBuilder::AddSystem(). But our systems are more complex now, and I don't think we want to be in the business of writing another Diagram.
• instead, AutonomousHybridSystem would simply add an abstract integer state for the mode, and could offer a default DoGetWitnessFunctions based on a series of calls to AddTransition. The state of the different modes would all be mushed together in the single Context. (this was missing before, but often modes share some of the state).
• additionally, it would offer documentation recommending the basic pattern for writing e.g. DoCalcTimeDerivatives with a switch(context.mode); making sure to always set the remaining derivatives to zero.

cc @sherm1 https://github.com/sherm1 @edrumwri https://github.com/edrumwri @hongkai-dai https://github.com/hongkai-dai

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobotLocomotion/drake/issues/11188, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHwz_ducp4M0187m1Ewr8hwNzDPsY34ks5vex59gaJpZM4ch3y1 .

--

Confidential or protected information may be contained in this email and/or attachment. Unless otherwise marked, all TRI email communications are considered "PROTECTED" and should not be shared or distributed. Thank you.

[sherm1]

I like this idea. Per f2f yesterday regarding composition of hybrid systems to make a hybrid diagram, it occurs to me that we wouldn't have to generalize Diagram for that -- we could derive HybridDiagram from Diagram, and have a HybridDiagramBuilder that could assemble AutonomousHybridSystems and other Systems into a Diagram that also supports the proposed hybrid model and API.

[RussTedrake]

@sherm1 -- that's brilliant. I actually might be able to implement everything I want by deriving from Diagram. It could then have the subsystem Context's clean and separate, and simply override that the derivatives are zero for inactive modes. And could provide just a little API for e.g. GetSubsystem(mode), GetSubsystemContext(mode), ...