GPS sampling rate is limited

[yu zhang]

Hi team,
I tested the default GPS sampling rate is about 1Hz, and I am thinking if it could be set up to 5-10Hz? It seems the GPS sampling rate is automatically configured by px4 and there is no way to change it in QGC, right?

Also, I installed another RTK GPS (Holybro F9P) on m500. It works fine, and the accuracy is much better than the default GPS. However, the RTK sampling rate is also limited to about 1Hz. As it's a u-box device, the sampling rate can be configured using u-center software. But, after trying a couple of times, I found no matter what rate I put in the u-center, the logger of px4 still kept outputting 1Hz GPS data. So, it's quite weird. Do you have any advice about it?
Thanks.

[Steve Turner]

https://github.com/PX4/PX4-GPSDrivers/blob/master/src/ubx.cpp#L2307

Might be a good place to start when it comes to PX4 talking to a UBX receiver. I believe even after you set params in U-Center, PX4 overwrites them with its own configuration at startup.

[yu zhang]

Hi @stevet It's great to know PX4 will overwrite the config

All right, thanks for that and I will then have a look at the PX4 side.

[yu zhang]

Hi @stevet, I asked PX4 side about the configuraion, and they pointed a place where they started to rewrite their configuration.
https://github.com/PX4/PX4-GPSDrivers/blob/master/src/ubx.cpp#L536

From here, it seems PX4 does try to set F9P RTK at a higher rate (e.g., 10Hz for normal mode or 8Hz for moving base mode). For Holybro F9P, the general max rate can be 8Hz. So, it seems their configuration should acheive the maximum rate.

So, is the GPSDirver code already in the VOXL-PX4 framework? Actually, I checked the px4-firmware-1.11.3-0.2.3 source code, but I didn't find the ubx.cpp file. Can you please double-check where I could locate this file in VOXL?

Also, PX4 asked me to check the px4-firmware-1.11.3-0.2.3/src/modules/logger/logged_topics.cpp to see if the logger of PX4 is limited the rate. I saw 122 lines for add_topic_multi("vehicle_gps_position", 1000);. It sets 1Hz as the lower bound, but I think it could work to log a higher rate, right?

[tom]

@yu-zhang This is the branch that the current PX4 version is built off: https://github.com/modalai/px4-firmware/tree/modalai-1.11

[yu zhang]

Hi @tom, thanks for the link. The current stable release was v1.12.3, and it does improve a lot over v1.11.3. I am wondering why you haven't recommended people refresh this release on m500? It should be already well-tested on the drone, right?

Also, it seems I still didn't find the ubx.cpp in this branch. It should be somewhere at /src/drivers/..., right? Can you please help me locate it? Thanks.

[tom]

@yu-zhang That project gets pulled in via. a submodule: https://github.com/modalai/px4-firmware/blob/f40863b2a72a3cf1c8d85b364a25a5dff3e87898/.gitmodules#L30

[yu zhang]

@tom All right, I see. I double-checked the px4-firmware-1.11.3-0.2.3 was built on 16 Nov 2021. And this GPS submodule was updated with F9P rate commits on 11 Nov 2021.
https://github.com/PX4/PX4-GPSDrivers/commit/f777421ecb559dd37d5a812213c59b18e61ae796

In this case, px4-firmware-1.11.3-0.2.3 should already include this rate update, right? If so, PX4 should automatically set the rate at 8Hz for F9P, but why I could only get 1Hz output from the log?

I also double-checked the logger in the px4-firmware-1.11.3-0.2.3, and it does set 1Hz as a default lower bound, but it should work to output if the rate is set higher than the default.

So, please any advice on this issue? I would get an 8Hz F9P log output.

[yu zhang]

@tom Also, in the px4-firmware-1.11.3-0.2.3/src/modules/logger/logged_topics.cpp, it has
add_topic_multi("vehicle_gps_position", 1000);.

I am wondering if the log will firmly output the GPS data at 1000ms (1Hz) whatever the GPS rate is, or it will output a higher rate if the actual GPS rate is higher than 1Hz? Thanks.

[tom]

@yu-zhang Any PX4 code related questions are probably better suited for the PX4 slack, people are usually pretty eager to help there: https://slack.px4.io/

[yu zhang]

@tom Actually, I already asked them via slack, but it seems they are not that eager to reply to people's questions. Anyways, I will double-check with them then.

Before that, can you please confirm that the released px4-firmware-1.11.3-0.2.3 already included the commit of GPS submodule on 11 Nov 2021? Or do you think I should refresh the Stable Release v1.12.3 to make sure that?

What if I would need to recompile the px4-firmware locally to achieve a high GPS rate, should I continue to make it based on the v1.11.3-0.2.3 or the v1.12.3?

I think I shouldn't do it based on the current dev version because I am not sure if there are any bugs unsolved in the latest dev.

[Steve Turner]

It looks like v1.11.3-0.2.3 uses https://github.com/PX4/PX4-GPSDrivers/tree/bcd57ae2396fe0fd88b725d81a686e072ef0ecc9 which was commited April 29 2020. Update that submodule to the versions, try to recompile and see what happens.

I did a quick check and it looks like there may be some compile issues to resolve to make it work.

[579/1381] Building CXX object src/drivers/gps/CMakeFiles/drivers__gps.dir/devij
FAILED: src/drivers/gps/CMakeFiles/drivers__gps.dir/devices/src/mtk.cpp.obj
/usr/local/bin/ccache /opt/homebrew/bin/arm-none-eabi-g++ -DCONFIG_ARCH_BOARD_Pp
In file included from /Users/sturner/Documents/code/darkhive/modal/px4-firmware,
                 from /Users/sturner/Documents/code/darkhive/modal/px4-firmware:
/Users/sturner/Documents/code/darkhive/modal/px4-firmware/src/drivers/gps/devicd
  283 |  void gotRelativePositionMessage(sensor_gnss_relative_s &gnss_relative)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.

I've not tried latest PX4 v1.12.3 on the Flight Core myself but I would imagine you could cherry pick some of the GPS logging changes into v1.11.3-0.2.3

[yu zhang]

@stevet Thanks so much for the quick check.

All right, I will have a try to figure it out then. Hope some simple changes could work for me

[yu zhang]

@stevet I have a question about the recompile.

It seems directly using git submodule update will get the latest commits. I am thinking about how to reset all submodules back to the v1.11.3-0.2.3? Should I reset them one by one with the specific commit id or if there is an easier way to do so?

What if I may have to do it one by one, I am wondering where I could find out those commit ids?

[Steve Turner]

@yu-zhang If you are OK with losing any changes you made in the submodules, you can make sure you have checked out the v1.11.3-0.2.3 branch created by Modal and then in the root of the PX4 repo run: git submodule foreach --recursive 'git reset --hard' that will reset each subrepo back to a known state.

You can also go into a particular submodule and update/pull to whatever revision you want. .gitmodules contains the commited submodules. Versions of submodules are tracked in the commit of the outer repo.

https://www.vogella.com/tutorials/GitSubmodules/article.html is a good quick tutorial on some common commands for submodules. https://git-fork.com is a good GUI client for Windows and MacOS as well. GitKraken is good for Linux or if you want one client SmartGit will work on all platforms. None of these are free options but can help if the CLI is not your preferred interface.

[yu zhang]

@stevet All right, thanks so much for that, and I will have a try about it then