Troubleshooting follow_me.py

[imthedronelord]

Hi Kevin,

Our team was able to run the follow_me.py example without debugging errors in two different ways. The first way we ran it, was exactly as the follow_me.py was written, and the second way was hardcoding one GPS coordinate in the Location function. However, in both cases we received the proper debugging output but the motors did not move.

The first way we ran it, was exactly as the follow_me.py was written. Our GPS USB dongle was providing GPS coordinates every two seconds, those coordinates were displayed, and the output showed “Got MAVLink msg: MISSION_ACK... etc.

The second way we ran it was with all the gpsd functions commented out and by hard-coding one GPS coordinate in the Location function.

After educating ourselves on your API, we believe that we have narrowed down the problem to being the goto function does not end up forcing the drone to move the motors.

Do you have any thoughts on why this could be happening.

We speculate that the problem may be that the drone is going into Guided mode. We believe that this is your intent. However, from our understanding, the drone will only go to locations autonomously in AUTO mode and only after the waypoints are saved and an rc command starts the motors.

Again, we do not fully understand what is wrong and why the command itself seems to be received by the APM, but the motors are not moving.

Again, we are able to get small_demo.py to move the motors properly, so we know it is not a problem with our wiring or our connection between the APM and our Raspberry Pi.

Any help is appreciated,

Thanks!

[geeksville]

oh yes - here's some likely theories:

• For safety the default behavior for the code is that guided mode (used for follow me) will not cause the copter to take off. You need to launch the vehicle using either an RC or the rc_overrides to fake lifting the throttle from 0. (The latest master - soon to be released arducopter build makes this protection optional if you you send takeoff waypoints)
• If you are using a px4 you'll also need to press the safety button at least once after boot so the LED stops blinking.
• Have you tried just launching the vehicle (say in LOITER) to confirm all is well? If the vehicle is flying already in any mode, the follow me should work well.

[imthedronelord]

You were right! Arm and channel override ran it!

Curious enough after attempting to takeoff/goto set GPS location, it quickly entered mode LAND and quit the program. Why is this? Is this a failsafe mode feature?

Also, any updates on changing vehicle mode fix?

[geeksville]

Re: vehicle mode fix
Hmm - I looked at the code and realized (I thought) it was fine.

Re: entering landing mode
Do you have a conventional rc xmitter? If not, I bet the land mode is due
to RC failsafe for loss ofr RC signal - you can turn this off by setting a
param (if you can't find the param, let me know and I'll grep the src when
I get to work)

On Sat, Aug 16, 2014 at 8:19 PM, Eric Smalls notifications@github.com
wrote:

so it was needing to arm and channel override!

Curious enough after attempting to takeoff/goto set GPS location, it
quickly entered mode LAND and quit the program. Why is this? Is this a
failsafe mode feature?

Also, any updates on changing vehicle mode fix?

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[imthedronelord]

re: mode fix
You are correct! The mavproxy module for mode mapping got messed up on our Pi so we reinstalled everything and now Droneapi examples (1) small demo and (2) follow me both work. It also explains why we got mixed results on Ubuntu. Thank you!

re: rc failsafe
I think we would set it similar to how it's done in the Pi<>Mavlink tutorial for arming using 'param set...' in Mavproxy [1, 2]. For example,

'param set ARMING_CHECK 0'

So I think:

'param set THR_FAILSAFE 0'

Should work for disabling rc failsafe in mavproxy [3].

(Away from drone)

What do you think?

Sources:
[1] http://dev.ardupilot.com/wiki/raspberry-pi-via-mavlink/
[2] http://tridge.github.io/MAVProxy/parameters.html
[3] http://dev.ardupilot.com/wiki/mavlink-parameters/

[imthedronelord]

re: setting parameters
I'm curious how to set parameters on Droneapi. I think v.parameters('THR_FAILSAFE', 0) would work [1, 2, 3]. Away from drone, thoughts? I'll be able to run tests soon.

Sources
[1] https://github.com/diydrones/droneapi-python/blob/a16181576f521e2b202a963740417a1be2f0fd73/droneapi/module/api.py

[2] https://github.com/diydrones/droneapi-python/blob/7e792e186929429ea5bb3810c72b2136135cb156/example/small_demo.py

[3] https://github.com/diydrones/droneapi-python/blob/a16181576f521e2b202a963740417a1be2f0fd73/droneapi/lib/__init__.py

[imthedronelord]

re: disabling rc failsafe
I tested 'param set THR_FAILSAFE 0' in mavproxy and there was no parameter found so I ran 'param show' and found 'FS_THR_ENABLE'.

After researching this parameter online, I set 'param set FS_THR_ENABLE 2' and successfully ran small demo.py without automatically going into mode Land [1].

Sources:
[1] https://code.google.com/p/arducopter/wiki/AC2_Failsafe

[imthedronelord]

re: disabling rc failsafe
So it turns out we weren't successfully starting a mission [1]. After refreshing our memory and starting a mission by (1) loading waypoints, (2) arming, (3) setting mode to AUTO, and (4) throttling rc, we immediately entered mode RTL [2].

This led us to believe, 'param set FS_THR_ENABLE 2' was not disabling rc failsafe. We next tried 'param set FS_THR_ENABLE 0' which successfully kept us in mode AUTO.

It should be noted that a simple google search of FS_THR_ENABLE leads one to '2' not '0' as a correct input [3].

Sources:
[1] http://copter.ardupilot.com/wiki/auto-mode/
[2] https://code.google.com/p/arducopter/wiki/AC2_Failsafe
[3] http://wiki.ardupilot-mega.googlecode.com/git/images/Failsafe/MPFSThrottleParams.png

[imthedronelord]

After testing a few times it looks like this explains why we have had mixed results with 0 & 2.

We are still having trouble reliably staying in AUTO mode. What are your thoughts?

Sources:
[1] http://copter.ardupilot.com/wiki/arducopter-parameters/#Throttle_Failsafe_Enable_ArduCopterFS_THR_ENABLE

[imthedronelord]

re: AUTO mode
Issue solved.

[geeksville]

Great! Sorry - I was away a few days, I assume you are all good now?

On Fri, Aug 29, 2014 at 12:12 PM, Eric Smalls notifications@github.com
wrote:

re: AUTO mode
Issue solved.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[mrpollo]

If this isn't yet resolved lets create a new issue to troubleshoot

[tcr3dr]

Since this may not have gotten rolled back into any documentation, this is what I'm using for some SITL tests:

param set FS_THR_ENABLE 0
param set FS_GCS_ENABLE 0
param set ARMING_CHECK 0

Which seemed to be successful. I can imagine scenarios where a DISARMING MOTORS trigger would still occur, but have nothing that causes that effect so far.

[hamishwillee]

@tcr3dr Setting ARMING_CHECK 0 is a big no no for real code. Might be worth adding a note in the test code to make it clear that this isn't something to do normally (since some people might copy it).