MoveByEnd callback not working properly


Hi all,

I’ve been trying to work with my Bebop drone to do a simple task: Move by a sequence of relative vectors. We’ve been having trouble with the callback—it seems to be called inconsistently. In essence, the design flow is that a moveByRelative command is called, and another one is called in its callback. Below is the relevant code (pastebin for formatting):


Some information about what happens:

Without the moveCommands in the callback
The first moveCommands is called successfully (after the take off state is changed to flying).

We noticed it is necessary to put a dummy relative move first (0,0,0,0). Then, the callback occurs after inputting the moveCommands, but the dx, dy, dz, dpsi do not match what we input. If, however, the drone is told to land, then the callback is called, and dx, dy, dz, dpsi match.

With the moveCommands in the callback
Because the callback is called with seemingly random dx, dy, dz, dpsi, moveCommands is called hundreds of times.

We’d love help on this, because it really seems like this should be working—but the API seems to be holding us back. We have a work around at the moment, but it’s a bit messy to work with.

Product: Bebop Drone
Product version: HW_11
SDK version: 3.3.0
Use of libARController: YES
SDK platform: Unix
Reproductible with the official app: N/A


I piddled with the move relative commands a bit and was unsuccessful as well. What is your workaround? I’m interested in this question as well.



these posts might help you:

Tell me if you still have problems after reading and applying these pieces of advice.



you can also use the FLYINGSTATECHANGED callback to trigger the new “sendPilotingMoveBy” command. If you check how the state changes during the flight, you’ll notice that you have, in sequence, (1) takingoff, (2) hovering, (3) flying, (4) hovering, …, (n-3) flying, (n-2) hovering, (n-1) landing, (n) landed.
You can send the moveBy command when the state changes from flying to hovering, and use the PILOTINGEVENT_MOVEBYEND just for the dead-reckoning. I am using this strategy and it seems to be working very well… but unfortunately you won’t get rid of the drift, or at least I couldn’t.



Could you please explain how do you do this (add your piece of code)?



Hi @b.spring,
I cannot post the entire code because I developed it for the company I work for, but I will try to write down the main chunks of code. Please let me know if they’re clear enough. :wink:

  1. Register the callback:

    error = ARCONTROLLER_Device_AddCommandReceivedCallback (deviceController, commandReceived, […]);

  2. in the function “commandReceived”,

    switch (commandKey)
    onFlyingStateChanged(elementDictionary, […]);

  3. in the function “_onFlyingStateChanged_”, get the state, then

    switch (state)


Thanks for your help dear elBarto
If I have question, I will ask you.


Dear @elBarto

Ok. I did this, but I have a problem. In onFlyingStateChanged there is same cases:

switch (state){

                deviceController->aRDrone3->sendPilotingMoveBy(deviceController->aRDrone3, 1, 0, 0, 0);

when robot move forward 1 meter, I should check the state again, if it is hover, I want to add another sendPilotingMoveBy (0, -1, 0, 0), then I should check hover again to land, but I cannot have duplicate case valve. What is the solution?
You said in sequence, how?


Hi @b.spring,
you don’t have to check the state because state transitions automatically trigger the FLYINGSTATECHANGED callback.
Then, instead of the sending the “sendPilotingMoveBy (0, -1, 0, 0)” command, you can call a function, where you can do your own computations before and the MoveBy command.
For example, you could use a vector to store the all the displacements that your drone should do, and use a static index to move from one displacement to the next


I haven’t been following this too much, and we abandoned automated flight for the most part, but you can see a semi working example here


@asakaplan, @elBarto

I really appreciate it.