edrumwri
commented
7 years ago I really like this idea, as long as we don't call it "templates and anchors" :)
Some questions:
Would the hierarchy be a chain or a tree?
What would moving along the hierarchy imply? Greater accuracy and computation time? Or would this just be nebulously "greater complexity"?
Would moving along the hierarchy imply that a model with greater complexity automatically subsumes the model below it (in other words, it's the same model "plus" some additional details)?
How would you imagine that one would programmatically access the models in the hierarchy? Could you just dial a knob for greater complexity? Or does the user have to be aware of each node in the hierarchy, calling it out by name?
Evan Drumwright Senior Research Scientist http://positronicslab.github.io Toyota Research Institute Palo Alto, CA
On Sun, Aug 27, 2017 at 5:29 PM, Russ Tedrake notifications@github.com wrote:
Just to seed the discussion and let it simmer, I’d like to formalize the notion that we can have different levels of detail for systems. Words like “model reduction”, etc are also relevant here. For two models to be related to each other in this way, they should have the same input and output ports.
As an example, consider a simple pendulum. At the top of the abstraction might be the basic nonlinear model (e.g. q̈ = -sin(q) - q̇). A more detailed model could have e.g., actuator saturation, actuator stiction, sampled-data i/o, and an encoder with finite ticks and non-zero calibration offset. Perhaps the real hardware could be yet another model in the hierarchy.
Formalizing the relationship between these models should make it easy to:
- do control design / estimation / analysis on the simple model and apply it to the more detailed model
- do runtime model checking. (e.g. “is my approximate model within some tolerance of the detailed model”)
- use model-order reduction techniques to automatically add more models to this hierarchy (or at least system id to fit model parameters across the hierarchy).
Perhaps there are more, still. Like writing requirements against the simple model state, but enforcing them on the detailed model. Again, just starting the discussion.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/RobotLocomotion/drake/issues/6927, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHwz8N_Hnv89fAJJGsGZ11MaOymyk_7ks5scgnagaJpZM4PD-B7 .
RussTedrake
Just to seed the discussion and let it simmer, I’d like to formalize the notion that we can have different levels of detail for systems. Words like “model reduction”, etc are also relevant here. For two models to be related to each other in this way, they should have the same input and output ports.
As an example, consider a simple pendulum. At the top of the abstraction might be the basic nonlinear model (e.g. q̈ = -sin(q) - q̇). A more detailed model could have e.g., actuator saturation, actuator stiction, sampled-data i/o, and an encoder with finite ticks and non-zero calibration offset. Perhaps the real hardware could be yet another model in the hierarchy.
Formalizing the relationship between these models should make it easy to:
Perhaps there are more, still. Like writing requirements against the simple model state, but enforcing them on the detailed model. Again, just starting the discussion.