Home        Store        Learn        Blog

Python script, manual mode: thrusters return to neutral after a few seconds

In a python script I’m using pymavlink to send an rc_channels_override_send command in manual mode to simply pitch up. The command works fine, however the motors return to zero thrust after a few seconds unless I repeatedly send the command in a while loop.

Can I change this behavior so that I can send the pitch up command just once and leave it in the pitch up state, or do I always have to loop over the rc_channels_override_send command in a loop?

I have thoroughly searched the ardupilot parameters and firmware source code but cannot find where the motors are being set to neutral after a few seconds of no rc commands.

Thanks for any help!

Hi @TMJ,

This is expected behaviour, ArduSub includes a Pilot Input failsafe which by default disarms the vehicle if it hasn’t received a new control input within the last 3 seconds. It’s possible to disable the failsafe by setting FS_PILOT_INPUT to 0, but the recommended approach is to send regular control inputs just as you should be sending regular heartbeat messages. There’s an example here of periodic events, which may be useful :slight_smile:

Thanks Eliot. This is valuable information. I am in SITL mode and am experimenting with some autonomous recovery behaviors when the companion computer experiences loss of control. Therefore I need to disable the neutral motors directive.

So I’ve tried setting all FS params to zero including FS_PILOT_INPUT to zero. However, it still goes to neutral after a few seconds.

Can you think of where else in the ardupilot code that this could be happening? I’ve put some printf statements in ArduSub/failsafe.cpp but it doesn’t appear to ever reach the set_neutral_controls() on line 195.

Hmm, odd. Have you confirmed that those parameters have been set as you expected, and did you restart the autopilot after setting them?

That’s unfortunately outside my experience. I’ve passed it on to our software team in case they have some insight :slight_smile:

→ Have a look at the RC_OVERRIDE_TIME parameter :slight_smile:

Hi Tim,

Would you mind posting your code please? I am also interested in doing something similar but all my attempts at running pymavlink scripts without losing the connection to QGC have been unsuccessful so far.

Thank you!

@monsterbacke are you referring to this issue:

Pymavlink and QGC generally aren’t expected to be running at the same time. If you do need to run them together you’ll need to set up an additional endpoint, as discussed/covered further down in that post :slight_smile:

If that’s not the problem then feel free to make a post about the issue you’re having and I can try to help sort it out :slight_smile:

YESSSSSSS! Thank you sir!


1 Like

Thanks @EliotBR :slight_smile:
Yeah, I do suspect it to be a port issue, but I put that topic on hold for the last few months and worked on other things that seemed easier to solve :sweat_smile: If I remember correctly, I did tell pymavlink to use port 14558 and it still didn’t work, so I stopped investigating and went down a different route.
I’ll probably pick it back up in the new year though and open a new topic then :wink:

The default port is 14550, and that’s only expected to work if QGC isn’t open at the same time - not sure if 14558 was a typo.

Fair enough, see how you go :slight_smile: