Closed RussTedrake closed 2 years ago
please do tag us on specific examples. I don't understand the problem statement from this issue.
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
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?)
How can the solution be ManipulationStation<double>(...).ToAutoDiffXd()
if ManipulationStation<AutoDiffXd> system
doesn't work?
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.
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.
At first blush, the signature
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 thatBuildInto(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.