David Lechner

> So you need a way to connect all 3 components together, right? This isn't really the problem. The problem is that `mavsdk_server` only allows communicating with one other system...

Does https://github.com/mavlink/MAVSDK/issues/1633#issuecomment-978081589 seem reasonable? I haven't thought of any major shortcomings with that idea yet.

I suppose another option would be to do https://github.com/mavlink/MAVSDK/issues/1618#issuecomment-970334161 for Python as well - create a new set of Python bindings that doesn't use `mavlnik_server`/gRPC but rather uses the C++...

Related issue: https://github.com/mavlink/MAVSDK/issues/1700

> If you have a better word than "manager", let me know ;) All of the existing plugins that implement such features are called `xyz_server`.

I don't think we want to merge it as-is, but rather reuse the ideas on top of the new changes. Don't we want a MAVSDK-Proto API for this too?

I considered something like this as well. There would also have to be an additional method to add systems that were discovered after the plugin was created (or only this...

Yes that is the idea. If we want one MAVSDK instance to do _everything_ (multiple components on the MAVSDK system), it might look more like this.  [link](https://edotor.net/?engine=dot?engine=dot#graph%20%7B%0A%20%20%20%20MAVSDK%20--%20%22System%201%22%0A%20%20%20%20MAVSDK%20--%20%22System%202%22%3B%0A%20%20%20%20%22System%201%22%20--%20%22Action%201%22%0A%20%20%20%20%22System%201%22%20--%20%22Telemetry%201%22%0A%20%20%20%20%22System%202%22%20--%20%22Action%202%22%0A%20%20%20%20%22System%202%22%20--%20%22Telemetry%202%22%0A%20%20%20%20MAVSDK%20--%20%22Component%201%22%0A%20%20%20%20%22Component%201%22%20--%20%22Camera%20server%22%0A%20%20%20%20MAVSDK%20--%20%22Component%202%22%0A%20%20%20%20%22Component%202%22%20--%20%22Action%20server%22%0A%20%20%20%20%22Component%202%22%20--%20%22Param%20server%22%0A%7D)

Why not just use the `struct` module for unpacking binary data? ```python import struct struct.unpack_from('

As far as I know, sensor values should always be treated as signed. https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#value-format This doesn't say it explicitly, but I know from extensive experience with the EV3 source code...