moveBy command error on Bebop 2


I just implemented the ardrone3.Piloting.moveBy command into pyparrot and I’m seeing some strange/dangerous behaviors. When I test dx, dy, and dPsi individually, they are fine. When I test dz positive (e.g. down), it is fine. But dz negative (e.g. going up) is reliably doing FAST and scary (I’m indoors!) lateral movements. I’d send a movie but I don’t particularly have a desire to run that one again (though it did do it 3 times in separate tests). Help? I’m very cautiously releasing it into the pyparrot library only because we really need the command for rotation but I’m worried about others seeing this behavior and crashing their drones. I’d really like to know what is happening. Thanks!


Update: this is happening on ALL of the dx, dy, dz, dPsi, It just sometimes goes nuts after it correctly executes the move. Seems unusable. Help @Djavan @Nicolas


This was confirmed to also be an issue on the bebop 1 per discussion on the GitHub page. Also, I found others talking about it on this forum so it has been an issue for several years. Any chance of a fix? MoveBy sure would be nice to have working.


Ok, I have been working to narrow down this issue because our drone has caused injuries with the random behavior of taking off in a random lateral or forward direction at high speed. I wanted to find out how to stop it and see if I could debug it. I have been recording sensor data during good and bad flights. I have that data if anyone from parrot wants to see it (I’m not going to post it generally to the forum since it contains my GPS location). What I can see is that these random pitches or rolls happen when the GPS lock is going in and out (basically during the transition zones). So I have two questions: 1) is someone from parrot looking into this behavior? and 2) how can I disable the GPS from being used? We are flying indoors (for a contest!) and I really do not want this to happen during the contest. It’s bad enough that I injured myself. Although the contest is held in a net, I don’t want any chance of injuring spectators either! The contest is in a little over a week so I need to at least address #2 (turning off the GPS). Thank you in advance for @Djavan and @Nicolas helping please.



We will report the issue to the drone software team. This is definitely not the intended behaviour!

Regarding the GPS, you cannot disable it from the software side, but you can make sure that it never fixes (if you’re only flying indoors) by covering it with a conductive sheet of metal (aluminium foil should do the trick, while not really aesthetic). This might be a “quick and dirty” solution for your event.



Thanks @Nicolas! If they want my log files, I’m happy to share them. We recorded data from 3 anomalous events this morning. I saved them out as a csv file so it is easy to share. I was recording from the sensor data at 20 Hz.

Where would you cover it? We still need the camera to work. Do I cover the front except the camera? I haven’t taken apart the bebop so I don’t know exactly where everything is in it.


You can just cover this part of the drone (the top, in front of the battery), this is roughly where the GPS antenna is placed (the same goes for the Bebop 1 : the plastic part behind the foam nose, but in front of the battery)


Thank you! We tried it and it worked great. GPS stays at 500,500 (seems to be a default) and no repeats of the crazy fly-off behavior. Good fix for safety next week! Look forward to the firmware fix also once they get that. Thanks!!