bsb808 / geonav_transform Goto Github PK

Hello, we started to experience some issues when we are far from datum point (physically, many Km away.)
There would be any problem, or further unwanted consequences if we develop some mechanism to update datum on runtime? Maybe a service that we could call whenever distance between current position and Datum riches some threshold? Or check for Datum changes during the main while()

Hello, I was wondering if in this package UTM coordinates are perfectly aligned with ENU. I have read here that they differ due to convergence (true north vs grid north) but since you assume the orientation is true, the published coordinate system could be perfectly aligned to ENU.

Can you confirm this?

source: http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html

Hi,

Do you intend to release it for kinetic?

Thanks!

Hi,
the below subprogram of the alvinxy.py source looks incorrect compared to the following document: http://www.chrismurf.com/papers/auv10-navigation.pdf

def mdeglon(lat):
    '''
    Provides meters-per-degree longitude at a given latitude
    Args:
      lat (float): latitude in decimal degrees
    Returns:
      float: meters per degree longitude
    '''
    latrad = lat*2.0*pi/360.0 
    dx = 111415.13 * cos(latrad) \
         - 94.55 * cos(3.0*latrad) \
	+ 0.12 * cos(5.0*latrad)
    return dx

The correct line would be (see the operator before 0.12)

 dx = 111415.13 * cos(latrad) \
       - 94.55 * cos(3.0*latrad) \
       - 0.12 * cos(5.0*latrad) 

It might be that using XmlRpc causes a loss of precision of the datum (8 digits quantised to 6 in my case), which was causing me issues. Looking into it, I wasn't able to quickly identify the cause (I got as far as looking into XmlRpc::XmlRpcValue::ValueArray), and so just overloaded nh_priv.getParam in geonav_transform.cpp with a vector<double>, which took about 2 minutes. I'm not sure if the loss of precision is a bug or an oversight but updating the source to overload getparam with a vector may be a good idea. This feature has been supported since groovy.

Can all transforms to nav frame be converted to base frame without impacting the overall functionality? For eg- can transform_odom2nav_ be replaced with transform_odom2base_ in the code?