i understand your point of view, but, what i think is also logical is the fact that it was a lot of time since Nov 17, and 3.5.5 worked fine, and now 3.6 rc does not - and tower is unlikely to be changed as author does not care - so - is there anything that can be done in 3.6 to make it talk to the tower like 3.5.5 did? and 3.4 did? and 3.3, etc?

My understanding is that Tower was using guided-position-control to move
the vehicle around as a “follow” mode.

Yes, we have something better now, but Tower will not currently support
it.

However, the old functionality should definitely not have broken.
Legitimate reasons for it breaking may include additional safety
precautions which Tower isn’t aware of - I can’t think of anything along
those lines, however.

If you can get us a short telemetry log showing the problem that may help
diagnose. Note that we have regression tests for this functionality (on
the master branch) - so it is working in some way, shape or form on
master.

Yes, we should try and get to the bottom of this. I can’t immediately think of a reason why it would have stopped working. There was that issue with Tower specifying absolute altitudes instead of relative…

The Solex app is a decent alternative to Tower because it is maintained but it’s not open source nor free.

QGC also runs on tablets I hear although I don’t know if it has “follow” as a feature.

Hi, I tested Copter 3.6 (master 81b1270) on omnibusf4pro using Tower Beta on my Android phone as GCS and I tried to do follow me with same results as described by @Paul_Atkin1
I attach the tlog file, near 42% there are some tentative to switch in follow me mode.

In the tlog there is another strange behavior: till near 35% there is a big value of compass variance error, then this value goes low and remain so till the end but without any intervention by me. In the phase with low compass variance I obtain a really good Loiter. I understand that this thing is OT, I have to do some other test and maybe report the results in another thread.

analysis - but not in this case, as I need to see the commands going from

the GCS to the autopilot - and that’s in the tlog.

@peterbarker in my previous post I attached a tlog from Tower Beta where I try to switch to follow me mode without success, can you analyse that tlog to see if there are info to understand the issue in this thread? Or maybe you can explain me what I have to search in the tlog.

One theory that we’ve had about Tower not working is we’ve changed the VFR_HUD mavlink message to (correctly) report the altitude as height above sea-level. We suspect that Tower was built around the incorrect value and this is the cause of the troubles. We need to verify this but it’s the leading theory. Once it’s verified then we can try and figure out how to fix it… fixing Tower would be best although it’s unclear if we can find any developers to take this on.

The is actually another underlying problem. Tower actually stopped doing Follow-me quite a while back.

@kellyschrock had to update the dronekit-android code to account for new changes that were made in the Android’s underlying GPS-precision data. Solex Follow-me had stopped working as well. I believe it had something to do with Android not providing an accurate enough position to a 3rd party tool, so he ended up, against his best judgement, changing the variable for accuracy so that it would allow follow-me mode in slightly less accurate conditions.

I started trying to take those changes and incorporate them into dronekit-android, but my PRs never even got looked at…also…I’m kinda dumb at programming. (Not blaming Bill I know the app isn’t top priority) Regardless, the underlying dronekit-android framework is where the follow-me is broken, and since noone is maintaining either dronekit-android or Tower at this time, it will remain broken. https://github.com/dronekit/dronekit-android/pull/485

I’m not sure on the claims that follow-me was working pre-RC3.6, because it certainly wasn’t for me. Around February, it was all still working (Tower and Solex), but it stopped around that time and kelly made a mention on his Facebook page of why it wasn’t working and how he fixed it.

The offending code:

private static final float LOCATION_ACCURACY_THRESHOLD = 10.0f;

My idea was to first modify dronekit-android to make this setable (is that a word?) by the connected app, then modify Tower to send it’s required accuracy for follow-me mode.

My justification here is that a Rover might not require as high of a threshold, so the app developer using dronekit could set the accuracy based on the requirements.

What you’re doing there is basically what I did, but I didn’t provide a means for a client to set an accuracy threshold. My previous accuracy threshold was 10 if memory serves, and I bumped it to 15 based on what I observed coming from the Android device’s GPS.

FWIW, Rover benefits from as much accuracy as possible with locations, at least for the things I mess with. 3 or 4-meter accuracy on a copter is generally pretty good for a copter. But since a Rover operates in close quarters next to bushes, people, houses, pets, etc. it’s actually much more likely to run into things than any of my copters if the location isn’t sufficiently accurate. The low speed and absence of spinning blades makes a collision less of an event, but that’s only until I attach a mower deck to my rover.

Randy
I noticed this, now Tower display altitude above sea-level where normally I saw the relative altitude and where, I think, should be relative altitude.
I don’t remember precisely when but some month ago I used Tower as GCS and I saw relative altitude displayed.
It is annoying to not know the relative alt when you fly.
Do you think it is feasible to correct this relative alt problem independently from the follow me problem (that I think is more difficult to solve)?