Auto reconnect on connection loss?

Ground Control Software APM Planner 2.0
1

NOTE: I originally posted this in the other mission planner forum before realizing that it wasn’t for APM Planner V2.

I am using the APM planner V2.0.0.15 with a Pixhawk connected over a network link. Occasionally, the network connection will drop briefly for a split second, but this causes the connection to the APM Planner to be lost.

Is there any way to automatically reconnect after the heartbeat has been lost for some amount of time?

2

What type of network connection. I am assuming in a TCP one?

3

Yes, TCP.

Funny thing: UDP actually stays connected all the time, no need to tell the APM planner to even open the socket. As long as it’s configured, it will connect on startup. Obviously, part of this is due to the way UDP works, but even with serial you have to tell the APM planner to specifically open the port. I wish there was an option to emulate that behavior with TCP.

Basically, I am looking for a way to make the APM planner aggressively maintain the connection.

4

Without knowing the setup, it’s hard to offer specific advice. But here are some more general points.

  1. UDP is ‘connection less’ i.e. APM Planner is either getting packets, or not, you don’t need to connect.
    • The heartbeat indicator will show if heartbeat messages are being received and the link is ‘active’
  2. TCP is connection oriented at link layer. You are notified when a link is disconnected, and new connection needs to be established. If you have link that data can be intermittent, use UDP.
    • We can add ‘reconnect on connection lost’ logic to the layer, but then you get into issue of how often to retry (or retry forever) how long to delay between retrying etc… UDP solves this as it just listens for data.
  3. Use APM Planner 2.0 in TCP Server mode. This means that your autopilot connects to APM Planner 2.0. if it loses the connection, it can remake the connection (same as 2) just the autopilot is in control)
  4. when you use telemetry radios it is more analogous to UDP. This is because the connect button relates to the connection of the computer to the radio. it does not mean that data can flow between the two radio always. This means you can see the connect button as connected, but the heartbeat indicator showing red as no data is being received.

If you can use UDP, i would suggest setting up that as the link method. If not I can look at adding some retry logic to the TCP Link handler. This essentially means adding a state of connecting/retry connecting until the user abandons this clicking disconnect or cancel

5

Hey Bill,

Thanks for the comments. #3 was especially notable. I didn’t realize that you could set up the APM Planner that way. I suppose that would explain the server checkbox :slight_smile:

I think I do still need to be using TCP for this, primarily because of the way the device is being used. I’ll be hanging out in the Glitter channel and I can explain more.

UDP is nice in that it inherently works like a serial pipe, but the issue with it is that you have to specify connection details on either end point (IP/port). For me, that’s fine on the APM Planner side, but once I set it up, I have no good way of changing the target IP/port on the pixhawk/serial to Ethernet bridge. TCP is nice since I can just initiate a connection on the planner side and never worry about changing config on the rover side regardless of what IP the tlm data may be streamed to.

6

oh! I thought is did this but doesn;t seem to now…??
I would like MP to automatically connect to a UDP source once it starts.
I have written a MAVLink type proxy, but I still seem to have to hit connect to get it to start receiving UDP packets?
I was hopeing there was a command line switch to tell MP to auto connect to a COM port or UDP session on start up, but there doesnt appear to be a any command line start switches to do this.

Are you saying you have seen it auto connect on start up?