Servers by jDrones

Follow-me arducopter

(Luís Vale Gonçalves) #9

Being logical, is that Tower last commit is from Nov17 (dev branch), and requires some heavy refactoring, and unfortunately the lead dev has no spare time to do it.

(Paul Atkin) #10

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?

I can't succes follow-me mode with TOWER App
(peterbarker) #11

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

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

(Paul Atkin) #12

I should have a log sample, will send link later today.

(Paul Atkin) #13

here is a log with a sample.

‘land’ and ‘brake’ commands were accepted. on the ‘follow me’ with attempts to use 2 different modes - ‘leash’ and ‘above’ - there was no reaction. it was sitting in the same spot in pos hold mode.

(peterbarker) #14

Paul_Atkin1 Paul Atkin
August 1

here is a log with a sample.

Sadly, that’s a dataflash log. Usually they’re superior to tlogs for
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.

¡land¢ and ¡brake¢ commands were accepted. on the ¡follow me¢ with attempts to use 2 different modes - ¡leash¢ and ¡above¢ - there was no reaction. it was
sitting in the same spot in pos hold mode.

Yep, I can see that much in the log you supplied.

(Paul Atkin) #15

i will try to get laptop out later this week to try to catch tlog, or may be somebody else would be able to provide a sample… thx anyway!

(Andrea Belloni) #16

Also Tower Beta saves tlog, in my phone under “Android\data\\files\tlogs”

(Paul Atkin) #17

if you could provide a log from current 3.6 rc7 it would be great - i cannot get to it neither today no most likely tomorrow…

(rmackay9) #18

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.

(Andrea Belloni) #19

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.

(Andrea Belloni) #20

@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.


(rmackay9) #21

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.

( .) #22

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.

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.

(kellyschrock) #23

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. :slight_smile:

(Larry A Amati) #24

Will the SOLEX app work on TAROT hex with arducopter 3.6?

(Andrea Belloni) #25

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)?

(rmackay9) #26


I’m not sure… I’ve never done any development on Tower I’m afraid… I’ll bring it up with the other developers on the weekly meeting and I guess we will see if we can find someone to fix it.

Dev Call Aug 13, 2018 2300 UTC
(zhangpeng) #27

Since the follow-up of the AC3.6rcX version of the firmware, my Tradheli test followed me mode and never succeeded. I look forward to the Tower update to fix this long-standing problem.

(Luís Vale Gonçalves) #28

This topic has been discussed on the dev call.

If there are candidates here to go and debug the current issues on Tower would be great.