New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constraint methods in System need revision #5297

Open
sherm1 opened this Issue Feb 24, 2017 · 25 comments

Comments

Projects
None yet
5 participants
@sherm1
Member

sherm1 commented Feb 24, 2017

Per discussion with @edrumwri, the constraint methods that slipped into System before I saw them need revision. A few issues:

  • These should be Calc methods, not Eval; Eval is for caching only.
  • Position, velocity, and acceleration errors should be distinguishable. For example, an Assembly analysis or IK needs to drive the position constraints to zero but has no interested in v or a.
  • Documentation is needed to specify what set of equations is being modeled. For example, are position constraint (holonomic) time derivatives included in the velocity errors along with velocity constraints (nonholonomic)?
  • These methods should be templatized by T, they shouldn't be doubles.
  • The velocity change method should be removed or replaced with one that is not specific to mechanical systems and does not require formation of an n^2 matrix; should permit an O(n) implementation.
  • The error norm is mixing units so should involve a scaling matrix but I don't think there is one. I'm not clear why this is a System API method since the constraint errors are already available. Choice of norm is usually made by a solver; could use a utility method that scales?
@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Feb 24, 2017

Contributor

fwiw -- http://drake.mit.edu/doxygen_matlab/class_manipulator.html#ae9a5cd0ce75ce832f0070c87c894d6fe
there are a number of constraint implementations (e.g. constant-length cable drive) in matlab that we can move over when this is ready.

Contributor

RussTedrake commented Feb 24, 2017

fwiw -- http://drake.mit.edu/doxygen_matlab/class_manipulator.html#ae9a5cd0ce75ce832f0070c87c894d6fe
there are a number of constraint implementations (e.g. constant-length cable drive) in matlab that we can move over when this is ready.

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Feb 24, 2017

Contributor

another important distinction is whether constraints are equality constraints or inequality constraints. of course, with our constraint classes you can simply ask the constraint about it's bounds; in matlab we kept separate lists of constraints for the two distinct types because they are treated very differently in the dynamics code.

Contributor

RussTedrake commented Feb 24, 2017

another important distinction is whether constraints are equality constraints or inequality constraints. of course, with our constraint classes you can simply ask the constraint about it's bounds; in matlab we kept separate lists of constraints for the two distinct types because they are treated very differently in the dynamics code.

@edrumwri

This comment has been minimized.

Show comment
Hide comment
@edrumwri

edrumwri Feb 24, 2017

Contributor
Contributor

edrumwri commented Feb 24, 2017

@edrumwri

This comment has been minimized.

Show comment
Hide comment
@edrumwri

edrumwri Feb 24, 2017

Contributor
Contributor

edrumwri commented Feb 24, 2017

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Feb 24, 2017

Contributor

@edrumwri - That's consistent with my understanding. The first consumers of the inequality constraints will be the planning/optimization tools.

Contributor

RussTedrake commented Feb 24, 2017

@edrumwri - That's consistent with my understanding. The first consumers of the inequality constraints will be the planning/optimization tools.

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Feb 25, 2017

Member

if we introduce position, velocity, and acceleration errors, then
we're back at the assumption that a system is mechanical.

Good point. We had the same issue with continuous state variables but phrased them neutrally as second order state variables q, their related first order variables v, and other first order variables z. Is there analogous terminology we can use here for

  • constraints on q, with t given: g₂(t;q)=0
    • holonomic, with time derivatives ġ₂(t,q;v), g̈₂(t,q,v;v̇)
  • constraints on v, with t,q given: g₁(t,q;v)=0
    • nonholonomic, with time derivative ġ₁(t,q,v;v̇)
  • constraints on v̇,λ: g₀(t,q,v;v̇,λ)=0
    • e.g. sliding friction and softened g₂ and g₁ constraints

Also I am unclear whether we should allow constraints on z and if so how they should be specified.

Member

sherm1 commented Feb 25, 2017

if we introduce position, velocity, and acceleration errors, then
we're back at the assumption that a system is mechanical.

Good point. We had the same issue with continuous state variables but phrased them neutrally as second order state variables q, their related first order variables v, and other first order variables z. Is there analogous terminology we can use here for

  • constraints on q, with t given: g₂(t;q)=0
    • holonomic, with time derivatives ġ₂(t,q;v), g̈₂(t,q,v;v̇)
  • constraints on v, with t,q given: g₁(t,q;v)=0
    • nonholonomic, with time derivative ġ₁(t,q,v;v̇)
  • constraints on v̇,λ: g₀(t,q,v;v̇,λ)=0
    • e.g. sliding friction and softened g₂ and g₁ constraints

