Closed bsb808 closed 3 years ago
@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
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)
@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?
@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.
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?
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.
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
Closing b/c seems to be addressed in https://github.com/Field-Robotics-Lab/glider_hybrid_whoi/pull/37
Need to simulate the glider's internal dead reckoning localization solution.
See the uw_glider_itnerface.graphml for context.