-
-
Notifications
You must be signed in to change notification settings - Fork 529
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
Fix backend connection issues #578
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We already disabled initialization without UUID behind an ifdef, however, we missed one place. This change disables the fallback after 10 heartbeats/seconds as well. This fixes an issue where we call `on_discovery` even though only a UDP bridge and no vehicle is connected.
This changes the initialization logic to first start the GRPC server and then try to connect it all. This is based on the assumption that we can initialize the GRPC server and the plugin it has using the default/dummy system and we don't have to have anything connected yet. Once something connects, the system gets updated and the plugins start to "work".
We need to remove this assert because we now initialize the GRPC server without having a vehicle connected and therefore, the system list of system UUIDs can be empty. This doesn't matter because the default/dummy system is still valid and the plugins will be ok later.
Minor version bump because the initialization of the backend changed.
JonasVautherin
requested changes
Oct 26, 2018
These are check to prevent us from calling on_discovery if we're actually just a dummy system and should wait until something real is connected.
This is a hack to prevent a UDP_BRIDGE from telling us we're connected when really we're interested in the drone, not the connection bridge. A proper fix would be to check for specific components when deciding if something is connected or not.
As a general rule we should have all custom things in `init()` and `deinit()` instead of the constructor or destructor.
This fixes the problem where we don't have a camera definition because we never receive the camera information. We need to request the camera information when we're connected, so in `enable()` not when constructed `init()`.
JonasVautherin
approved these changes
Oct 26, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a couple of connection issues: