Framework support for fixed-size AutoDiff

[jwnimmer-tri]

Almost all of the Systems Framework code related to AutoDiff deals in AutoDiffXd. We should support a fixed-size derivatives vector as well, so that we can do chunking (#2619). This might be a good time to design solutions to the scalartype-related instantiation questions like #3741 or #6890 as well.

In any case, the first step is to wrap up the transmogrification work, and then add support for one fixed-size derivatives vector type, using some satisfactory "don't repeat yourself" mechanism so that we can change the fixed size after some profiling.

Edit: The WIP branch for this issue will be https://github.com/jwnimmer-tri/drake/tree/autodiffnd-spike.

Fixing this probably means also fixing #6890 first.

[sherm1]

I suspect a one-size-fits-all fixed size won't be enough and that we'll want to instantiate a few smaller fixed sizes below the largest chunk size (in beautiful powers of 2 of course!).

[jwnimmer-tri]

Possibly yes (and I didn't intent to exclude the future possibility of having more than one), though I suspect we can get pretty far with just one.

[RussTedrake]

fwiw - i agree that we get (very) far with just one size. AutodiffXd -> fixed size is the difference between dynamic memory allocation and not… on every single math operation in the stack. having the vector of size 2,4,8, etc is a relatively much smaller performance improvement, I think.

[jwnimmer-tri]

@RussTedrake do you have a first example or two in mind where you'd want me to try applying this fixed-size AutoDiff? Maybe systems::Linearize, or systems::trajectory_optimization::DirectTranscription?

[RussTedrake]

I think linearizing the atlas or valkyrie models would be an excellent starting point.

[jwnimmer-tri]

@RussTedrake By that I think you mean take a RigidBodyPlant<double> under a specific Context<double> (state and inputs), and then do systems::Linearize on it? That sounds like a good goal, but perhaps not the first goal? RigidBodyPlant doesn't support AutoDiff at all.

Assuming my spike starts out with AutoDiffd<N> somewhere in the N = 4..8 range, perhaps the Quadrotor would be a better plant for the first experiment (num_xc = 12, num_u = 4)?

[RussTedrake]

Good point. Yes, I'm happy with Quadrotor to start.

The huge performance gains won't be apparent until you get to bigger systems (like Atlas). There are queries in RigidBodyTree (which does support AutoDiff) that might be good tests. But it might also be good to bring up an equivalent of https://github.com/RobotLocomotion/drake/blob/last_sha_with_original_matlab/drake/examples/PlanarNLink/PlanarNLink.m in MultibodyTree/Plant as a simple way to test scaling on the most important code. cc @amcastro-tri . The nice thing is that the system doesn't need a parser, so could probably be implemented very soon.

[amcastro-tri]

@RussTedrake, I like this example a lot! One of my goals for this week was to push an acrobot example with MBT. Would you like me to prioritize the N-link pendulum for these tests?

@jwnimmer-tri, MBT now only supports scalar conversion to AutoDiffXd. We'd need something similar to what you are working on with systems to provide similar functionality in MBT. Maybe generalizing your SystemScalarConverter or even writing a MBTScalarConverter based on it would be a good idea?

[RussTedrake]

The N-link pendulum would be great. I hope it's (almost) no harder than the acrobot, and it would indeed enable this sort of test.

[jwnimmer-tri]

FYI I've parked my work for this (last touched a long time ago) at https://github.com/jwnimmer-tri/drake/tree/autodiffnd-spike-take2. Over to @sherm1 for dynamics team prioritization.

[sherm1]

Closing this in favor of #10991 with a back reference to the discussion here.