Here are a few fairly close looks at transitions into and out of QHOVER.
From AUTOTUNE into QHOVER, there’s some instability as it tries to pitch up hard while holding altitude. Maybe there’s a strategy to prioritize stability over altitude hold during the first few seconds. @tridge mentioned a strategy whereby stability might be prioritized over altitude hold. Is this on by default, or activated by flipping a parameter?
In hover, pitch stability is better with the “top” facing into the wind. I think this is because I calibrated accelerometer level with 3 degrees of nose up to get more angle of attack in forward flight, but it probably also means hover is 3 degrees from vertical. Is there a better way to set angle of attack independently for forward and hovering modes?
Overall though, it feels pretty confidence inspiring!
Next Steps
Transition into and out of QLOITER. Seems like it’s okay to go straight from QLOITER to FBWA, but coming back to a hover it might be better to go FBWA --> QHOVER (allow forward speed to decrease close to zero) --> QLOITER. This kind of strategy is described in the quadplane documentation also.
To explain the concept a bit further, the idea is that rather than try to run copter control loops using a body frame of reference, we instead use a rotor frame of reference which is a combination of the angle of the body plus the tilt angle of the rotors relative to the body averaged across the rotors.
The ‘Twin Vectored Belly Sitter’ has been added as separate frame class and is selected by setting Q_FRAME_CLASS = 13
We then use the nav_pitch demand to specify a desired rotor orientation in earth frame. This demand is rate limited according to the Q_TVBS_SLEW_LIM parameter with default value of 60 deg/sec. The rate limited pitch demand is also filtered using first order low-pass filter as specified by the Q_TVBS_SLEW_TAU time constant wiht a default value of 0.2 sec. This filtering ensures that the tilt mechanism will not be asked to to rapid angle changes that is cannot follow.
The tilt servos are adjusted to keep the rotors pointing in the direction specified by the nav_pitch_cd variable. The mapping from demanded motor tilt to servo deflection is specified by the Q_TVBS_ANGMIN and Q_TVBS_ANGMAX parameters and the servo PWM max, min and trim parameters for the tilt servos.
In effect we are pointing the motors similar to how a servo camera gimbal is pointed.The wing is allowed to assume it’s preferred angle underneath the rotors. The elevator is used to damp the body pitch motion so the motor pointing control does not have to compensate for large body rates . This aerodynamic control damping is controlled by the Q_TVBS_QGAIN parameter. Some additional pitch damping is also fed into the tilt motors and controlled by the Q_TVBS_TILT_LAG parameter.
This means the copter control laws are demanding the angle of a rotor disc which is what they are designed to do.
Control of yaw and roll has been left alone for the time being, however I will be adding a gain parameter so that we can also adjust the amount of fraction of aileron control action sent tot e control surfaces during VTOL operation.
Hi prisebrough, if I understand your idea, the wing is hanging in a semi float in hover with pitch controlling motor tilt to control velocity forward or back with the wing in tow? this should be interesting, might just be able to fly into and out of ff with ease,if I understand this correctly ?
@lorbass The pitch angle ‘seen’ by the copter loops will be the average of the two rotors and does not include the aileron mixing which is equal and opposite for each motor. The tilt angle demand for each rotor is the sum of the tilt required to track the filtered nav_pitch_cd plus the aileron mixing component.
@tilt Yes, your understanding is correct. Flying in and out of FF should be possible provided the wing pitch rate can be damped aerodynamically to remain within tilt mechanism limits.
Assuming hover testing is successful, then some reworking of the transition logic will be required because when in VTOL mode, the AHRS_view data seen by the VTOL control loops is providing the rotor angle, not the body angle.
The idea for forward transition is to tilt the rotors forward and wait until the wing has tilted past a threshold (use AHRS, not AHRS_view) which will occur naturally when there is enough airspeed. When this happens the plane control loops can be engaged.
For reverse transition, we may be able to go directly into QHOVER mode. Alternatively we could stay in fixed wing mode, whilst tilting the rotors to the vertical as quickly as possible (throttle can be set to a specified value when this is being done) and QHOVER engaged with a nav pitch demand of 0 when the rotor tilt is complete.
@jeffstreet You are probably experiencing reverse flow over the wing. The faster you descend the more flow you have over the wing in the wrong direction, making it want to flip around to be leading edge first, a problem native to tailsitters. Try to lock the surfaces in descent because they are giving the reverse command.
Accelerometer calibration (code is in libraries/AP_AccelCal/AccelCalibrator.cpp)
requires placing the vehicle in 6 distinct orientations (nose up/down, left/right wing up, and belly up/down)
There would be no difference (other than labeling) in the calibration procedure, so I don’t see any sense in changing the meaning of “nose up” for a tailsitter.
Hi @Caleb_Harris
The PWM outputs are configured by the SERVOnn_FUNCTION parameters. You can use whatever pins you like, but note that there are 3 groups of “main” outputs in the Pixhawk, and PWM rates apply to whole groups. The groups are [1-4], [5-6], and [7-8].
so left elevon servo is channel 1, right elevon is channel 2, and throttleLeft/Right are channels 5/6.
This puts the servos in group 0 and the ESCs in group 1, which allows running the servos at 50Hz while the ESCs could be at 400Hz.
I haven’t actually checked whether these speeds are correct. It would be wise to check at least the servo rates if you’re using analog servos, since they can burn up if the rate is too high.
i have finish calibration and the plane can fly well at QSTABILIZE mode, but while i switch mode from QSTABILIZE to QHOVER the plane unstable and fly down.
can anyone help me. this my log https://drive.google.com/open?id=0B3YvxLi0Xv5JbVFlaDY1MjdfdVk
yes, if throttle going down the plane unstable, is this PID problem or my tunning was wrong.
so i can’t landing at mode Qstabilize, but work well at stabilize mode.
this is my other log https://drive.google.com/open?id=0B3YvxLi0Xv5JQVlsX29CRzViUEU
I’ve never considered flying a tailsitter in STABILIZE mode instead of QSTABILIZE; where did you get the idea to do that, and do you know how it differs from QSTABILIZE?
i’m sorry, i don’t have video. but tomorrow i’ll record my test flight.
i flight with qstabilize to stabilize mode because i can flight the plane with manual mode. and i have test the respond of servo is right at stabilize mode.
I am still running into trouble in getting my servos to respond at all. I have motors running correctly, and I also have checked the servos to make sure they operate.
I have motors on Outputs 1 and 2. I have Y-splitter servos in Output 5 and 6. I have a V-tail setup with two servos on each tail.
I am attempting to test the servos by putting the drone in Manual mode and arming the drone. No responses at all.
I was powering the Pixhawk form the USB port, but I read that there wouldn’t be outputs in the servo rail. So now I am powering from the Power port using a power module.