-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GNSS: Limitations of the current uavcan.equipment.gnss.Fix message #7
Comments
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 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 ( What exact fix type codes would you propose to define? Keep in mind that there is already the |
Since we already have the status field, the additional fix types I'd recommend would be: 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). |
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:
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? |
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? |
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. |
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. |
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? |
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. |
Fixed. |
Status doesn't allow for reporting any fix types better then 3D fix. This is a problem as there are significant differences between 3D, DGPS, RTK Float, RTK Fixed types. (As well as not allowing for future reporting of a fixed base status).
The accuracy estimates can be used for comparing which GPS to use, however there are several issues with trying to use it in this manner:
The text was updated successfully, but these errors were encountered: