I have been developing a flight mode for the quadcopter to stabilize on a constant yaw rate. This is to have a flight mode which can simultaneously scan and localize inddor environments or outdoor landmarks while mounting the lidar/camera sensors rigidly on the quadrotor structure to save weight.
Below the video is a simple proof of concept of the new flight mode. The quad spins at a constant yaw rate and the pilot controls the quad by activating 'Absolute Mode'
However, as I spin the quad in a faster yaw rate, the absolute mode reference seems to drift and change directions. That is, the reference direction changes, making it hard to control. The video is at 180 deg/s yaw rate. I would like to increase this to up to around 500deg/s. I am suspecting maybe the control loop is running in a low bandwidth but don't see how I can improve the performance.
Moreover, while moving in one direction is working fine but when I change directions vertically while moving in a translational motion, the quadrotor does a kind of swinging movement as shown in the video. What should be done to increase the controllability of this concept.
Any ideas or comments will be a big help to resolve the matters.
Comments
Hi all,
I wrote this part of the code:
_rate_bf_target.x += _angle_bf_error.y * _ahrs.get_gyro().z;
_rate_bf_target.y += -_angle_bf_error.x * _ahrs.get_gyro().z;
This takes care of the fact that when a copter is rotating in yaw, a zero roll error will grow if a zero roll rate is requested and there is a non-zero pitch error. The rates calculated above are such that a roll error of zero will remain zero when there is a pitch error and the copter is rotating in yaw.
One of the major issues with fast yaw rotation is the delay causes a significant yaw offset for these types of flight modes. For example, if you are updating your heading at 10 times a second, or updating your navigation at 10 times a second, when you yaw at 180 degrees per second you have up to a 18 degree error in your applied heading (probably 9 on average).
So you need to do it faster or smarter.
This may be other things too though.
I would think at some point you're going to run into a form of P-factor or gyroscopic precession. With the copter rotating like that, it's now become a spinning gyroscope on it's own.
The accelerometer sensor chip must be perfectly in the aircraft's X and Y center of gravity for this to work. If it is not, then spinning will cause the quad to think it is accelerating laterally in a direction that is described by the vector pointing from the actual CG through the accelerometer. This "false" acceleration will cause the flight controller to try to compensate for perceived movements that don't exist, creating a semi-erratic flight pattern.
The second issue you might be facing is that there is a lag between when the magnetometer is read and when the orientation estimate uses the data to compute the estimated yaw error. As you spin faster this delay will result in a heading error that the controller does not attempt to compensate for since spinning that fast is not considered normal.
Ankur, Thank you for the insight.
I suppose some modification to the low level control should be made...
Will there be any references for the effect of the mixing angular velocity errors between the x/y directions and the z axis?
I suppose the intuition is that if the quad is rotating along z, errors along x are creeping into errors along y and vice versa. However it would be nice to have a proper explanation of why this is needed and also good to experiment how much difference it makes if this is removed from the rate controller.
ok. I'm working on implementing my own flight controller and did a deep dive into the Arducopter source code. One thing I found a bit interesting:
_rate_bf_target.x += _angle_bf_error.y * _ahrs.get_gyro().z;
_rate_bf_target.y += -_angle_bf_error.x * _ahrs.get_gyro().z;
in
void AC_AttitudeControl::update_rate_bf_targets()
In this code, they appear to be mixing the angular velocities in x/y directions based on whether there was movement along z (yaw). So while this could be a good thing to do for general flight stability, it might be contributing to the problem you are experiencing.. just a guess.
Oh, I am using the Arducopter!