Hi,
I know that Tower app is de-facto abandoned, but, could anybody confirm if there is any way to make it work on a Pixel 2 phone with Android 9 on it?
So far any attempt to connect to a vehicle via UDP causes an immediate app crash. I can connect using same tower beta app from old Samsung S7 with no issues, as it is running an older Android. Is there anything that can be done to fix/resolve this?
Have you tried QGroundControl? It has a nice interface, is being actively developed, and runs on anything. I use it on all my Android devices.
yes, but unfortunately i am unable to troubleshoot its quirks, as QG app often hangs in the state ‘waiting for connection’ when i have wi-fi connection established and having tower app and MP connecting to the model with no issues from other device or PC.
i noted when QG goes into such state it seems to be sitting in it constantly and the way how QG app is done it not really allowing to understand what is the issue. it may be that it wants mavlink 2 to be the protocol on the wi-fi link, pehaps, but before i start un-soldering and re-flashing all esp8266 cards i have with firmware for mavlink 2 i would really want to see if i could make tower app to work.
also, even if QG connects to the model - the android version of it throws an error saying that model ‘did not respond’ on the request to ‘retrieve parameters’. i see no way in that app to alter a parameter i want neither, that pretty much renders QG useless for me.
the PC version of QG is not doing it - it connects almost always and shows no errors. it is way too much for me in there to deal with - i do not have stamina nor time to decipher what is it QG expects and what it does not get, considering that rest of data seems to flow fine into it, it shows voltage, sats, etc. just does not work reliably and connects only when some unknown stars do align in a certain way.
Try the QGC daily build. The WiFi connection issues have been fixed in it. Mavlink2 does not matter. And fetching the params when you have a unreliable WiFi link will always return the error that it can’t get all the params
https://docs.qgroundcontrol.com/en/releases/daily_builds.html
I run QGC on Android and Linux using UDP all the time, with no problems. Including connecting to SITL running on my Linux dev machine, with the tablet over the network using QGC.
Since WiFi is 2.4 GHz, same frequency as most RC radios, the WiFi connection can be unreliable due to interference from the RC or nearby WiFi routers. Unlike Tower, QGC will refuse to display an incomplete parameter list because using an incomplete list can brick your settings.
On Android you can get the daily build direct from Google Play. If you are using ArduPilot stable firmware you do not need the daily build - just get the latest stable QGC. If you are running ArduPilot beta software, then you need the daily build because the params are totally different between the stable and beta firmware.
ok, not sure what it is - i got daily build installed. it prints this: 'vehicle 1 did not respond to request for paramters. this will cause… '.
wifi is very stable and works fine. phone is 2ft away from esp card. PC is 15ft away and has perfect stable non-affected link.
what is this ‘request for parameters’?
how can i see what parameters were given? vehicle setup summary screen is empty. says ‘vehicle settings and info will display after connecting to your vehicle’. i am connected.
and i have same scenario now. i close QGC - then disconnected from the wifi. reconnected to wifi. restarted QGC. it waited for the sweet time with no responses - a good time - saying no vehicle connection - and now somehow the summary screen opened up with stuff in it.
i do not get it what is it driven by, this behavior. and, i feel, as i am on custom ‘3.7.0-dev’ build - it does not seem to like it neither. some options are different there.
i disconnected and reconnected again. comm links section was empty and still is - now it does not reconnect anymore. just shows me ‘waiting for vehicle connection’. there is no button to press to force it reconnect…
ok, all in all - it is same exact BS. worked once, then did not, then worked more or less and now 5 times in the row refuses to connect completely, in all combinations - start app before wi-fi, then connect to wifi; or kill all, ap stopped, wifi stopped, start drone, connect to wifi, then start app - that is where it worked fine first time - so now it does not connect, or while wifi on and app on quickly bounce drone power for phone to stay on wifi - nothing works, QGC stays in the ‘waiting for connection’ mode.
it is not workable.
as i killed it for last time - QGC app on the phone, i started old Tower to check - got connected immediately with no issues. it is not usable.
OK, well the reason is because on an Android device only one app at a time can use a connection on port 14550. When you close Tower it doesn’t actually stop. So it still has the connection tied up. So QGC can’t connect. Get rid of Tower by force stopping it, uninstalling it, then QGC will work.
QGC shuts down the connection cleanly when you close the program. Tower doesn’t because the legacy “3DR Services” (or whatever it was renamed to) still is running in the background.
the Tower app is on the other phone, not on the one with QGC…
do i need or do i not need to make an entry for UDP port in the comm links screen? it is confusing as it connected fine first time with comm links empty.
double checked - 3dr services are not installed on the new phone.
Look in the configured connection links under the “Q” and see if the UDP Link on port 14550 shows trying to connect (the connect will be greyed out). If it is, something else has the port tied up and it can’t use it.
If you don’t have a UDP link defined, define one and check the box that says “connect automatically”. This is from my 14" tablet, but still the same despite the bigger screen:
ok, it is some random BS. i just went, killed the app onthe phone - did a ‘force stop’. repowered model, reconnected to wifi - started QGC - it got connected and sucked in all params, rather quick.
stopped it, restarted it - connected again. repeated 3 times. i need to work now, so, will see next time on the field if it will keep working and will keep this BS going on. it wold be easier to have a forced button to do a reconnect and see an exact response code if it refuses - the way it is now it is impossible to figure out what is wrong. one time it works, then does not, then works again - it is total BS.
the whole section under comm links is blank now. there is nothing in there. yet somehow it connects.
beats me.
QGC is supposed to be automatic and not use a connect at all. Using a MavLink radio, simply plug the radio in, QGC starts automatic and connects.
It is the same with UDP, but it doesn’t hurt to define a link to force it to “listen” on port 14550 in case some other app is using the port or has it tied up. That way you can look at the Comm Links page and see if it tried to connect, but couldn’t.
I used Tower for quite awhile but finally gave up on it. Been using QGC for over a year now and it “just works”. When around WiFi routers sometimes the tablet will connect to the WiFi router instead of the link from the vehicle. And then QGC can’t connect. Have to keep an eye on that too.
yep, i hear you. and, thanks so much for your help - it makes more sense to me now, and i will try to setup connection to see what is the issue.
it is what it is, in the end - Tower is in fact abandoned, and, QGC is the new one to use. i will try to sort out what the issue is with connection. but, it seems, after i did a force stop it acted ok. may be it is what i need to do in the future if it refuses to connect. will see.
I think you will like QGC for flight planning too. It doesn’t have finger draw like Tower. But clicking or touching for the waypoints is more accurate anyway, as my finger draw skills aren’t all that good.
QGC really shines on a 13-14" tablet with a hardware keyboard and touchpad for a mouse pointer. I have a tablet with built-in 4G cellular and GPS in it. It’s awesome in the field compared to lugging a laptop around.
If only QGC supported my Solos more cleanly, especially the RTSP video stream, I would switch in a heart-beat from Tower Beta.
If I’m not mistaken Tower was originally written for the Solo. But if you make a feature request on GitHub it is possible it could be implemented.
Tower has not seen any active development and version updates in over 2 years. I would not anticipate anything happening with it in and foreseeable future unless someone steps up to volunteer their time developing it further.
Tower was not written for the Solo. It was made long before the Solo existed, as traditional android mobile GCS. The app was formerly known as Droid Planner and began circa 2013. The name was changed to Tower in late 2014ish. The Solo has its own apps designed around it and it’s companion computer functionality.
As far as I remember both Solo and Tower came out about the same time in 2015. The Solo App didn’t have any sort of flight planning in it. So 3DR repurposed Droidplanner as Tower specifically for the Solo. And that is why it has some features specific to the Solo.
Of course, everybody else used it too, because it runs on the most popular mobile platform there is. And then development for it sort of ground to a halt when 3DR abandoned it.
It’s still a pretty good app. But no longer suitable for Copter 3.6 in it’s present state of development. There was a commit on it almost a year ago now, but nothing since.
