GPS-RTK2 ZED-F9P Question about the use of a moving base

Hello everyone , I’d like to make a heading sensor for a flying drone with the GPS-RTK2 ZED-F9P, but I’d also like to have his positioning in space so here are my questions :

-Do I need two boards (a moving base and a rover) on the drone to have the heading and two more boards (a base on the ground and a second rover on the drone) to have the positioning ?

-Or can I use the moving base on the drone to act simultaneously as a rover for the base on the ground ? In this case I will only need 3 boards. (One rover on the drone, one moving base on the drone and one base on the ground)

-Or if a moving base can’t be used simultaneously as a rover, can I have one base on the ground and two rover on my drone and then process the heading of my drone by using the data position of the two rover ?

Thank you for your time !

Basically, I’d like to know if a system like this is feasible and if it is, what are the configurations for my different boards.

  1. I believe the base in this configuration should be stationary.

  2. 915 MHz has a much better link budget than WiFi. Free Space Path loss over 500ft at 915 MHz is 75.33dB and at 2400 MHz is 83.7dB (assuming the same tx power and antenna gain)

  3. I don’t think you need two GNSS receivers on you drone.

Which base should be stationary ? The one on the ground ? In my application I need it to be a moving base as I want to create a kind of “follow me” drone.

I am taking note for the wireless communication advice ! :slight_smile:

And I need two GNSS receivers on my drone because I want the heading of my drone. To do that you need a moving base and a rover on the same drone, this is explained in this application note of the ZED-F9P:

ZED-F9P-MovingBase_AppNote_(UBX-19009093).pdf (1.37 MB)

But one of my main question is how can I use a moving base simultaneously as a rover for the base on the ground ? What is the configuration for doing this ?

I absolutely have not tried this, but I think what you propose should work…? Maybe?

The car base is feeding corrections to the drone base.

The drone base is feeding corrections to the drone rover.

The drone rover is outputting its position relative to the drone base (RELPOSNED). That gives you the drone orientation.

I was wondering if you also need to know the position of the drone base relative to the car base, but I don’t think you do?

So long as you are outputting the drone rover position (PVT) and relative position (RELPOSNED) then I think you have everything you need to calculate the relative position and orientation of the drone pair to the car base.

All this is relative though. None of this will give you accurate absolute positioning. Unless the car base is also receiving RTCM corrections from a nearby static base (via NTRIP).

I do worry about having those two GNSS antennas on the drone. The baseline will be really short. And getting both away from the props could be challenging?

Wow. That’s quite a project. Please let us know if it works!

Best,

Paul

If you want to calculate and display the relative position / orientation in real time, your microcontroller also needs the position of the car base. You need a link from car base Tx back to a second port on your microcontroller. Or use I2C for that.

PaulZC:
I absolutely have not tried this, but I think what you propose should work…? Maybe?

The car base is feeding corrections to the drone base.

The drone base is feeding corrections to the drone rover.

The drone rover is outputting its position relative to the drone base (RELPOSNED). That gives you the drone orientation.

I was wondering if you also need to know the position of the drone base relative to the car base, but I don’t think you do?

So long as you are outputting the drone rover position (PVT) and relative position (RELPOSNED) then I think you have everything you need to calculate the relative position and orientation of the drone pair to the car base.

All this is relative though. None of this will give you accurate absolute positioning. Unless the car base is also receiving RTCM corrections from a nearby static base (via NTRIP).

I do worry about having those two GNSS antennas on the drone. The baseline will be really short. And getting both away from the props could be challenging?

Wow. That’s quite a project. Please let us know if it works!

Best,

Paul

Thank you for your answer Paul !

Actually, what I need in my project is the heading of the drone (this is why I have two GNSS on the drone) and I do also need the precise relative position of the drone to the car.

So I need to get the output of the rover to have the heading, but do I also need the output of the drone base to have an accurate relative position ? or the rover output is enough ?

Because I think that to calculate the relative position of the drone to the car with the positions of the rover and the car would be less accurate than having directly the relative position from the drone base.

I don’t think I’ll need an accurate absolute position but thank you for the information about the NTRIP !

For the two antennas, I’ve seen YouTube videos where they get about 1 or 2 degree precision on the heading with 50cm between the two antennas. Therefore, I will try my best to put the antennas away from each other as much as possible ! :slight_smile:

PaulZC:
If you want to calculate and display the relative position / orientation in real time, your microcontroller also needs the position of the car base. You need a link from car base Tx back to a second port on your microcontroller. Or use I2C for that.

You’re right but if the base of the drone is already outputting its relative position (which I don’t know of it can…) to the car I won’t need this, but I will need a link from drone base Tx back to my microcontroller. Because as I said, I think that to calculate the relative position of the drone with the absolutes positions of the drone and the car won’t be accurate.

So the big question here is do the moving base on the drone can output its relative position ? :?: :?:

Thank you for your time !

Do you mean the heading of the drone, or its orientation? Your drone could be heading (travelling) North, but oriented (pointing) West. I think you mean orientation, right?

RELPOSNED gives you the relative position of the rover compared to its base. The coordinates are North, East, Down in cm and mm. It also gives you heading and length of the relative position from the base. The length will be fixed - it is the distance between the two drone antennas. The heading is actually orientation, compared to the base. It doesn’t give you any information about the heading that the drone is travelling in. For that, you need the heading from the standard Position (PVT) message.

(I might be confusing myself of course. More coffee required!)

Good point about the drone base outputting RELPOSNED too. I don’t know if it can do that. Maybe?

But even if it can’t, I think you have everything you need if you know the drone rover position and the car base position. You could calculate the orientation and distance manually.

PaulZC:
Do you mean the heading of the drone, or its orientation? Your drone could be heading (travelling) North, but oriented (pointing) West. I think you mean orientation, right?

RELPOSNED gives you the relative position of the rover compared to its base. The coordinates are North, East, Down in cm and mm. It also gives you heading and length of the relative position from the base. The length will be fixed - it is the distance between the two drone antennas. The heading is actually orientation, compared to the base. It doesn’t give you any information about the heading that the drone is travelling in. For that, you need the heading from the standard Position (PVT) message.

(I might be confusing myself of course. More coffee required!)

Yes by heading I mean orientation, like a compass !

Thank you for the protocol information. PVT and RELPOSNED are in the UBX protocol do you know if the same data are sent in NMEA protocol ? I’m not familiar with both of them, but NMEA seems to be easier to decode in a microcontroller I don’t know.

PaulZC:
Good point about the drone base outputting RELPOSNED too. I don’t know if it can do that. Maybe?

But even if it can’t, I think you have everything you need if you know the drone rover position and the car base position. You could calculate the orientation and distance manually.

You’re right, but I’m worried about the accuracy of this method. When I’ll have my boards, I will let you know if the moving base also output its relative position to the ground base ! :slight_smile:

There’s no way to access RELPOSNED as NMEA… UBX is the way forward. The SparkFun u-blox GNSS library for Arduino should have everything you need. :smiley:

Thanks a lot !

I couldn’t resist… I had to try this. And - drum roll please - it works! With three ZED-F9P’s… (I tried using a ZED-F9R as the drone rover but couldn’t get it to work. Must have missed something there…)

I’ve attached the write-up, in case it comes in handy.

Good luck with your project - please let us know how it goes,

Paul

Multiple RELPOSNED.pdf (160 KB)

Awesome ! I can’t wait to try this myself !

Thank you for the write-up, as a beginner with F9P it will help :slight_smile:

I was thinking about the architecture of my system and I was wondering if a wireless module like a XBee 3 PRO ZigBee 3.0 (https://www2.mouser.com/new/digi-intern … 3-modules/) would be enough for the transmission of the correction data. In term of distance, I know it will be ok, but in term of data rate I was wondering if 250kb/s will be enough.

Have you ever used something similar or any kind of wireless transceiver with F9P ?

All of the tests I did over the weekend were using the default baud rate of 38400 on UART1 and UART2. The ZigBee should be should be more than fast enough, but I have not tried it.

There is also a new LoRa product available - if you need extra range:

https://www.sparkfun.com/products/20029

Best wishes,

Paul

Ok great! I’ll give you feedbacks about my system when finished :slight_smile: