Drone instance doesn't ignore messages from other destination sys_id

[billbonney]

This is related to #443 since when this is fixed you get the connection bar/mode control toggling between mavlink heartbeat message from system_id the than the drone instance related one. If you connect a second system, e.g sys_id 254 that could be a connected GCS the system becomes unusable.
These images show two frames as the control bar changes (probably has a different name but I am just getting familiar with the code)

[billbonney]

fixed in version_3.0.2 (but still needs #443 fixed)

[seanmcleod]

Won't this fix also filter out broadcast messages now?

[billbonney]

@seanmcleod Which messages are those? I assume you mean sys_id of 0. It's easy to add a condition for that but if there is no responsder in the drone object for a broadcast messages nothing changes.

[seanmcleod]

@billbonney Yes I'm referring to broadcast messages which use a sys_id of 0. When we first came across issue #443 I looked into the MavLink spec/docs to understand the valid ranges of sys_ids etc. and noticed the broadcast option.

There may be no responders at the moment for broadcast messages but if someone decides to add code for a broadcast message in future they'll be confused when it doesn't make it through.

[billbonney]

@seanmcleod I have create an issue (enhancement) to add the broadcast responding feature to MAVLink drone object in Tower.

#454

With the changes above, Tower is closer to supporting multiple drones and ones with a sys_id > 127.

Hope that helps 👍