Android Emulator w 3DR servcies and Google API challenges

[hanno.bla...@gmail.com]

Hi all,

Love how Tower and 3DR Services are improving.

I have installed the latest Tower Git and am running the version on AVD Nexus 9, API 23 with Google Apis.

I am running MAVproxy and SITL

I am connecting via TCP and my IP on port 5760 to the virtual UAV.
BTW - I am unable to connect via UDP in the emulator (on APM planner UDP works fine) - this is separate issue

All good so far via TCP and all works fine via APM Planner 2.0. I can control the MAV and push pull data.

Problem: On the AVD Emulator I could not install 3DR Services via the google play store website, so I sideloaded the APK via terminal command.

Done that, I see the 3DR Services 1.5.04 app and it works fine on the Nexus 9 AVD.

HOWEVER: Whenever I try connecting to the sitl UAV, it connects and picks up all the data, but then spins and the voice goes 'GPS 3d lock', 'mode unknown' 'mode loiter' 'mode loiter' ' mode unknown' on and on and on. Occasionally I see the ARM and Dronie symbols, every 5th time it spins or so, when I attempt to click the ARM symbol I get a pop up 'Unfortunately 3dr services have stopped'.

What can I do to improve the stability and usability?

Thanks for help

[hanno.bla...@gmail.com]

I resolved it: Hopefully the following is of help for others:

a) Downgraded the JDK from 1.8 and linked the projects Tower and 3dr services in Android Studio to Java 1.7.079. As a result I was able to install the 3DR services app on the emulator and the services seem to be running in the background, however when I hit connect in tower, the app still goes into a loop

b) I disconnected Mavproxy and reconfigured as follows:
mavproxy.py --master=tcp:127.0.0.1:5763 --out=udpout:<local IP>:14550

c) I connected the AVD Nexus 9 emulator with TCP (your local IP and port 5760) and I connected mavproxy to see the command line simulation

d) This graph helps a lot: http://dev.ardupilot.com/wiki/sitl-simulator-software-in-the-loop/#running_sitl
and this:
http://dev.ardupilot.com/wiki/using-sitl-for-ardupilot-testing/

[Bill Bonney]

The issue is that either 3DR services or Tower is not filtering the messages based on system_id, so you are seeing message from both the mavproxy gcs and system under control. It needs a filter to reove the messages not intended for Tower.

By selecting the TCP port connection this essentially removes the unwanted mavlink messages.