Skip to content
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

Fallback to mavlink system ID if no UUID available #80

Merged
merged 6 commits into from
Sep 25, 2017

Conversation

julianoes
Copy link
Collaborator

This changes the logic so that you the UUID is used if available but the
mavlink system ID is used as a fallback option. The fallback happens if
3 requests for the autopilot_version are unsuccessful or if the
AUTOPILOT_VERSION.uid field is 0.

This replaces #77.

This changes the logic so that you the UUID is used if available but the
mavlink system ID is used as a fallback option. The fallback happens if
3 requests for the autopilot_version are unsuccessful or if the
AUTOPILOT_VERSION.uid field is 0.
Copy link
Collaborator

@hamishwillee hamishwillee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change looks reasonable but I don't think I can "approve" - my C++ isn't good enough.

That said, what I'm not seeing is:

  1. Update to docs explaining that UUID may not really be a UUID. This should probably be in: device_uuids() and typedef event_callback_t

@hamishwillee
Copy link
Collaborator

Should the user be warned that they're working on a SYSID and not a real UUID? I guess the chances are that if the UUID < 255 they can tell that it is not "real".

@hamishwillee
Copy link
Collaborator

I added #81 for discussion of the cases that come up due to shared SYSID, and in particular when the UUID is the SYSID.

@julianoes
Copy link
Collaborator Author

Should the user be warned that they're working on a SYSID and not a real UUID? I guess the chances are that if the UUID < 255 they can tell that it is not "real".

Ok I'll add that to the docs, thanks @hamishwillee.

This allows to direct the MAV_CMD_SET_MESSAGE_INTERVAL commands.
We use a timeout of 0.5s to slow the retries down. Otherwise, we can run
into the case that the retries are exhausted just because many
components send heartbeats at the same time, or if somebody sents
heartbeats at a high(er) rate.
Copy link
Contributor

@darioxz darioxz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be correct 👍

@mrpollo mrpollo merged commit 8789ac3 into improve-timeouts Sep 25, 2017
@mrpollo mrpollo deleted the uuid-or-sysid branch September 25, 2017 19:14
dlech pushed a commit to dlech/MAVSDK that referenced this pull request Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants