Add moveByVelocityZBodyFrame

[meurissemax]

Fixes: #3476

About

To be consistent, I propose to add function moveByVelocityZBodyFrame to Multirotor API.

Indeed, the function moveByVelocity has its associated moveByVelocityBodyFrame. It is not the case for the function moveByVelocityZ.

More over, I experienced a small problem with function moveByVelocityBodyFrame (when used to move in X-Y plane): multiple calls, separated by a small amount of time (for example, the time to process and analyze an image) leads the UAV to move downwards gradually.

A small video illustrating this problem is available here: https://youtu.be/iiWdGzhMKqA.

The use of moveByVelocityZ solved this problem, but unfortunately its associated moveByVelocityZBodyFrame does not exist, so I propose to add it.

The implementation is (almost) exactly the same as this PR: #3169.

Usage: moveByVelocityZBodyFrameAsync(vx, vy, z, duration, drivetrain (optional), yaw_mode (optional), vehicle_name (optional)).

How Has This Been Tested?

I used the modified version of the AirSim plugin in my Python project. I tested the function in multiple environments by simply moving the UAV using moveByVelocityZBodyFrame . The UAV successfully moves by velocity in its direction's X-Y frame.

A use case of my project is available here: https://youtu.be/mODIlYtCzP8?t=15.

In this example, the drone moves using moveByVelocityZBodyFrame. It can be seen that the drone stops very briefly from time to time to perform calculations and still keeps a constant altitude during its movement.

Screenshots (if appropriate):

/

[ghost]

All CLA requirements met.

[rajat2004]

The implementation is almost exactly the same as moveByVelocityBodyFrame, so maybe it can be extracted out to a common method? I can't think of any good way to do this currently, if anyone has any ideas that would be great, else can be left as is

[meurissemax]

Hello @rajat2004 👋 , thank you for your review!

As I mentioned, the implementation is almost exactly the same as moveByVelocityBodyFrame. More precisely, they have in common two lines of code that transform the velocities in the world frame to the corresponding values in the drone frame.

This transformation can certainly be computed in another function, but to be honest, I don't known how and where to add properly such a function, so I prefer to leave it as it is for now.

I create a new commit with modifications according to your advice.

[rajat2004]

@meurissemax Yeah, the duplication is pretty small so shouldn't be a problem ig

[jonyMarino]

Hi @meurissemax! Thanks for your contribution!