GNSS: Limitations of the current uavcan.equipment.gnss.Fix message about public_regulated_data_types HOT 9 CLOSED

Fix type was not included in the message because it was intended that the final use of the fix type is to detect the quality, hence precision, of the fix, and this function was delegated to the error covariance estimate, provided in the matrix field position_covariance.

I now realize that this approach, indeed, did not account for all viable use cases. A possible solution is to utilize one of the reserved fields in the message (void5 or void4), converting them into an integer field defining the fix type, and freezing the message DSDL signature using the approach outlined here #4. Since we're going to re-use a reserved field, the binary compatibility should not be harmed - receivers that use old definitions will just continue to ignore the new field, and transmitters that use the old format will keep reporting zero in the new field, which should be declared to be a functionally-neutral value, e.g. indicating that the fix type is undefined or something of that effect.

What exact fix type codes would you propose to define? Keep in mind that there is already the status field which we can't touch, therefore the new type definitions should be orthogonal to it.

from public_regulated_data_types.

Since we already have the status field, the additional fix types I'd recommend would be:
DGPS/SBAS
RTK Float
RTK Fixed
Base (or static position)

There is a bit of a debate if DGPS should be split into two parts (DGPS and SBAS). Technically the two are different, but given that few people leverage a DGPS system other then SBAS, I'm not sure it makes sense. (For some hardware like the u-blox chips, it takes more work to distinguish between the two types of fixes). Given that the current MAVLink protocol treats them as identical, and overall DGPS usage is rarer then the other modes I think reporting it as a combination is probably fine.

I can't see any of these types of fixes (except for Base) not being a 3D fix as well, however since the original status field can't be modified, we can encode those states correctly (IE 2D base).

from public_regulated_data_types.

I am observing that the problem of categorizing fix types is slightly larger than what can be sensibly described with the proposed set of 4 values. Off the top of my head I can name several different operating modes:

• Single GNSS fix (base station mode may fall into this category)
• DGPS augmented GNSS fix (base station also may utilize this mode), with the following sub-modes:
  • SBAS
  • Other DGPS
• RTK with the following sub-modes:
  • Single
  • Float
  • Fix
• Moving base RTK, with identical set of sub-modes
• PPP
  • Float
  • Fix

This list is clearly not exhaustive. What I would propose is to use both fields, one for fix mode and the other for sub-mode. Furthermore, in certain cases it might be useful to use the sub-mode field as a bit mask rather than an integral value.

Does this make sense?

from public_regulated_data_types.

Unless I'm vastly mistaken there is no concept of float/fixed position types for PPP.

Not really sure what Single RTK type is, it's not a mode I've ever heard of before, and can find any documentation on.

Single GNSS Fix, how is this different from the existing list of fix types, and does this imply a single GNSS constellation/frequency?

from public_regulated_data_types.

In short, PPP relies on the phase ambiguity resolution, much like RTK does, so the concepts of floating and fixed solutions apply.

You are right about RTK, there is no "single" mode, it is essentially a regular Single GNSS fix.

Single GNSS fix is a mode in which the receiver uses no fix augmentation in the form of DGPS, RTK base station, PPP, etc.

from public_regulated_data_types.

The reason I'm questioning the floating/fixed aspect on PPP is none of the post processing software/receivers I've dealt with ever refer to those concepts in any manner for PPP, it's just always expressed as the computed solution with a error.

Regrading moving base, I admit I thought of it, but then considered that the positioning aspects are the same, and the additional distinction is in the form of GNSS attitude, which would need to be published in a additional message anyways, so I wasn't sure if it was needed. (At the same time filing one of the void slots probably leaves the space for this).

My biggest concern with the dual usage of the fields is that it seems to add a lot of complexity on the receiving side where typically these collection of fields will need to be mapped back into a single enum. At that point I can see how this buys us a degree of flexibility for the future on the GPS side, but I don't think it's buying us a denser protocol, and is burning both the empty slots at the same time, while every value we've listed is easily fit into one of the 2 free slots at the moment.

from public_regulated_data_types.

You may be right, the underlying nature of PPP may be not represented exactly by the higher level software. We can leave the sub-modes undefined for PPP, at least for now.

I agree that positioning aspects in the case of the moving base are identical, so this mode can be considered a special case of RTK, requiring no dedicated handling. Yes, orientation data must be published separately, using different message.

I don't envision any other meaningful use for the second field, so there should be no downsides in using both of them. Also I don't think the two field approach adds any noticeable extra complexity on the receiving end. The refined definition would look like follows:

# (some fields skipped)
uint3 MODE_SINGLE   = 0
uint3 MODE_DGPS     = 1
uint3 MODE_RTK      = 2
uint3 MODE_PPP      = 3
uint3 mode

void2

# (some fields skipped)

uint4 SUB_MODE_DGPS_OTHER   = 0
uint4 SUB_MODE_DGPS_SBAS    = 1
uint4 SUB_MODE_RTK_FLOAT    = 0
uint4 SUB_MODE_RTK_FIX      = 1
uint4 sub_mode

# (some fields skipped)

Do you think it makes sense?

from public_regulated_data_types.

Argh! @pavel-kirienko I totally missed the notification about this... Really sorry!

The proposed solution would work, while I still prefer just a single enum, I have no problems with whats outlined here as its straightforward to map it out into a single enum later.

from public_regulated_data_types.

Fixed.

from public_regulated_data_types.