gps_dump not recorded in .ulg, even when GPS_DUMP_COMM set
-
I have been struggling for a while to extract GPS information out of the drone. I am aware that info is sent in mavlink pipes and I am aware of voxl-inspect-gps. I do not have much c experience, and I am trying to avoid listening to the mavlink pipe as that seems like it would be the most challenging for me to do. At the end, I really just want a file that I can dump timestamps and positions to that can be read in by matlab. I have considered creating a service that runs voxl-inspect-gps -n and > it to a file then pulling that file afterwards as well.
Ideally, I would love to use the logger as I got pyulog up and running. I see that there are vehice_gps_postion messages, but I dont know how to parse those out. However, pyulog does have a function to extract gps_dump messages. I have pulled three log files with GPS_DUMP_COMM set to 0, 1, and 2 and confirmed these values are what I assume them to be in the log. None of these files have a gps_dump recorded in them. Are there any insights? Is there a better way to get the information I am looking for that doesnt involve me making a (my first and rather daunting) c++ dev environment?
-
@groupo There are a couple of topics normally logged that include timestamp, latitude, and longitude. The raw message from the GPS receiver is vehicle_gps_position. If you want the global position estimate from the state estimator then you can use vehicle_global_position. Both of these topics should be in the log file.
-
@Eric-Katzfey I've seen this
gps_dumpuorb not get recored because the default is to request optional logging. https://github.com/modalai/px4-firmware/blob/8d26285b2362354092aca88716c70d48a3c62ea2/src/modules/logger/logged_topics.cpp#L73
change toadd_topicfixes that.@groupo if you want to do something like PPK processing on raw GPS phase data then you need to change the GPS driver submodule. Upstream default explicitly disables msgs such as
UBX_RXM_RAWX. I don't know why. Would be useful functionality to have the dump param turn on raw data for devices that support it.Only other useful data without code change is
satellite_infothat will give carrier to noise ratio to diagnose GPS issues. But it's only published ifGPS_SAT_INFOis set to 1 and recorded if bit 5 ofSDLOG_PROFILEis high. -
@ben-grocholsky Thanks again Ben! And yes, the gps_dump is setup as "optional" meaning that it will log it if it sees the topic available when it is initialized. But since the logger is initialized before anything else it won't think that any of the optional topics are available. To change that you could move the logger start command to the end of the startup command sequence in /usr/bin/voxl-px4-start.
-
@ben-grocholsky And yes, we also use satellite_info to do performance testing on the GPS units.
-
Thank you again @ben-grocholsky! @Eric-Katzfey also thank you for the info about the logger startup.
Eric, I was able to get what I desired, albeit very crude. I ended up highjacking one of the functions in pyulog that prints to CSV and had it create a matlab struct instead which I can now run from my matlab. Not clean or sexy, but I think it gets the job done for now. A more experienced developer on my team thinks he will try to set up a restful web server and snag the output of
px4-listener sensor_gps. This seems like the best way to 'stream' the GPS data as the drone is in flight (besides setting up another MAVLINK client and working through parsing pipes, etc). Saying this more to tie up loose ends but I suppose I will ask if you see any gotchas or think there is a better way to access the information we are curious about? I initially identified the output ofvoxl-inspect-gpsbut it is not nearly as verbose as sensor_gps -
@ben-grocholsky also, we really just want the GPS data for truth against one of our other processes, not PPK. Thank you again for your help!
-
@groupo Yes, we have used
px4-listener <topic name>for external monitoring of PX4 topic data in other applications.
