Simulate glider dead reckoning

[bsb808]

Need to simulate the glider's internal dead reckoning localization solution.

• First cut would be to use the Hector Gazebo GPS plugin parameters (particularly drift) to simulate the dead reckoning soluiton.
  • Do a test to verify that the solution is "reasonable" and consistent with expectations.

See the uw_glider_itnerface.graphml for context.

[bsb808]

@WHOI Please provide the performance parameters for the glider's dead reckoning solution. Best if you can specify the "XML Parameters" listed as part of the Hector ROS GPS Plugin, particularly the position and velocity drift rates: http://wiki.ros.org/hector_gazebo_plugins#GazeboRosGps

[greg-burgess]

Rather than using a GPS plugin with drift added, we recommend creating a derived DR localization estimate using available information from other existing sensor plugins (namely, pitch from the IMU, heading from the compass, and ascent/descent rate from the pressure sensor). This way, the DR estimate already contains noise from the sensor readings, and no further noise needs to be injected.

For calculation of the Glider Path Angle which is:

abs |glide angle| = abs |pitch|+ AoA

We can assume a constant angle of attack of ~4 degrees.

Equations where Xi is the glide angle, Psi is the heading, z is depth, and t is time

*cite Eichhorn et al. 2020 section 2

In the future, it would be best to calculate angle of attack based on pitch and elevator angle (EPIC DAUG). This relation exists in the literature to a great extent. Can follow-up on this topic in the future. For example:

Angle of attack = pitch - f(pitch)

[woensug-choi]

@greg-burgess I am not much familiar with the dead reckoning sensor and I am confused. Is this a separate sensor? It seems it's something like a module to calculate glider position using data from other sensors. From uw_glider_interface.graphml, I see that a plugin should be designed for this dead reckoning module with NavSatFix msg output.

Should I design the GPS sensor not to publish msg until it's on the surface and let this Dead Reckoning sensor publish estimated GPS value using other sensor data while underwater?

[greg-burgess]

@woensug-choi I apologize for the confusion. There is no "dead-reckoning sensor." The glider's onboard, front-seat computer calculates an estimate of its position using data from other sensors (compass-heading, pressure sensor-rate of change in z, and IMU-pitch).

The simulator should ideally produce three position values.

1. The actual global position of the glider while underwater as well as at the surface (this would normally not be available).
2. A GPS position fix produced only at the surface.
3. A DR estimate of position using various onboard sensors.

For now, I think it's okay to maintain only one NavSatFix msg output. However, it would be helpful to be able to distinguish when the msg is coming from the GPS or from the DR estimated navigation solution. (possibly with a boolean flag for GPS or non-GPS). If that's not possible, maybe it would be better to have two separate messages?

Not sure what the norm is maybe @bsb808 could weigh in here?

[greg-burgess]

After discussing with Rich, we think it would be best to have two separate messages published. One from the GPS, and one from DR.

In post-dive analysis, we can simply override vehicle localization estimate with GPS when available.

[woensug-choi]

This is one last resorting feature that is not yet implemented. It will be worked on after discussions on how to bring this up the interface at https://github.com/Field-Robotics-Lab/glider_hybrid_whoi/issues/34

[bsb808]

Closing b/c seems to be addressed in https://github.com/Field-Robotics-Lab/glider_hybrid_whoi/pull/37