Yes APM Planner will connect but you’ll have to clean-up a load of junk it automatically adds:
-
Start APM Planner 2, go to the File menu and enable “Advanced Mode”.
-
New menus will appear. Click the “Communication” menu then, for each entry (connection) below the top “Add Link” option, click it. In the connection dialog, click “Disconnect” if connected (else it will show “Connect” then do nothing) then click “Delete Link”.
-
Check: Now you should have NO connections at all (a good starting point).
-
Click the “Communication → Add Link → TCP” then enter the port and IP address you started APM with (e.g. “sudo ArduCopter.elf -A tcp:192.168.1.2:5555”) then “Connect”.
It should connect. If not, you have to check a few things on the Linux side:
-
Did you supply the start-up parameters to match? There are three virtual serial (UART) ports in APM which are mapped to local (physical or pipe) or remote (network) ports of Navio via the “-A”, “-B” and “-C” parameters. Run “ArduCopter --help” for examples.
-
Be aware you really have to put the Navio’s own IP address in the command line parameter of APM, not the GCS/client address. You can’t use localhost or 127.0.0.1, it just doesn’t bind to any address (shame as that would be much easier to configure).
-
As an alternative to the complexity of #2 and also to support DHCP you can use UDP to broadcast to anyone on the same subnet (e.g. secure WiFi). Then you would use the “UDP Client” type of link in the APM Planner menu.For more information see: Broadcasting the output of the firmware in the network - #5 by CodeChief
I’m still experimenting with different combinations to find the ideal configuration for me. Some people report permanent disconnections when using direct IP addresses with APM when interference occurs (e.g. mobile network reconnect).
That could also be an APM limitation (bug in my opinion) so let’s hope it gets an improvement soon. We should just be able to start APM with “-A tcp:127.0.0.1:5555” then get it it via any address which is currently working, even after reconnects and USB plug-and-play.
In the meantime I think broadcasting general information is a good idea for ease of use and flexibility (DHCP and mesh networks), so you can tune-in multiple devices like you do with FPV monitors. But if you have no RC transmitter/receiver in your build, you really should choose TCP for the main (joystick) RC input unless there is a specific network limitation preventing you from achieving that.