Excessive Drone motions with fly_direct method in Bebop 2

[tomas-ascensao]

Hello!

I've been trying to code a controller for the drone by making extensive use of the fly_direct function, which receives the controller's output.

bebop.fly_direct(0, 0, yaw, 0, duration=0.5)

(the yaw value varies, but it stays within the range [-50, 50])

One thing I noticed is that whenever I use fly_direct with only duration and yaw arguments, in order to make the drone change heading while remaining in the same (x, y, z) position, the Bebop 2 drone tends to move significantly over time in the x and y axis. This motion in x and y becomes even more significant when the drone changes the direction of rotation around the z axis or when it transitions from any motion involving pitch/roll to the one described by the code above. Shouldn't fly_direct prevent this from happening since the roll and pitch arguments are set to zero?

Is there any way to stabilize the drone around the same (x, y, z) position while it changes heading?

Thanks in advance

[amymcgovern]

Do you have flat trim enabled?

Also move_relative will turn in place but watch the firmware bug I note in the documentation.

[tomas-ascensao]

By having flat trim enabled you mean whether I'm using the set_flat_trim method at the beginning of each test flight? If that's the case, then no, I haven't used it, thanks for the tip.

Regarding move_relative, whenever I use it, the drone just remains still (and stable) in mid-air and the code interpreter never leaves the function (probably stays stuck in a loop inside). I just read the documentation and although I'm using the drone indoors, the scenario seems rather different from the one described there.

Do you think this problem is due to mixed coverage and can be solved with tin foil?
(I'll try using the tin foil just in case)

[amymcgovern]

The mixed coverage is definitely an issue. To my knowledge, they never fixed the firmware bug that I reported about that.

[tomas-ascensao]

Found out that the problem couldn't be fixed with tin foil. After testing more code I realized that move_relative works just fine as long as fly_direct is never used. Once fly_direct is used, the next time move_relative is called, the drone will just stay still indefinitely, regardless of the arguments used, with the interpreter never leaving the move_relative function.

Is this supposed to happen?

Here's the simplest example I tested where the bug could be seen:

print('Using move relative to turn the drone 60 degrees')
bebop.move_relative(dx=0, dy=0, dz=0, dradians=np.pi / 3)
print('Using move relative to the left, 2 meters')
bebop.move_relative(dx=0, dy=-2, dz=0, dradians=0)
print("Using move relative to the right, 2 meters")
bebop.move_relative(dx=0, dy=2, dz=0, dradians=0)
print('Using move relative backwards, 30 cm')
bebop.move_relative(dx=-2, dy=0, dz=0, dradians=0)
print("Using fly direct")
bebop.fly_direct(0, 0, 0, 0, 0.5)
print("Going forwards")
bebop.move_relative(dx=-2, dy=0, dz=0, dradians=0)
print(f"Landing...")
print(f"Remaining Battery = {bebop.sensors.battery}")
bebop.safe_land(5)

Depending on whether the fly direct command is commented out or not the code will either reach its end (drone lands), or it will stop working from print("Going `forwards") onwards. Is there something wrong with the code? (I also tried using different arguments on fly_direct but the result was the same)

[amymcgovern]

That's really odd! I wonder if there has been a firmware upgrade recently? My bebop no longer charges so I can't even turn it on to check :( I know we used to use fly direct and move relative but I tended towards move relative because it uses more precision internally (they use internal sensors that they don't give us access to through the API to move a precise amount)