Add RequirementsMonitorSystem

[jwnimmer-tri]

Add RequirementsMonitorSystem.

(@soonho-tri please edit the overview here to explain what you want.)

[soonho-tri]

@RussTedrake, I'll start implementing it based on framework/primitives/requirements_monitor.h file in your requirements branch. Here is a plan:

• [ ] As a first step, assume that every requirement is in the form of G φ and use the existing symbolic::Formula to represent φ.
• [ ] Implement RequirementMonitor class, test it with interesting scenarios.
• [ ] Extend the specification language to MTL/STL and support it in RequirementMonitor . There is a separate issue for MTL/STL, https://github.com/RobotLocomotion/drake/issues/4999.

[jadecastro]

As discussed with @soonho-tri, I could help work on bullet 2 to implement it as a Drake System.

Fundamentally, once we have G \phi covered, our next step might be to extend this to safety MTL subformulas of the form G_[a_i,b_i] \phi are satisfied or not. We could do this by implementing a system that creates a continuous resettable timer for each subformula of this form. Specifically, the ith timer would be set at a_i and reset at b_i. This should additionally offer enough flexibility to monitor "request-grant" patterns such as G (\phi -> F_[a,b] G_[c,d] \psi).

In later iterations, it would of course be good to have utilities in the RequirementsMonitor system that output a robustness measure computing how far the system is from violating the specification.

[jadecastro]

To document the f2f discussion with @soonho-tri and @RussTedrake (let me know if this differs from your viewpoint), the initial (Spiral-0) work will be detecting any type of constraint violation supported by MathematicalProgram during a simulation. When such a violation occurs, we will need a mechanism to stop the terminate the simulation early, for instance, by setting an AbstractValue flag that the simulator subsumes. The monitor would explain which constraint was violated and report the time the event happened.

[jwnimmer-tri]

See #3346 for discussion on stopping a simulation. If the Monitor system has state (into output) that represents "When did this fail", guarded by the events system, then we don't need to teach the Simulator about anything else. You just clock it with Step calls in your main loop, and your main loop can ask the Monitor if anything tripped yet.

[jadecastro]

Good call. I think what you mean by a "when did this fail" state is some function over state that's locally smooth about zero and can be subsumed by the event handler (which we now support)? If so, I'm onboard.

[jwnimmer-tri]

Yes I agree and that's true, but not precisely what I meant.

To me it sounded like people thought we needed to stop the simulation exactly when the failure happened, so that we know what time we failed. My point is that if simulated time overshoots the failure by 100ms we don't care, because we've noted the exact time at which it failed.

[jadecastro]

If I'm understanding correctly, you're making a distinction between "major time steps" where the events happen, like terminating the sim, and "minor steps" where we can log the "constraint-satisfaction" output of the Monitor. So your point is, we can take advantage of the granularity of these minor steps, to hone in on when the "constraint-satisfaction" output actually said there had been a violation, regardless of when the sim-termination event (decided over a coarse time step in our main loop) had triggered.

This is a good point and I think this makes for fairly simple initial implementation then.

[RussTedrake]

my two cents -- I hope #3346 is only a short-term solution. per the description in that issue, i believe sherm is onboard with event-handling in the simulator allowing an abort.

one hope is that everyone eventually writes requirements for nearly every use of the simulator (so that examples have test value). so #3346 would effectively void the StepTo( > dt) interface and have everyone writing their own simulation loop!

but i also think that the requirementsmonitor could simply trigger an internal state change and allow the simulation to keep running, for the short term. terminating the simulation on violation is a (very important) efficiency improvement, but not strictly necessary for rev 0.1.

[sherm1]

i believe sherm is onboard with event-handling in the simulator allowing an abort

Yes, see #4447.

[soonho-tri]

Thanks to @jadecastro, I found https://reviewable.io/reviews/robotlocomotion/drake/5028 which includes the following function into the System class:

Eigen::VectorXd EvalConstraintEquations(const Context<T>& context) const

@edrumwri and @sherm1, do you plan to handle a disjunction of constraints in the future (or even further a boolean combination of them)?

[edrumwri]

Disjunction meaning one subset of the constraints? Specifically speaking, these are algebraic constraints (meaning that they are free of derivatives) coupled to a system of ordinary differential equations, just to make sure that we're speaking the same language.

---

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

On Tue, Feb 14, 2017 at 5:18 PM, Soonho Kong notifications@github.com wrote:

Thanks to @jadecastro https://github.com/jadecastro, I found https://reviewable.io/reviews/robotlocomotion/drake/5028 which includes the following function into the System class:

Eigen::VectorXd EvalConstraintEquations(const Context& context) const

@edrumwri https://github.com/edrumwri and @sherm1 https://github.com/sherm1, do you plan to handle a disjunction of constraints in the future (or even further a boolean combination of them)?

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

[soonho-tri]

Disjunction meaning one subset of the constraints?

This is correct. To be clearer, I meant logical OR (||). An example is x >= 5 || x <= 0. I realize that DAE(Differential Algebraic Equations) doesn't have disjunctions in its formulation, and N constraints are considered as a conjunction implicitly.

I wanted to point out that there is a similarity between this issue (adding RequirementMonitor) and #5028 (introducing DAE) in that both of them need to introduce a set of constraints into a system and to provide a way to evaluate those constraints. I am wondering if we can have a uniform way of achieving these goals.

[RussTedrake]

Love the discussion! :) It will be great to use the same tools. cc @david-german-tri , @sherm1 , @hongkai-dai

In the matlab system hierarchy, every system had the ability to list state constraints. I've copied the documentation for that concept (from http://underactuated.csail.mit.edu/underactuated.html?chapter=26) here: "State constraints are additional information that you are providing to the solver and analysis routines. They should be read as "this dynamical system will only ever visit states described by ϕ(x)=0". Evaluating the dynamics at a vector x for which ϕ(x)≠0 may lead to an undefined or non-sensible output. Telling Drake about this constraint will allow it to select initial conditions which satisfy the constraint, simulate the system more accurately (with the constraint imposed), and restrict attention during analysis to the manifold defined by the constraints. However, \emph{the state constraints function should not be used to enforce an additional constraint that is not already imposed on the system by the governing equations.}. The state constraint should be simply announcing a property that the system already has, if simulated accurately. Examples might include a passive system with a known total energy, or a four-bar linkage in a rigid body whose dynamics are written as a kinematic tree + constraint forces. State constraints are implemented by overloading the stateConstraints method \emph{and} by calling setNumStateConstraints to tell the solver what to expect in that method."

In that context, I do not believe we will come up against disjunctions in the forseeable future. In matlab, the extra logic was even limited to equality constraints (no inequalities). But even so, i would absolutely want to make sure we are using the same library of constraints for both this and the requirements monitor -- the system constraints would simply only accept a restricted subset.

[jadecastro]

BTW, on the subject of constraints-within-a-System, here is a discussion @amcastro-tri and I had for equality constraints https://github.com/RobotLocomotion/drake/issues/4151.

[RussTedrake]

Good to see that I'm consistent. :)

[sherm1]

Constraints intended for physical simulation have to be enforceable through forces acting on the system. I think that limits them to a subset of the set of all possible constraints that might make sense in a constrained optimization setting.

[jwnimmer-tri]

FYI I've changed the team label here, in preparation for retiring the "team: automotive" label.