Also I am unclear whether we should allow constraints on z and if so how they should be specified.

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Feb 25, 2017

Contributor

my two cents:

  • constraints on z should definitely be supported, too. in matlab we had stateConstraints (phi(x)=0) for all Systems, and added additional notions of positionConstraints, velocityConstraints for Manipulators only. Adding a position constraint would also register a stateConstraint. i think the semantics are slightly different here -- since any system can have q,v,z, but this is just to say that many non-manipulators announced constraints on z in systems that we care about.
  • we already have a language for constraints in drake, and should definitely reuse that. The existence (or non-existence) of derivatives should be expressed by the constraint class.
  • the constraint classes also allow constraints to be inequality constraints. we should support that, too! joint limits are a simple version.
Contributor

RussTedrake commented Feb 25, 2017

my two cents:

  • constraints on z should definitely be supported, too. in matlab we had stateConstraints (phi(x)=0) for all Systems, and added additional notions of positionConstraints, velocityConstraints for Manipulators only. Adding a position constraint would also register a stateConstraint. i think the semantics are slightly different here -- since any system can have q,v,z, but this is just to say that many non-manipulators announced constraints on z in systems that we care about.
  • we already have a language for constraints in drake, and should definitely reuse that. The existence (or non-existence) of derivatives should be expressed by the constraint class.
  • the constraint classes also allow constraints to be inequality constraints. we should support that, too! joint limits are a simple version.
@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Feb 25, 2017

Contributor

in my mind, this is such an important thing to get right (to fulfill the promise of having a truly beautiful architecture for optimization over dynamical systems), that we should probably schedule a design meeting about it. cc @hongkai-dai @soonho-tri

Contributor

RussTedrake commented Feb 25, 2017

in my mind, this is such an important thing to get right (to fulfill the promise of having a truly beautiful architecture for optimization over dynamical systems), that we should probably schedule a design meeting about it. cc @hongkai-dai @soonho-tri

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Feb 25, 2017

Member

Good idea! @edrumwri and I may be out of action Monday due to HQ chaos on move-in day but should be functional again by Tuesday (I hope). We could also devote the Wed 10:30PT/1:30ET dynamics team meeting to this topic.

Member

sherm1 commented Feb 25, 2017

Good idea! @edrumwri and I may be out of action Monday due to HQ chaos on move-in day but should be functional again by Tuesday (I hope). We could also devote the Wed 10:30PT/1:30ET dynamics team meeting to this topic.

@soonho-tri

This comment has been minimized.

Show comment
Hide comment
@soonho-tri

soonho-tri Feb 25, 2017

Member

I'll read the discussions carefully.
/cc @jadecastro who is working on the design of RequirementMonitor with me.

Good idea! @edrumwri and I may be out of action Monday due to HQ chaos on move-in day but should be functional again by Tuesday (I hope). We could also devote the Wed 10:30PT/1:30ET dynamics team meeting to this topic.

Tuesday is better for me and @jadecastro. On Wednesday, we have MIT project meetings (Ken and Larry visit us).

Member

soonho-tri commented Feb 25, 2017

I'll read the discussions carefully.
/cc @jadecastro who is working on the design of RequirementMonitor with me.

Good idea! @edrumwri and I may be out of action Monday due to HQ chaos on move-in day but should be functional again by Tuesday (I hope). We could also devote the Wed 10:30PT/1:30ET dynamics team meeting to this topic.

Tuesday is better for me and @jadecastro. On Wednesday, we have MIT project meetings (Ken and Larry visit us).

@hongkai-dai

This comment has been minimized.

Show comment
Hide comment
@hongkai-dai

hongkai-dai Feb 25, 2017

Contributor

I should be available on both Tuesday and Wednesday.

Contributor

hongkai-dai commented Feb 25, 2017

I should be available on both Tuesday and Wednesday.

@soonho-tri

This comment has been minimized.

Show comment
Hide comment
@soonho-tri

soonho-tri Mar 15, 2017

Member

Can anyone summarize the action items (if any) that we agreed on in the last meeting?

Member

soonho-tri commented Mar 15, 2017

Can anyone summarize the action items (if any) that we agreed on in the last meeting?

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Mar 15, 2017

Member

Can anyone summarize the action items (if any) that we agreed on in the last meeting?

I agreed to work on the specification of the equations that are represented by our System abstraction. I have a work-in-progress document here but it isn't ready yet. Feel free to add comments if you think of something.

The issue of how to handle input bounds constraints still remains. Russ & I discussed this morning. In the doc I'm assuming those would be a property of the input ports so that they would be easily visible. But that requires a flavor of CalcTimeDerivatives() (for example) that operates on the unbounded input values, so that an input-bounded linear system could reveal the linear part. The alternative is to depend on a System Diagram that has a subsystem that bounds its outputs that are fed into a linear subsystem. The difficulty there is attempting to discern that structure, while it would be obvious if the subsystem inputs declared it.

Member

sherm1 commented Mar 15, 2017

Can anyone summarize the action items (if any) that we agreed on in the last meeting?

I agreed to work on the specification of the equations that are represented by our System abstraction. I have a work-in-progress document here but it isn't ready yet. Feel free to add comments if you think of something.

The issue of how to handle input bounds constraints still remains. Russ & I discussed this morning. In the doc I'm assuming those would be a property of the input ports so that they would be easily visible. But that requires a flavor of CalcTimeDerivatives() (for example) that operates on the unbounded input values, so that an input-bounded linear system could reveal the linear part. The alternative is to depend on a System Diagram that has a subsystem that bounds its outputs that are fed into a linear subsystem. The difficulty there is attempting to discern that structure, while it would be obvious if the subsystem inputs declared it.

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Apr 30, 2017

Contributor

Besides the document @sherm1 referenced, #4998 and #4151 are also relevant. I'm going to collect my thoughts in that document for now. And the constraint methods that slipped into the system framework (that started this discussion) are here:

/// @name Constraint-related functions.

Contributor

RussTedrake commented Apr 30, 2017

Besides the document @sherm1 referenced, #4998 and #4151 are also relevant. I'm going to collect my thoughts in that document for now. And the constraint methods that slipped into the system framework (that started this discussion) are here:

/// @name Constraint-related functions.

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Jun 24, 2017

Contributor

After some random conversations last week, and some upcoming use cases that we’d like to support, I propose that we move forward with the following initial API (which mirrors the new output port API) to System:

template <class MySystem, typename BasicVectorSubtype>
  const OutputPort<T>& DeclareConstraint(
      void (MySystem::*calc)(const Context<T>&, BasicVectorSubtype*) const,
      VectorXd lower_bound, VectorXd upper_bound) 

This does not satisfy all of the constraint types that @sherm1 articulated in the doc above, but it enables many immediately (input constraints, state constraints, parameter constraints). I think that the block diagram logic will do a lot of the right work for us (for instance, if I use SymbolicExpression to ask a block diagram if it has any input port constraints, it will answer correctly).

This should not be hard to do… and we can convert @edrumwri’s previous constraint implementations over to it. Thoughts?

Contributor

RussTedrake commented Jun 24, 2017

After some random conversations last week, and some upcoming use cases that we’d like to support, I propose that we move forward with the following initial API (which mirrors the new output port API) to System:

template <class MySystem, typename BasicVectorSubtype>
  const OutputPort<T>& DeclareConstraint(
      void (MySystem::*calc)(const Context<T>&, BasicVectorSubtype*) const,
      VectorXd lower_bound, VectorXd upper_bound) 

This does not satisfy all of the constraint types that @sherm1 articulated in the doc above, but it enables many immediately (input constraints, state constraints, parameter constraints). I think that the block diagram logic will do a lot of the right work for us (for instance, if I use SymbolicExpression to ask a block diagram if it has any input port constraints, it will answer correctly).

This should not be hard to do… and we can convert @edrumwri’s previous constraint implementations over to it. Thoughts?

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Jun 26, 2017

Member

@RussTedrake, in your proposal above are you thinking of that as an easy-to-query declaration, independent of the internal constraint implementation?

Member

sherm1 commented Jun 26, 2017

@RussTedrake, in your proposal above are you thinking of that as an easy-to-query declaration, independent of the internal constraint implementation?

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Jun 26, 2017

Member

A more-specific name like DeclareBoxConstraint() would be better, I think.

Member

sherm1 commented Jun 26, 2017

A more-specific name like DeclareBoxConstraint() would be better, I think.

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Jun 26, 2017

Contributor

My goal was to constrain the function arguments (this captures all constraints that can be written as a function from Context to VectorXd.) The internal implementation can be anything (not just a box constraint). We can rely on symbolic expression to figure out the structure of the constraint.

My thinking is
(a) we want to support general constraints like this eventually.
(b) if we start breaking out box, linear, affine, quadratic, ... constraints, then we have to maintain them separately. that can be a performance improvement after we get the initial version working.

Contributor

RussTedrake commented Jun 26, 2017

My goal was to constrain the function arguments (this captures all constraints that can be written as a function from Context to VectorXd.) The internal implementation can be anything (not just a box constraint). We can rely on symbolic expression to figure out the structure of the constraint.

My thinking is
(a) we want to support general constraints like this eventually.
(b) if we start breaking out box, linear, affine, quadratic, ... constraints, then we have to maintain them separately. that can be a performance improvement after we get the initial version working.

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Jun 27, 2017

Member

(sorry for the slo-mo discussion rate) I don't think I understand what you mean by "constrain the function arguments" -- I don't see any enumerated arguments in the signature to constrain so I thought the bounds were on the BasicVectorSubtype output argument (which is why I thought it was a box). To what are the bounds applied? Can you clarify with some mathiness?

Member

sherm1 commented Jun 27, 2017

(sorry for the slo-mo discussion rate) I don't think I understand what you mean by "constrain the function arguments" -- I don't see any enumerated arguments in the signature to constrain so I thought the bounds were on the BasicVectorSubtype output argument (which is why I thought it was a box). To what are the bounds applied? Can you clarify with some mathiness?

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Jun 28, 2017

Contributor

My goal was to describe a vector-valued constraint function of the (conceptual) form:

lower_bound <= f(const Context&) <= upper_bound

where f() is an arbitrary function of the context. A bounding box constraint, a linear constraint, etc, would be special forms of this general case.

Contributor

RussTedrake commented Jun 28, 2017

My goal was to describe a vector-valued constraint function of the (conceptual) form:

lower_bound <= f(const Context&) <= upper_bound

where f() is an arbitrary function of the context. A bounding box constraint, a linear constraint, etc, would be special forms of this general case.

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Jun 28, 2017

Member

Oh, got it -- that makes sense. Bounds on the output of f. That's what I thought you meant but then I think I misused the term "box constraint" which I now think means that the bounds must apply directly to the decision variables. Is that right?

Above you said "my goal was to constrain the function arguments". I'm still confused by that statement. Did you mean "constrain the function result" or " constrain the argument which is a function"?

Member

sherm1 commented Jun 28, 2017

Oh, got it -- that makes sense. Bounds on the output of f. That's what I thought you meant but then I think I misused the term "box constraint" which I now think means that the bounds must apply directly to the decision variables. Is that right?

Above you said "my goal was to constrain the function arguments". I'm still confused by that statement. Did you mean "constrain the function result" or " constrain the argument which is a function"?

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Jun 28, 2017

Contributor

I could have chosen my words more carefully. I just meant "let's implement 'f(const Context&)' first", even though it is probably not the best way to write friction cone or other acceleration-level constraints.

Contributor

RussTedrake commented Jun 28, 2017

I could have chosen my words more carefully. I just meant "let's implement 'f(const Context&)' first", even though it is probably not the best way to write friction cone or other acceleration-level constraints.

@sherm1

This comment has been minimized.

Show comment
Hide comment
@sherm1

sherm1 Jun 28, 2017

Member

Thanks. I like the API. Am I correct in thinking of this as a declaration about the System's behavior rather than something that causes that behavior?

Member

sherm1 commented Jun 28, 2017

Thanks. I like the API. Am I correct in thinking of this as a declaration about the System's behavior rather than something that causes that behavior?

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Jun 29, 2017

Contributor

Good. Yes, i think that it means "the system methods are only well-defined if this constraint is satisfied". For instance, one should not pass in a non-unit quaternion, nor some other parameter out of range. It also means, "you can safely analyze/optimize this system by only considering context values satisfying this constraint".

Contributor

RussTedrake commented Jun 29, 2017

Good. Yes, i think that it means "the system methods are only well-defined if this constraint is satisfied". For instance, one should not pass in a non-unit quaternion, nor some other parameter out of range. It also means, "you can safely analyze/optimize this system by only considering context values satisfying this constraint".

@RussTedrake

This comment has been minimized.

Show comment
Hide comment
@RussTedrake

RussTedrake Aug 26, 2017

Contributor

I’m chipping away at my proposed implementation. Would be very interested in feedback if anybody is willing to take a quick look. Some things will get better with additional syntactic sugar, but I’d like to get the basic organization right.

https://github.com/RobotLocomotion/drake/compare/master...RussTedrake:system_constraints?expand=1

cc @sherm1, @jwnimmer-tri, @hongkai-dai, @soonho-tri

Contributor

RussTedrake commented Aug 26, 2017

I’m chipping away at my proposed implementation. Would be very interested in feedback if anybody is willing to take a quick look. Some things will get better with additional syntactic sugar, but I’d like to get the basic organization right.

https://github.com/RobotLocomotion/drake/compare/master...RussTedrake:system_constraints?expand=1

cc @sherm1, @jwnimmer-tri, @hongkai-dai, @soonho-tri

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment