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

Fix backend connection issues #578

Merged
merged 10 commits into from
Oct 26, 2018
Merged

Fix backend connection issues #578

merged 10 commits into from
Oct 26, 2018

Conversation

julianoes
Copy link
Collaborator

@julianoes julianoes commented Oct 26, 2018

This fixes a couple of connection issues:

  1. We start the discovery before the vehicle is actually connected.
  2. We miss the discovery because the GRPC server doesn't run yet when we try to register the discovery.
  3. The camera tried to early (before being connected) to get the camera information.
  4. A UDP_BRIDGE would mean that we always think the vehicle is connected, when we actually only see the bridge.

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.
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()`.
@julianoes julianoes merged commit 466e7e2 into develop Oct 26, 2018
@julianoes julianoes deleted the fix-connection-issue-2 branch October 26, 2018 14:11
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.

2 participants