search

UAVTracking / UAVTrackingProtocol

An open radio protocol for transmitting UAV flight data in real time.
https://xkcd.com/927/
11 stars 4 forks source link

Source of position data #20

Open darekzbik opened 7 years ago

darekzbik commented 7 years ago

What should be a source of done position?

There are several sources GPS/GLONASS/Galileo which one should be used? Also some other GPS related parameters are important to ensure that position of both aircraft are calculated in the same way. Should we insist to sue WAAS or not?

pjalocha commented 7 years ago

My experience with drones is limited: I have looked at the ArduPilot and there I realized drones try to keeps their position as accurate as possible. They not only use the GPS but as well the pressure sensor and the inertial sensors to produce a global estimate which is better than the GPS position.

Simply by taking the position from the drone itself we would likely get better estimate than with a best GPS. In case of the ArduPilot you can do it by feeding the position transmitter from the MAVlink port of the autopilot.

yohanboniface commented 7 years ago

There are several sources GPS/GLONASS/Galileo which one should be used?

What would be the rationale to allow only one of those sources?

Should we insist to sue WAAS or not?

I wonder if this regards the protocol itself (at least at this stage). As I understand it, the protocol tries to define a common way of exchanging information, but let the users define what is the best way to get this information in an accurate way.

Also we should keep in mind that UAVs are not only aircrafts with an advanced onboard flight controllers (as ArduPilot or PX4), but also model aircrafts, with fuel engine and so on. At least on the French context, those are considered UAVs and will need to conform to the law and send their positions too. They will need to add some dedicated add-on modules, which certainly will have less CPU power and instruments (compass, air pressure…). Hence what I mean is that we should certainly not make too much assumptions about the capabilities of the UAV, and focus on how it should send which information. However in some case we certainly should define a minimum accuracy of the information to be valid as per protocol specifications.

pjalocha commented 7 years ago

Are the simple RC models considered as UAV's falling under the obligation to transmit their position if they are heavier than 0.8kg ?

Should there be a field saying what is the source of the data ? This could be difficult, as there can be many possible source or combinations of these. For now I can see three sources: GPS, inertial sensors and pressure sensor, thus we could have a 3-bit field saying which of these are used to determine the position. In my proposed format the pressure sensor is actually already covered.

With my proposed header I have the fields "Human" and "Pilot". For RC aircrafts the fields would be: Human=0 (no human on board), Pilot=1 (human pilot)

yohanboniface commented 7 years ago

Are the simple RC models considered as UAV's falling under the obligation to transmit their position if they are heavier than 0.8kg ?

Yes (when they fly out of an official RC airfield).

Should there be a field saying what is the source of the data ?

As for every payload field, the answer is an arbitration between usefulness of the data and added length on the payload. Seems to me that the balance is negative in this case.

With my proposed header I have the fields "Human" and "Pilot". For RC aircrafts the fields would be: Human=0 (no human on board), Pilot=1 (human pilot)

Interesting!

pjalocha commented 7 years ago

I agree for the negative balance. The equivalent information is transmitted in the estimated position accuracy field, as this is really what counts. For GPS-only the accuracy would be (normally) worse.

darekzbik commented 7 years ago

@yohanboniface I think that I need to explain that I'm a glider pilot so I'm strongly biased to anti collision aspect of this protocol. And if someone is going to use the same format glider anti collision purpose source of position as well as additional correction options are important to have the same position. For gliders it is important as sometimes gliders are flying close one to another.

Maybe in this spec we should focus on UAV/RC models. If we are talking about collision between glider (with human inside) and some RC/UAV I think that most pilots will simply stay in a distance big enough to ignore differences between GPS/Glonass ....

I think that GPS (US) is the most popular and cheapest solution. Now days most GPS has WAAS enabled by default so simply let's specify GPS source with WAAS should be enabled and dead reckoning should be disabled. When at some point Galilego or Glonass become more important new version of protocol can enforce different source.

In all cases we need to be clear what should be a source of position.

pjalocha commented 7 years ago

We could add that the dynamic mode "airborne" should be chosen for the GPS, which I think is the case anyway for the drones.

darekzbik commented 7 years ago

@pjalocha 'airborne' mode is a name used by uBlox so it is better to be more specific what we need. It is true that ublox airborne mode is something what is expected but it is better to specify required dynamics in Gs or other important params. What if some crazy GPS manufacturer enable dead reckoning limit dynamics to 1G and just call this mode 'airborne'?