As DroneCore supports multiple connection interfaces TCP, UDP & Serial, we need to allow user to select either of them while launching the application.
Examples of connection URL could be:
udp://[bind_host][:port]tcp://[server_host][:port]/path/to/serial/device[:baudrate]For.eg below conn URL _binds to UDP port 14500_
$ ./takeoff_land udp://:14500
binds to default UDP port 14540
$ ./takeoff_land
Connects to TCP Server (192.168.8.2:5760) hosted by MAVLink Router on Intel Aero
$ ./takeoff_land tcp://192.168.8.2:5760
etc.
I agree that this would be handy, however, what you add here are cli args to the examples and not to the core library, so this means you'd have to add it one by one to each example.
We'll have to think about this again after the gRPC refactor, I think.
@julianoes Agree.
In case of gRPC it can be handled at single place dronecore_server. We can have one config file to load and connect to any number of vehicles which are listed in config file.
client (applications) just need to query for active vehicles.
How about this ?
udp://:14540)int main(int argc, char **argv)
{
DroneCore dc;
DroneCore::ConnectionResult connection_result;
if (argc == 1)
connection_result = dc.add_connection(); // default UDP connection at port 14540
else if (argc == 2)
connection_result = dc.add_connection(argv[1]); // connection URL of user's preference
...
This removes all overhead from apps whether to call add_udp_connection() or add_tcp_connection(), etc.
That's a good idea.
What about calling it dc.add_any_connection(argv[1])?
Yeah. I think to keep simple and effective:
conn_res = dc.connect(argv[1]);
and
DroneCore::connect(const std::string &connection_url);
Where connection_url could be any of the below:
But it's not connect, it's adding a connection. Because you can add several connections and then it will connect once a vehicle appears.
Right. But its connect in case of TCP, because, we get connected to TCP server.
To be consistent, we can keep either of dc.add_any_connection(argv[1]) or dc.add_connection(argv[1]).
I vote any.
Addressed in #264 .
Most helpful comment
I vote
any.