F9P settings

[minglok943]

First, thanks for the brilliant packages.

My zed-f9p firmware version is 1.32 and I don't want to change the firmware version.

I am using three ardusimple rtk2b board, one at base station, two on robot.

(1) Settings for receivers that output aircraft that output NMEA (positioning results RTK'd by the F9P internal engine)
eagleye_f9p_nmea_conf.txt
https://www.dropbox.com/s/3viqyqutipn5dpj/eagleye_f9p_nmea_conf.txt?dl=0
(2) Settings for receivers that measure RAW data through RTKLIB and output Doppler velocity.
eagleye_f9p_raw_conf.txt
https://www.dropbox.com/s/acz98v30rtgbmsx/eagleye_f9p_raw_conf.txt?dl=0

Regarding above, can I understand that the first zed-f9p on robot should output NMEA only like image below

while the second zed-f9p on robot should output Raw message only like the image below only?

Or other settings need to be configured?

[rsasaki0109]

These settings should be fine. Through the ROS node, you should check the /nmea_sentence or /fix topic from (1), and the /rtklib_nav topic from (2) as they will be outputted accordingly.

[minglok943]

From (1), when I run roslaunch f9p_nmea_sentence.launch, warning [ WARN] [1711257286.189094931]: Null byte received from serial port, flushing buffer was shown.

however, the topic /f9p/nmea_sentence was still publishing

Is this normal?

Also, our final goal is to get robot's heading in dual antenna mode,

if run eagleeye_rt.launch in multi_antenna_mode, we need to set the config.yaml accordingly,

gnss:
  velocity_source_type: 0 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
  velocity_source_topic:  /rtklib_nav
  llh_source_type: 1 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /main/mosaic/nmea_sentence
sub_gnss:
  llh_source_type: 1 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /sub/mosaic/nmea_sentence

KumarRobotics/ublox
this package publishes
~fix(sensor_msgs/NavSatFix)

Navigation Satellite fix.

~fix_velocity(geometry_msgs/TwistWithCovarianceStamped)

Velocity in local ENU frame.

for gnss and subgnss, can I use that as source?

[rsasaki0109]

Is this normal?

If the topic is being published, then there's no problem.

can I use that as source?

The fix is fine, but since the fix_velocity is in the ENU system, it needs to be converted to the ECEF system.

[minglok943]

I connected 2 simplertk2b to a laptop,
First SimpleRtk2B(gnss)

For /dev/ttyACM0, I got the /rtklib/nav by the rtkrcv and rtklib bridge,
For /dev/ttyUSB0, I got the /f9p/nmea_sentence by nmea_comms

Second SimpleRtk2B(subgnss), /dev/ttyACM1
I want to get the nmea sentence with the same way but I got
[ERROR] [1711332945.879142881]: Unable to bind socket. Is port 29500 in use? Retrying every 1s.

How to run two instances of nmea_comms ?

Therefore, I tried also using the ublox package to get the llh for subgnss.
Recorded rosbag file

And I set the config as below

gnss:
  velocity_source_type: 0 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
  velocity_source_topic:  /rtklib_nav
  llh_source_type: 1 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /f9p/nmea_sentence
sub_gnss:
  llh_source_type: 2 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /ublox2/fix

then I run roslaunch eagleye_gnss_converter gnss_converter.launch use_multi_antenna_mode:=true, but I got the error and the /sub_navsat/gga is not publishing also, how can I troubleshoot this?

terminate called after throwing an instance of 'std::invalid_argument'
  what():  stod
[navsat/gnss_converter_node-1] process has died [pid 67476, exit code -6, cmd /home/a2tech/catkin_ws/devel/lib/eagleye_gnss_converter/gnss_converter_node __name:=gnss_converter_node __log:=/home/a2tech/.ros/log/45692a18-ea5c-11ee-bed6-fb2b8dd8ccff/navsat-gnss_converter_node-1.log].
log file: /home/a2tech/.ros/log/45692a18-ea5c-11ee-bed6-fb2b8dd8ccff/navsat-gnss_converter_node-1*.log

[rsasaki0109]

Please specify using what is displayed by the 'ls /dev/serial/by-id/*' command, instead of /dev/ttyACMX.

I got the error and the /sub_navsat/gga is not publishing also, how can I troubleshoot this?

I will check on this later.

[rsasaki0109]

Does the gnss_converter die on startup, or does it die when subscribing to a topic?

Can you launch gnss_converter.xml without any issues within eagleye_rt.launch.xml?
https://github.com/MapIV/eagleye/blob/autoware-main/eagleye_rt/launch/eagleye_rt.launch.xml#L135

[minglok943]

  // Callback functions
void nmea_callback(const nmea_msgs::Sentence::ConstPtr &msg)
{
  nmea_msgs::Gpgga gga;
  nmea_msgs::Gprmc rmc;
  sensor_msgs::NavSatFix fix;

  sentence.header = msg->header;
  sentence.sentence = msg->sentence;
  nmea2fix_converter(sentence, &fix, &gga, &rmc);
  if (fix.header.stamp.toSec() != 0)
  {
    gga.header.frame_id = fix.header.frame_id = "gnss";
    pub1.publish(fix);
    pub2.publish(gga);
  }
  if (rmc.header.stamp.toSec() != 0)
  {
    rmc.header.frame_id = "gnss";
    pub3.publish(rmc);
  }
}

I found out that the gga message needed by gnss_compass is only published when we use nmea message. I also tried the rosbag provided
GNSS: Ublox F9P with RTK IMU: Tamagawa AU7684 LiDAR: Velodyne VLP-32C

I assumed the rtklib_nav and /f9p/fix in the rosbag are from the first gnss, and the /fix is from the second gnss,
then I run eagleeye_rt.launch in dual antenna mode and I found out that the gnss_compass node is not running but the heading estimation works fine. The gnss_converter node is publishing /eagleye/navsat/rtklib_nav for heading estimation nodes.

So can I conclude that as long as I got the gnss_converter node publishing /eagleeye/navsat/rtklib_nav, I can procede to the next stage?

The package KumarRobotics/ublox I mentioned previously also support publishing of NavPvt message, any modification needed for the message before I forward the message to gnss_converter node?

gnss:
  velocity_source_type: 2 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
  velocity_source_topic:  /ublox1/navpvt
  llh_source_type: 2 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /ublox1/fix
sub_gnss:
  llh_source_type: 2 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /ublox2/fix

[minglok943]

rosbag

# Estimate mode
use_gnss_mode: RTKLIB
use_can_less_mode: false

# Topic
twist:
  twist_type: 0 # TwistStamped : 0, TwistWithCovarianceStamped: 1
  twist_topic: /can_twist
imu_topic: /imu/data
gnss:
  velocity_source_type: 2 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
  velocity_source_topic:  /ublox1/navpvt
  llh_source_type: 2 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /ublox1/fix
sub_gnss:
  llh_source_type: 2 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /ublox2/fix
# TF
tf_gnss_frame:
  parent: "base_link"
  child: "gnss"

reverse_imu_wz: false
reverse_imu_ax: false

# Origin of GNSS coordinates (ECEF to ENU)
ecef_base_pos:
  x : 0.0
  y : 0.0
  z : 0.0
  use_ecef_base_position : false

# Eagleye Navigation Parameters
# Basic Navigation Functions
common:
  imu_rate: 400
  gnss_rate: 10
  stop_judgement_threshold: 0.01
  slow_judgement_threshold: 0.278
  moving_judgement_threshold: 0.834

This is my setup, I performed static initialization for 30 seconds, then I move the robot, I have to move for a long distance around 50 meter to get the heading in dual antenna mode. How can I get faster heading estimation?

Video

[rsasaki0109]

So can I conclude that as long as I got the gnss_converter node publishing /eagleeye/navsat/rtklib_nav, I can procede to the next stage?

While in that state, heading won't be estimated unless the vehicle is moving, but you can proceed to the next stage. If that's undesirable, you should start the gnss_compass node and perform orientation estimation using multiple antennas.

The package KumarRobotics/ublox I mentioned previously also support publishing of NavPvt message, any modification needed for the message before I forward the message to gnss_converter node?

No modifications are necessary except for changing the velocity_source_type in the yaml configuration.

This is my setup, I performed static initialization for 30 seconds, then I move the robot, I have to move for a long distance around 50 meter to get the heading in dual antenna mode. How can I get faster heading estimation?

Is the gnss_compass node running? I will check the rosbag later.

[rsasaki0109]

I want the vehicle speed and IMU topics in the rosbag since they are missing.

~/Download/rosbag_multi$ rosbag info 2024-03-25-11-56-02.bag 
path:        2024-03-25-11-56-02.bag
version:     2.0
duration:    1:06s (66s)
start:       Mar 25 2024 12:56:02.35 (1711338962.35)
end:         Mar 25 2024 12:57:08.69 (1711339028.69)
size:        1.2 MB
messages:    4916
compression: none [2/2 chunks]
types:       diagnostic_msgs/DiagnosticArray          [60810da900de1dd6ddd437c3503511da]
             geometry_msgs/TwistWithCovarianceStamped [8927a1a12fb2607ceea095b2dc440a96]
             nmea_msgs/Sentence                       [9f221efc5f4b3bac7ce4af102b32308b]
             rosgraph_msgs/Log                        [acffd30cd6b6de30f120938c17c593fb]
             rtklib_msgs/RtklibNav                    [8533c89c82ac053f498dba1369c38618]
             sensor_msgs/NavSatFix                    [2d3a8cd499b9b4a0249fb98fd05cfa48]
             ublox_msgs/NavPOSECEF                    [6f1f4f9473d5586f7fa1427a3c53cee9]
             ublox_msgs/NavPVT                        [10f57b0db1fa3679c06567492fa4e5f2]
topics:      /diagnostics            289 msgs    : diagnostic_msgs/DiagnosticArray         
             /f9p/nmea_sentence     1166 msgs    : nmea_msgs/Sentence                      
             /rosout                 155 msgs    : rosgraph_msgs/Log                        (2 connections)
             /rosout_agg             146 msgs    : rosgraph_msgs/Log                       
             /rtklib/fix             270 msgs    : sensor_msgs/NavSatFix                   
             /rtklib_nav             270 msgs    : rtklib_msgs/RtklibNav                   
             /ublox2/fix             655 msgs    : sensor_msgs/NavSatFix                   
             /ublox2/fix_velocity    655 msgs    : geometry_msgs/TwistWithCovarianceStamped
             /ublox2/navposecef      655 msgs    : ublox_msgs/NavPOSECEF                   
             /ublox2/navpvt          655 msgs    : ublox_msgs/NavPVT

[minglok943]

latest rosbag
Hi, provided is the rosbag.
main gnss is publishing /ublox1/fix ... and /f9p/nmea_sentence
sub gnss is publishing /f9p2/nmea_sentence

use_gnss_mode: NMEA
use_can_less_mode: false

# Topic
twist:
  twist_type: 0 # TwistStamped : 0, TwistWithCovarianceStamped: 1
  twist_topic: /can_twist
imu_topic: /imu/data

gnss:
  velocity_source_type: 1 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
  velocity_source_topic:  /f9p/nmea_sentence
  llh_source_type: 1 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /f9p/nmea_sentence
sub_gnss:
  llh_source_type: 1 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
  llh_source_topic: /f9p2/nmea_sentence
# TF
tf_gnss_frame:
  parent: "base_link"
  child: "gnss"

reverse_imu_wz: false
reverse_imu_ax: false

# Origin of GNSS coordinates (ECEF to ENU)
ecef_base_pos:
  x : 0.0
  y : 0.0
  z : 0.0
  use_ecef_base_position : false

# Eagleye Navigation Parameters
# Basic Navigation Functions
common:
  imu_rate: 400
  gnss_rate: 10
  stop_judgement_threshold: 0.01
  slow_judgement_threshold: 0.278
  moving_judgement_threshold: 0.834

Since the gnss compass node is subscribing to main_gga and sub_gga, and the gga messages are only published in NMEA mode, so I tried publishing nmea message from two gnss. But still I can't get the heading and the /eagleeye/navsat/gga and /eagleeye/subnavsat/gga which are needed by gnss_compass are not publishing.
because the gnss converter node
terminate called after throwing an instance of 'std::invalid_argument'
what(): stod

[rsasaki0109]

Please set the common.moving_judgement_threshold to 0.5 [m/s] in the YAML. The default is set based on the car.

It's strange that wz in the rosbag's IMU data is always 0. Does the IMU only have an accelerometer? Eagleye requires a gyroscope.

[minglok943]

We are using Xsens MTI 670 DK as imu, there is gyroscope according to the datasheet

xsens_mti_driver_ros
we are using this ros node to get the data.

Also, I found that stoi or stod in nmea2fix_core.cpp is causing error.

Input string: 014158.40
Header time: 1.7115e+09
Year: 124, Month: 2, Day: 27
Hour: 10, Minute: 41, Second: 58
GPSTime: 17.4
Input string: 0�������K�3{2
Header time: 1.7115e+09
Year: 124, Month: 2, Day: 27
terminate called after throwing an instance of 'std::invalid_argument'
  what():  stoi
[navsat/gnss_converter_node-1] process has died [pid 19919, exit code -6, cmd /home/a2tech/catkin_ws/devel/lib/eagleye_gnss_converter/gnss_converter_node __name:=gnss_converter_node __log:=/home/a2tech/.ros/log/56d95daa-ebe1-11ee-ba5a-57b4451a012a/navsat-gnss_converter_node-1.log].
log file: /home/a2tech/.ros/log/56d95daa-ebe1-11ee-ba5a-57b4451a012a/navsat-gnss_converter_node-1*.log

eagleye_util/gnss_converter/src/nmea2fix_core.cpp

    std::cout << "Year: " << tm_GPSTime.tm_year << ", Month: " << tm_GPSTime.tm_mon << ", Day: " << tm_GPSTime.tm_mday << std::endl;

    tm_GPSTime.tm_hour = std::stoi(input.substr(0, 2)) + 9;
    tm_GPSTime.tm_min = std::stoi(input.substr(2, 2));
    tm_GPSTime.tm_sec = std::stoi(input.substr(4, 2));
    GPSTime_msec = std::stod(input.substr(6));

$GNGGA 014300.30 0132.6172046 N 10337.9604002 E 5 12$GNRMC 014300.40 A 0132.6172048 N 10337.9603574 E 1.518 272.48 270324   F V*0B 
Input string: 014300.30
Header time: 1.7115e+09
Year: 124, Month: 2, Day: 27
Hour: 10, Minute: 43, Second: 0
GPSTime: 17.3
gga->lat1.54362
gga->lon103.633
gga->gps_qual5
gga->num_sats12
gga->hdop14300.4
terminate called after throwing an instance of 'std::invalid_argument'
  what():  stod

    if (linedata[i].compare(3, 3, "GGA") ==0)
    {
      std::stringstream tmp_ss1(linedata[i]);

      while (getline(tmp_ss1, token2, ','))
      {
        nmea_data.push_back(token2);
      }

      std::cout << "gga" << std::endl;
      for (const auto& data : nmea_data) {
        std::cout << data << " ";
      }
      std::cout << std::endl;
//['$GNGGA', '014024.20', '0132.6105322', 'N', '10337.9856630', 'E', '5', '12', '0.67', '51.491', 'M', '4.837', 'M', '9.2', '0000*60']
      if(!nmea_data[2].empty() || !nmea_data[4].empty())
      {
        gga->header = sentence.header;
        gga->message_id = nmea_data[0];
        // gga->utc_seconds = stod(nmea_data[1]);
        if(!nmea_data[1].empty()) gga->utc_seconds = stringToGPSTime(nmea_data[1], sentence.header.stamp.toSec());
        gga->lat = floor(stod(nmea_data[2])/100) + fmod(stod(nmea_data[2]),100)/60;
        std::cout << "gga->lat" << gga->lat << std::endl;
        gga->lat_dir = nmea_data[3];
        gga->lon = floor(stod(nmea_data[4])/100) + fmod(stod(nmea_data[4]),100)/60;
        std::cout << "gga->lon" << gga->lon << std::endl;
        gga->lon_dir = nmea_data[5];
        if(!nmea_data[6].empty()) {
          gga->gps_qual = stod(nmea_data[6]);
          std::cout << "gga->gps_qual" << gga->gps_qual << std::endl;
        }
        if(!nmea_data[7].empty()) {
          gga->num_sats = stod(nmea_data[7]);
          std::cout << "gga->num_sats" << gga->num_sats << std::endl;
        }
        if(!nmea_data[8].empty()){
          gga->hdop = stod(nmea_data[8]);
          std::cout << "gga->hdop" << gga->hdop << std::endl;
        } 
        if(!nmea_data[9].empty()) {
          gga->alt = stod(nmea_data[9]);
          std::cout << "gga->alt" << gga->alt << std::endl;
        }

[minglok943]

latest rosbag with imu angular z

Hi, this is the latest rosbag, we have enabled the output of yaw rate of imu. We also disable other unused nmea messages. Now, the gnss converter node is working fine, publishing gga and rmc. However, the heading estimate still takes long time? How can we improve it?