Mavproxy commands last only 1 second

Hello! I am trying to send velocity X Y Z commands to my drone via MavProxy, but this commands only last for 1 second. Could you please help me to understand how to make these commands persistent?

It says here that the commands need to be sent every second. Are you sending them on a regular interval or just a single time?

Hello Asher,

Thanks a lot for your answer. What I am trying to do is flying the drone in a determined direction with a determined speed for some time. I am not sure If I am going to be able to do that using MavProxy, or maybe I will have to use Dronekit and write an script.

Well you can certainly do it in drone-kit, and admittedly I am not very familiar with mavproxy.

Do you have the copter in guided mode like this?
(Look at Guiding the vehicle section)

Yes, I launched Mavproxy through the telemetry (so I am not using a raspberry Pi) and I set the drone en guided mode, then you can arm the drone, and make it take off and hover at the desired altitude.

Once at the altitude, I set the desired yaw, till here everything is good. Then I try to fly In a straight line, nut it only works for a second.

What I will need to do is creating a script that will make me able to take of, climb to a desired altitude, then take the desired heading, and fly forward with a desired speed (v) for a (t) time, then take another heading and fly straight with a desired speed (v1) for a (t1) time, and so on…

Thanks for replying

Sounds like you know more about it than me at this point. Somehow, you’ll have to get mavproxy to keep resending that velocity message until you’ve reached where you need to be. I’m not sure how to do that in mavproxy though.

Maybe someone else can help. Best of luck!

Yes, lets see if someone could help.

Thanks again :slight_smile:


The velocity controllers’ timeout is 3 seconds (not 1 second) and this timeout is intentional to ensure that the companion computer is alive so that we don’t end up with flyaways due to a bad companion computer script. Could you modify the companion computer to keep resending the velocity requests? This would be the normal solution.

By the way, we are also working on adding this type of control to Lua scripts but it will still be a month or so before we add the takeoff and velocity controls.

1 Like

Thanks for your answer. I am trying to do it with a Dronekit Python script. But I had to change my approach. I cannot use GPS and the Guided_Nogps mode is not accepting altitude commands, nor taking off commands, only attitude commands, and I am scared that if I change the attitude and the drone tilts , it wont keep the altitude.

Is there any way to use the guided mode but with the GPS off?


Guided mode really needs a position estimate so either a GPS or some other position source is required (options are here on the wiki).

Guided_NoGPS doesn’t require a GPS but it also can’t do position control so I’m afraid the caller has to provide the attitude and “thrust”. In AP though we actually interpret that “thrust” field as a climb rate. So it will maintain it’s altitude.

Thanks a lot for your fast answer. This information is being really useful for me. I have a couple of questions:

Does guided_nogps mode has any command to take off and climb to a desired altitude and any other command for changing the altitude to a desired one later during the flight?

Is there any list with the commands that are available in each flight mode? I went in the documentation and I am studying it but I am a bit confused. I know that In guided mode I can send plenty of commands, and I know that In gided_nogps I can only send attitude commands. But what about all the other modes? Are the other modes accepting command or only guided and guide_nogps modes?

Thanks a lot!


The best info we have on this subject is here and I’m afraid it’s not very complete.

Guided_NoGPS doesn’t accept a target altitude. It could be enhanced to accept an altitude I suppose but that would leave the roll and pitch uncontrolled so it would certainly drift horizontally.

In general AP only accepts commands that affect the movement of the vehicle while in Guided mode. So it’s possible to affect servo outputs or trigger the camera to take a picture from any mode, but when it comes to moving the vehicle, only Guided mode (or Guided_NoGPS) will accept the commands. One other exception is Auto mode when it is executing a GUIDED_ENABLED command… this is rarely used and it is essentially Guided-within-Auto mode.

I understand, so I guess the only way I would have to send commands where I specify target altitude, target attitude, and target velocities (If possible) without GPS would be maybe creating a custom flight mode?

Maybe using Guided mode and faking the gps? (I know the aircraft will drift)


It won’t be possible to control the vehicle’s velocity without a real GPS. It’s important to understand that the IMUs on commonly used autopilot can provide acceleration but not to the level of quality that it can be accurately integrated into a velocity or position on it’s own. There’s simply too much drift. Without a real position (or velocity) source to counteract the drift the EKF’s velocity estimate will become many hundreds of kilometers per hour in less than a minute. Without a good velocity or position estimate it’s not possible to control a vehicle’s position or velocity.

It would be possible to allow controlling the vehicle’s altitude and attitude in Guided_NoGPS (but it would require a code enhancement).

Thanks again.

I am new in the development world, I do not really know how should I modify the code to enable altitude target in Guided_NoGps. Where could I find some guidance or help? My coding skills are a little bit limited for now. DO you think that would be possible for me to make these modifications by myself?