Solution for VC head movement bug

[ggalfi]

This bug: https://github.com/orbiternassp/NASSP/issues/767 was caused because GetForceVector does not take into account all the forces when the vessel is docked. A new class InertialData is created to correctly calculate inertial acceleration. The head movement in VC is now based on this instead of GetForceVector function. This - or a very similar - calculation is done many times for multiple instruments (IMU, EMS, mechanical G-meter on CSM, LV IMU, LM IMU, LM T/W, LM AGS Accelerometer). It would be more effective to make all these to query the InertialData object of the vessel for inertial acceleration instead of doing the calculation on their own.

[indy91]

I'll give this a good test. Looks good though! Something like this was also my idea, but when I started looking into it I was a bit discouraged by how different the accelerometer implementations of LV IMU, EMS, G-Meter etc. are. I had hoped to implement something that generated the data that all accelerometers could access. But that can hopefully still be done with this, just will need some changes in those accelerometer classes.

[ggalfi]

I had hoped to implement something that generated the data that all accelerometers could access. But that can hopefully still be done with this, just will need some changes in those accelerometer classes.

My observation was when I peeked into the code of these instruments was that a lot of unnecessary calculation is happening (on top of the repeated calculation of acceleration): for example in case of EMS to get the the vessel->global transformation and it's inverse, there is a lot of messing with Euler angles and also trigonometric functions - but we don't need them at all. First of all, the actual attitude of a vessel is kept as a rotational matrix within Orbiter (I've looked it up in Orbiter's source code), so I'd rather query it directly by GetRotationMatrix method than to ask OrbiterSDK to convert it into angles through GetGlobalOrientation. Also to get the inverse of this transformation, there is no need to mess with angles, as it is a rotational matrix it's inverse is simply it's transpose. And despite it is fairly easy, still you don't need to calculate the transpose itself, just use the tmul function instead of mul to multiply with the inverse of the matrix. If you don't mind I'd keenly do the integration of all the relevant instruments with IntertialData class, and I'd also do some refactoring of the linear algebra stuff there.

[indy91]

Yeah this new inertial data class seems like a good place to do a bit of experimentation like that. Go for it!

One thing to keep in mind. When we originally switched to Orbiter 2016 we suddenly had a small oscillation in the acceleration. I believe this was caused by using the wrong Orbiter timestep length in clbkPostStep because the way clbkPostStep works changed in Orbiter 2016. It probably doesn't occur in your class (I haven't checked yet), but just something to be careful about. Our EMS didn't like it and triggered 0.05g too early for example.