-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Proposal: Deprecate all non MISSION_*_INT usage with a breaking change #1285
Comments
That makes total sense. We need to tighten up the overall protocol. |
@auturgy Any comment? |
@auturgy My understanding of your comments in dev call was that:
Is that correct? To me the value (to me) in this is simplifying the work for future implementations. Essentially a docs change that removes the old non-INT path. I believe I understand your objection as "not best use of time" rather than "bad idea". Can you please comment directly, because if it is the former, then I'd like to do the work. |
I should clarify that, I don't use the float versions, but it can be argued that they actually better represent some situations such as local NED much better then the int does. (Not that most systems have sensors that can read that accurately) |
Yup, that is why I proposed it. Simpler is better. |
Lets move to a PR and have a look at the impact - I think it'll be ok, as the lost local NED precision isn't useable anyway |
Isn't the only message that uses both _INT and NED variant the old Gimbal messsage? |
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
To progress this, PR created. See #1389 |
As it currently stands there is a hole in the mavlink spec with respect to _INT usage. There is a capability bit on the vehicle side. But there is no clear way to know whether the GCS side will support uploads of MISSION_ITEM_INT items. The only sideways sort of way to do that would be for the vehicle to remember if the GCS did a MISSION_REQUEST_INT. To both deal with that and remove complexity from the mavlink spec I propose a breaking change to only allow support for the _INT variants of the protocol.
This reflects the reality of PX4/ArduPilot/QGC/MP of today which supports the _INT based protocol. I don't see any reason to maintain the non _INT protocol moving forward. So gets reduce complexity and get rid of it.
Related to #8122
The text was updated successfully, but these errors were encountered: