Expose states_deriv and fix symplectic integration

[ratheron]

I believe the derivatives were supposed to be exposed, but we forgot this, since integration does everything we want. Exposed them in this PR. While at it, fixed symplectic integration.

Here are some benchmarks

[amacati]

Taking our discussion here: I think adding acc, ang_acc and rotor_acc to the state would not be the worst idea. We could even keep the derivative data class, apply the delta, but update with the correct accelerations.

[ratheron]

I think with this, we are mixing things and making it confusing. I see the following options

1. Keep as is, but add note to docs that the deriv is always zero. This is unintuitive imo.
2. Write the correct derivatives into the data. Then we lose about 4%, as shown above.
3. Drop SimStateDeriv from SimData and adapt to sim_dynamics(data: SimData) -> SimStateDeriv, so we can use it directly. This would break the pipeline convention of "always data in, data out", but the dynamics are never meant to be put into the pipeline directly anyway.
4. Drop SimStateDeriv from SimData and add acc, ang_acc, and rotor_acc to SimState. In this case, all base states would be the states, but derivatived would be derivatives. In other words dvel != acc. I think this is weird and not consistent.

I think the cleanest implementation is 3. because nobody expects they can put dynamics directly into the step pipeline without integration. Then, we should add a simple example on how to compute the derivatives via finite differences or directly from the dynamics

[amacati]

1 is not an option IMO. I like 3 more than 2, and think this should be the temporary solution. But it should be combined with 4, so that we have access to the accelerations without finite differences.

[ratheron]

I still dont like that 4 is inconsistent. However, we could use the dynamics to compute the exact derivative and store it in the data (plugins). Showing this in an example is enough imo. Let me implement this real quick

[amacati]

How is 4 inconsistent? It is the current snapshot of the full state. We would not use e.g. the average of RK4 in acc, but the last acc estimate. This seems well defined for me.

[ratheron]

So you want to call the dynamics to integrate the state -> new state is exact. Then with the new state call the dynamics again to get the exact derivative at that state? Otherwise, the acc would be from the previous state an in the case of RK4 not even point to the current state.

[amacati]

Ah, that's what you mean. I was thinking that we use the latest acc available, but I see that this is slightly inconsistent. We should not call the dynamics multiple times. So unless we want to save the accelerations and step with the pre-computed ones from the last step, which is a big change I would not want to commit to, we either have to accept slight inconsistencies, or use finite differences. I am not particularly happy with either, but less with finite differences. That makes no sense at all.

[ratheron]

I believe the solution now implemented (3) is the sweet spot. Dropped SimStateDeriv from SimData and added an example on how to get the derivative easily for the exact derivative at the current step and exact finite differences from the last step.

Due to a circular input problem with SimStateDeriv, I had to move the sim wrappers to sim. I think they also fit nicely there, since build_integrate_fn and build_dynamics_fn now both select from functions living in crazyflow.sim. The dynamics module is now cleanly only the physics and the data. I'm just unsure if we should move the individual data objects (e.g. FirstPrinciplesParams) to crazyflow.sim.dynamics as well, since they are only used there.

[amacati]

Looks okay except for the example which I believe you wanted to rework anyways before the merge

[amacati]

Merged, thanks