RobotLocomotion / drake

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

autodiff support for multibody parsers #9573

Closed RussTedrake closed 2 years ago

RussTedrake commented 6 years ago

At first blush, the signature

ModelInstanceIndex AddModelFromSdfFile(
    const std::string& file_name,
    const std::string& model_name_in,
    multibody_plant::MultibodyPlant<double>* plant,
    geometry::SceneGraph<double>* scene_graph) 

seems reasonable -- because we can always parse into a double system and then convert. But it turns out this complicates the construction of Diagram derived classes that BuildInto(this)... which try to support autodiff.

I suspect it might not be too painful to support autodiff in the parsing; would like to consider it before I start implementing work-arounds on the diagram class. Will tag this in my forth-coming PR for a specific example.

amcastro-tri commented 6 years ago

please do tag us on specific examples. I don't understand the problem statement from this issue.

RussTedrake commented 6 years ago

I cannot instantiate the manipulation_station example on autodiff. it fails (first) at this line: https://github.com/RobotLocomotion/drake/blob/master/examples/manipulation_station/station_simulation.cc#L110

EricCousineau-TRI commented 4 years ago

Er, can I suggest we close this issue, and that the workflow is just ManipulationStation<double>(...).ToAutoDiffXd()?

Supporting AutoDiffXd parsing sounds like a bit of infrastructure churn, overhead for compile times, all in the name of information loss? (e.g. we won't be putting gradients in SDFormat files?)

RussTedrake commented 4 years ago

How can the solution be ManipulationStation<double>(...).ToAutoDiffXd() if ManipulationStation<AutoDiffXd> system doesn't work?

jwnimmer-tri commented 4 years ago

I don't know if its a good idea or not, but I think the nature of Eric's proposal is that the AD owned_plant_ is scalar-converted from the double owned_plant_ in the scalar-converting copy constructor -- that the scalar conversion constructor member-wise converts all of its data fields, instead of invoking the same constructor that the user invokes (which parses). Or to parse into a double owned-plant even in the AD constructor, and then immediate scalar-convert the intermediate result.

jwnimmer-tri commented 2 years ago

I believe the solution here would go as follows:

Change owned_plant_ and owned_scene_graph_ to be double-only (not T), for use during setup. Then during ManipulationStation::Finalize(), scalar-convert them to AutoDiffXd (if T=AutoDiffXd) while building-into the Diagram.

In cases where such approaches are not tenable, I believe instead we should focus on something like #15026 to copy a parsed model instance into a new plant, rather than trying to teach our parsers about multiple different scalar types.