I have the ZED-F9R dead reckoning board. Everything has been going well so far but I have come across a small issue.
I have a python script that takes frames from a camera stream and saves every 10th frame along with GPS coordinates. Additionally, a live feed is displayed on screen.
Using the python code provided by the sparkfun github page, I open a serial port connection from my computer to the ZED-F9R using:
coords = gps.geo_coords()
lat, lon = coords.lat, coords. lon
All this works and I get the coordinates correctly. The issue is that each time I send a request for the coordinates information, there is a noticeable lag in the stream and therefore the script.
I think that increasing the baudrate should increase the communication rate between the devices and minimize any lag. However I dont know how to set the baudrate on the ZED-F9R for usb communication.
In U-center I can go to UBX-config-prt and select usb, but it gives me no option to change the baudrate, unlike for UART1 or UART2.
I would find it hard to believe that I cant change the baudrate for usb since I can change the baudrate for the communication between u-center and the ZRD-F9R.
Is there a way to do this? Am I looking in the wrong location?
The ‘lag’ is just how the u-blox GNSS modules work. They produce solutions at the navigation rate; default is 1Hz. When you request (poll) the position (UBX-NAV-PVT), it can be up to a full second before the data is returned, depending on when you request it. You can make the PVT message periodic, where it is output automatically every second without polling. In your loop, you can keep checking for the arrival of a new message and update your local copy of the position when it arrives.
If you are connected directly to the module via USB to its USB port, the baud rate does not actually apply. It only applies when you use a FTDI interface chip or similar to convert USB to UART.
Thanks for the response! I see what you mean. Is there any way to change that rate?
The integration guide talks about using priority navigation mode to get the data output up to 30Hz. However I dont see this option available in the location stated by the manual. I do have the option to change the measurement period and navigation rate in CFG-RATE and additionally there is the CFG-HNR option that can be changed.
What is you opinion on this? Would this change anything or are these settings unrelated?
Im tagging about 3 photos per second on a moving platform, so unfortunately a 1Hz position update isnt fast enough. Is this just a limitation of the device?
Have you thought through the positional accuracy you need for each photo? What positional accuracy do you need in m? Can you achieve that: taking the speed of the moving platform into account; and the positional accuracy of the F9R? What is the platform’s maximum speed in m/s? With SBAS, the quoted positional accuracy is 1.0m. You need RTK to get to 0.01m plus 1 ppm of baseline. With that information, you can start to work out what update rate you need from the GNSS.
With the ZED-F9R, the “non-priority navigation mode” is limited to 2Hz for the -01B and -02B variants. For the -03B and -04B, it is 4Hz. The maximum for “Priority navigation mode” is 30Hz, where it uses the IMU to interpolate between GNSS solutions. CFG-RATE-NAV_PRIO sets the output rate of the priority messages in Hz. You need to access this through the Configuration Interface (CFG-VALSET and CFG-VALGET). Please see “3.2.8 Priority navigation mode” in the integration manual. The standard PVT and NMEA messages can all be output at the high rate. Be very careful that you do not overload the ports. If you are not using UART1 or I2C, disable message output on those ports entirely (set the output protocols to zero).
High Navigation Rate is something different and only supported on some modules. The dedicated UBX-HNR-PVT / ATT / INS messages can be output at higher rates. To see those, you need to enable or poll the messages and set the HNR rate.
We will be locating targets with these images and will need high positional accuracy in order to locate and accurately map the targets from the GPS coordinates. Realistically, we are aiming for an accuracy within .25m. We are using a Mosaic x5 as our base station and have been able to achieve a fixed RTK solution with about 5cm accuracy. The camera is drone mounted and will be flying only about 3-4 m from the surface at a slow speed of 1-2 m/s.
Ideally, we would take the photo and collect the location data within a fraction of a second ( the quicker the better of course) in order to ensure the located target positions can be as accurate as possible.
Slight side question, does it matter whether I use Gen 9 configuration view or the normal configuration view?
After changing the rates in CFG-RATE-NAV_PRIO (set to 3Hz) my python script would not correctly collect the data. Using Ublox GPS python library, I would see that when I poll,
gps.geo_coords() would return None. I did not have UART1 or I2C disabled for this. Is this indicative of the port being overloaded? Or do I have to change some of the other rates such as CFG-RATE-MEAS or CFG-RATE-NAV along with the priority rates.
It also seems the manual says that I will have to have completed the IMU alignment for this to work correctly. So I will go ahead and try that too.
I probably can’t help you much more unless I start replicating your setup. I don’t have time to do that - and I have little experience with the Python library. Sorry!
An alternative approach would be to timestamp your shutter signal using the UBX-TIM-TM2 message. If you feed your shutter signal to the EXTINT pin, the TIM-TM2 message will contain the Time of Week of the shutter event - with nanosecond resolution. The message holds the time of the most recent rising edge and falling edge. One message per navigation interval. So, you would need to push the navigation rate to 4Hz to capture edges accurately at <= 4Hz. You’d then need to interpolate the position of each event from the previous and next PVT messages.
Just FYI, the mosaic-X5 has similar feature. But it is able to capture the position of the event as well as the time. See ExtEventPVTGeodetic (SBF Block 4038). If your budget allows, maybe using an X5 breakout on the UAV would make life easier for you? You could log the ExtEvent blocks direct to SD card…
Thanks again for all the help. I think it is a limitation with the python code being used. I am able to get a reliable and quick output when set to 4Hz, anything faster will return None or a PVT message at sporadic intervals, so I will likely stick to that for now until we have completely setup and tested the entire system.
