MAVSDK
MAVSDK copied to clipboard
mavlink
Adding disconnect button to kill/disconnect to any port or kill not used variables.
I saw that QgroundControl has disconnect button to kill all the connections to a drone in a port. There should be a way to do it in, using MAVSDK, that keeps the code running but just disconnect specifics ports.
When handling connections with multiple drones, it would be good to have a way to disconnect to a drone and kill all unused variables, just for a specific connection to a drone. But mavsdk can still be running accepting other connections. Just like Qgc does it.
@JonasVautherin I can work on that, unless anybody else is working on that. I will need to make research on how mavsdk handle the connections and the auto-discover.
Awesome!
To give you some context, that is done in the Mavsdk classes (mavsdk.h/cpp, mavsdk_impl.h/cpp). Mavsdk opens a connection and then listens for heartbeats. Whenever it receives new heartbeats, it checks if it already knows the sysid or not. If it doesn't, it creates a new System for that new sysid.
I guess that you don't want to destroy a System if its connection disappears, because a System can be present over multiple connections (multipath). So those are two different things: if a System is disconnected for too long, maybe it should be removed (but maybe we don't care because we never have so many systems anyway). But in your case I believe you want a way to remove the connection, independently from the system (heartbeat stuff) logic.
Let us know how it goes :slightly_smiling_face:.
I have been reading the documentation, but I am not sure how the connections are store in system and I am sure I can delete them.
Yeah preferably you'd have to look directly into the code for that :see_no_evil:
My idea is this : I get this now so basically there is a vector called std::vector<std::shared_ptr<Connection>> _connections{};
My idea is to keep a track of the connection for example:
using a map < std::string , std::shared_ptr<Connection> > _connections
udp://0.0.0.0:14550 map to their respective connection. So basically I know I can address any element from the map, and delete it if I want to disconnect.
please let me know how to contribute or anything else I need to know if I wanna do this.
@Macf41 contributions would be very welcome!
So the first thing that we have to think through, in my eyes, is what the API would look like. So, what would the interface be to tell MAVSDK to "remove" a connection? That part is not clear to me just yet.
Basically I was thinking something in the way of remove_connection(string url){} the url would be something like udp://0.0.0.0:14540 if serial would be like /dev/ttyS0:57600 or remove_connection(string type, string url) type is either udp or tcp or serial
Also there is still the issue with the system being created, so it would need to be deleted first or cleared. But developers have access to the system variable so they can cleared it. they can reset the pointer to clear it using the reset function for pointers or just delete the pointer.
Deleting/clearing systems is tricky because it involves the plugins being deleted first. Or plugins would only be given a weak_ptr to their system, and before doing anything, they would always have to check if the system is still there with weak_ptr->lock(). That's a bit of an overhead that I was trying to avoid so far.
I guess it is right, my biggest concern with that is that we have to keep a map of all the connections So url - > connection pointer - > system I was thinking more in the way user is in charge of deleting the system. There should be another function to delete plugins, I don't know if system has a destructor function.
But certainly, I don't know how to check what plugins were created so I can delete them automatically. I just was thinking of writing an implementation where we first delete plugins, then the system pointer. Check for
system->unique first to see if we can reset/delete the pointer.
And after that we are able to delete the connection.
Either that or we can exposed connections vector so developers can delete any connection they don't need.
Either that or we can exposed connections vector so developers can delete any connection they don't need.
Yes, that should be more doable.
If we are exposing the vector I was thinking of adding a map from url to connection, cause developers will not have a way of knowing which pointer belongs to what connection. Just changing the variable _connections from a vector to a map <string, shared_ptr>