inav
inav copied to clipboard
iNavFlight
Offset GPS coords on OSD
This feature was previously mentioned in https://github.com/iNavFlight/inav/pull/7908 Thanks Sergey!
But since the author didn't rebase it for quite some time - I had to do it. Now updated to current master.
Tested in HITL:
Let's teleport to 0.000000, 0.000000
Enable the offset feature
And here we go
Should I add the altitude offset too? This should be useful for the same reason - video sharing.
It's to mask the actual GPS coordinates on the OSD. It stops people snooping on the video feed from knowing where you are.
Vector had it. It was confusing when you didn't know it had been set 🤣
It's probably less usful for systems like DJI and Walksnail. Where there is binding of the video link. But for analogue and HDZero. It could be useful.
It is also useful when sharing your DVR footage, no need to blur coordinates and altitude.
It would have no affect on the altitude. With WS or WTF, there's no need to blur anyway. You can render the OSD separately. Then just mask those elements so they're not visible. It looks much neater than blurring 👍🏻
Yes, but some of us render DVR with full OSD and then delete the original video file. So there is no way to render it again with some OSD elements disabled.
But with offset GPS and altitude already embedded in the video I still have this data without compromising myself. So for digital FPV systems this can be done on the ground while rendering, for analog there is no choice.
Just offsetting the altitude may not be enough though. Perhaps omitting the first 2 digits(out of total 4) would be a better solution? Or just hard cap the altitude to predefined value if it is higher. But this can't be decoded by the user too.
As mentioned in #7908 it would be useful if this was also applied to Plus Codes.
Yes, but some of us render DVR with full OSD and then delete the original video file. So there is no way to render it again with some OSD elements disabled.
But with offset GPS and altitude already embedded in the video I still have this data without compromising myself. So for digital FPV systems this can be done on the ground while rendering, for analog there is no choice.
Just offsetting the altitude may not be enough though. Perhaps omitting the first 2 digits(out of total 4) would be a better solution? Or just hard cap the altitude to predefined value if it is higher. But this can't be decoded by the user too.
Ah, that's pretty limiting. I much prefer having the OSD rendered as a separate file. It allows much more editing freedom.
With regard to the altitude. I don't think that should be messed with. It is actually proving information that you use in flight. Having said that, I did have an unofficial build once that had "altitude roundabout". For shits and giggles. Once it got to 100 metres, it started again at 0 🤣. But I wouldn't dream of putting anything like that in the official release. There's only one reason for having that, which is flying illegally. Something the firmware can't support. Moving the GPS coordinates is different. Because that can be for safety concerns and avoiding theft.
@MrD-RC Understood. No messing around with altitude.
@breadoven Thanks for the suggestion.
I would like to know the reasoning behind this change. So far, the only practical reasons I can think of are related with potentially illegal/military applications. From the practical point of view, I see no good reason to try to scramble coordinates. If one does not want to share coordinates I suggest removing this element from OSD and relying on radio telemetry. Or not sharing DVR or blurring
The legitimate reasons were around before the conflict. But mainly applied to analogue. Anyone can potentially snoop on your FPV image. Then find out where you are and can steal your equipment. It's a safety feature, especially if you're flying alone. But given the current climate, I can see how this could be also used in that environment.
Checking the OSD DRV is probably the easiest way of getting the coordinates of a lost model in the field. Some radios don't record telemetry logs and even if they do it's not as easy to retrieve the log as looking at the DVR replay. So this change would be useful if you want to easily find the location of a lost model whilst maintaining privacy if you want to make the DVR public later on without exposing where you were flying. Just saves having to obscure the DVR OSD coordinates ultimately.
Obviously I don't want this feature to be used in any other way than just enjoying the flight.
Unfortunately, it can be used in a harmful way too. So as waypoint mode or anything else.
But if it comes as a security/legal concern - I'll delete this PR. It is up to core developers to decide.
I would rather enhance programming framework to access current lat/lon, store modified lat/lon to GVARs and then show GVARs in custom OSD elements https://github.com/iNavFlight/inav/pull/9508
