Hey ,Tridge been working on illusion, testing yaw and transition in hand, dif yaw = good… when switch to fbwa throttle goes to high and serfaces abrupt switch to horzontal seems good for fixed motor mount but I am concerned with vector setup. with baseflight bicopter software, my normal transion is t/o in horizon mode (3pos switch) pos 2 is switch off horizon fly to nose down to horizontal and switch to airplane pos3 that one also changes to a 2nd controller setup for inav and is reverse for landing, my observation with baseflight is that I can hold 1/2 down elevator and the tilt might still point the motors up to hold whatever position the stick is in, is it possible to get that control with a pix ? my controller also uses 2 IMU’s 1 vert and 1 horizontal ,also with the new radio’s can we get more mode channels ? hope this is helpful and doable
@tridge,
First succes with Caipirinha dual motors vectored Tailsitter.
Remarkable issue:
Q_M_THST_Hover does not work. Even set to 0.8 the thrust increases proportional (linear)
to CH3in. With stick in the middle CH5out or CH6out ppm = 1500
This makes the mode change from QSTABILIZ to QHOVER difficult as shown in the video.
Regards Otto
lookin good, better and better,love that it can go upside down and still go, big thunbs up!
Looks good, perhaps Q_ANGLE_MAX higher than default (3000) to fight against wind?
Otto
is it possible to use a rangefinder or optical flow with a dual motor tail sitter aircraft when in hover position?
are dual gps receivers advisable? one for forward flight and one for hover?
I am starting to poke around inside the control loops with a view to improving the wind resistance of the so called ‘vectored tail-sitter’.
I had a question about the axis convention. The code in tailsitter.cpp implies that zero pitch is when the nose is pointing up in hover - is that correct?
I will put the functionality in a new function called bicoptertiltrotor or something like that to make a clear distinction between it and the traditional tailsitter, because the control strategy will be quite different and I do not want to clutter up the tailsitter.cpp file with branch logic.
OK, it looks like the pitch convention is different between VTOL and forward flight modes. I remember now that Tridge made a point of this at his unconference talk. It’s required to keep the copter loops (Leonard) happy.
I’ve made a start here that changes the axis reference to rotor instead of body frame
https://github.com/priseborough/ardupilot/tree/tvbs-wip
This has some theoretical advantages in decoupling rotor tilt and body motion, but there may be some problems in practice that make it not such a good idea. I still need to add some angular accel and rate limiting to nav_pitch_cd.
Foamboard Tail Sitter - Flight Test - QHOVER
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.
The nav_pitch_cd filtering has been added.
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.
Yesterday we had the first hoppers with the Twin Vectored Belly Sitter (pixracer, ArduPlane V3.8.0beta5).
(sorry, the flying Cameramenn was inattentive)
It flew in QSTABILIE, but with low throttle or little bit pitch severe oscillations occurred immediately.
I guess it’s due to high P-values and an “old” firmware . Are the last changes by Paul already in Master ?
logfile: https://www.magentacloud.de/share/ci7vxt6at6
(Current and voltage sensors have not yet been calibrated)
Regards Rolf
@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.
With reduced PID values, it already hovers something better. The first tranistion will follow soon.
Rolf
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.
But perhaps I’m missing the point?