HKUST-Aerial-Robotics / ublox_driver

A driver for u-blox receiver (ZED-F9P) with ros support
GNU General Public License v3.0
96 stars 44 forks source link

Why is there no ionosphere topic? #1

Closed JiangZhengok closed 3 years ago

JiangZhengok commented 3 years ago

Today, I use this ublox_driver to collect data. The collected rosbag info as follows:

image

Obviously, we drove for 21 minutes, but there is no /ublox_driver/iono_params topic. But your rosbag has /ublox_driver/iono_params topic. I know from your ublox_driver code( as follows) that both the ephemeris and the ionosphere are parsed from the RXM-SFRBX.

image

So I don't understand why there's ephemeris but there's no ionosphere. Is it something to do with the environment or the weather? Today's weather is cloudy, we collected data in the urban open environment. Or, could it have something to do with a GPS antenna?

shaozu commented 3 years ago

The code only parses ionospheric parameters from Beidou's ephemeris data, so make sure that your receiver supports Beidou and it's enabled. Nevertheless, the ionospheric parameters can be obtained offline so your bag is still good to use.

JiangZhengok commented 3 years ago

The code only parses ionospheric parameters from Beidou's ephemeris data, so make sure that your receiver supports Beidou and it's enabled. Nevertheless, the ionospheric parameters can be obtained offline so your bag is still good to use.

I see. I banned Beidou yesterday by u-center. Thank you very much. Do ionospheric parameters fluctuate very little in the same region at the same time? In the same area at different times? How to get ionospheric parameters offline? Do you get the the default ionospheric parameters of visensor_left_f9p_config.yaml offline?

shaozu commented 3 years ago

The ionospheric parameters vary from time to time, but I think the difference of the final ionospheric delay can be small.

You can obtain these parameters from here. Simply download the ephemeris file and the parameters are included inside.

The default parameters in visensor_left_f9p_config.yaml are drawn from a random day. It doesn't matter whether is comes from online or offline. The values are just the same.

JiangZhengok commented 3 years ago

Hi, @shaozu. Thanks for your help. I recollected the data today. Does GVINS have data frequency requirements? In my bag, image is 10Hz, Imu is 100Hz. The system always restarts after GNSS-VI align when I run GVINS use my bag. I use my config file. Always print that "throw gnss, only should happen at the beginning" during the run. Is it because I didn't do hardware synchronization? image

It can run 300m before the trajectory divergence if I disable GNSS. image

shaozu commented 3 years ago

Hi, @JiangZhengok. What's the frequency of your GNSS measurement?

If the message "throw gnss, only should happen at the beginning" pops up frequently, then synchronization may be an issue.

JiangZhengok commented 3 years ago

Hi, @JiangZhengok. What's the frequency of your GNSS measurement?

If the message "throw gnss, only should happen at the beginning" pops up frequently, then synchronization may be an issue.

The frequency of my GNSS measurement is 20Hz that is the same as yours. Hardware synchronization cannot be achieved in our car at this time. I'm looking for other solutions. Do you have any good suggestions? I'm now adding the wheel speed constraint.

shaozu commented 3 years ago

The frequency of GNSS in our platform is 10Hz (camera: 20Hz, IMU: 200Hz). During the process we halve the image's frequency to improve efficiency as well as match with that of GNSS. So in you case, you may set the GNSS output to 10Hz and modify the code here.

JiangZhengok commented 3 years ago

The frequency of GNSS in our platform is 10Hz (camera: 20Hz, IMU: 200Hz). During the process we halve the image's frequency to improve efficiency as well as match with that of GNSS. So in you case, you may set the GNSS output to 10Hz and modify the code here.

Sorry, I made a mistake yesterday. My GNSS observation frequency is 10Hz. I've changed the code which halve the image's frequency and the message that “throw gnss, only should happen at the beginning” doesn't pop up frequently. I note that your body frame is x-y-z(right-down-front), but my body frame is x-y-z(right-front-up). Does that affect the result? Do I need to change the code?

shaozu commented 3 years ago

The orientation of the body(IMU) frame does not matter. It only affect the extrinsic parameters between camera and IMU.