Thanks Rolf, we use regular firmware, unmodified. So what about AHRS_ORIENTATION ? should that be changed? I have it set to the nominal value (AHRS_ORIENTATION = 0).
AHRS is as usual according to the FC attitude.
Here are our parameters: 2019-09-06 10-00-00-0006_644.BIN.param (16.9 KB)
Final succeeded today with 2 full hovers of the reverse-tricopter. Mode -> QHOVER. Parameters used were;
Q_A_RAT_PIT_D,-0.0036
Q_A_RAT_PIT_FF,0
Q_A_RAT_PIT_FILT,10
Q_A_RAT_PIT_I,-0.25
Q_A_RAT_PIT_IMAX,0.5
Q_A_RAT_PIT_P,-0.25
Next is to mount a forward thrust motor that can rotate about the CG or there about. Thanks Rolf for your help.
FM
Just tested this on a real copter, I can see no reason why it should not also work on plane maybe I built the wrong branch for you previously, this is the version I tested built for plane.
arduplane.apj (999.6 KB)
from this branch
Reverse tricopter has now go into master,
set Q_FRAME_TYPE to 6 for MOTOR_FRAME_TYPE_PLUSREV
Motor 1 and 2 remain on the right and left respectively as with standard tricopter. the ‘tail’ motor 4 is now at the front
should be in the latest builds within a day
1 Like
Thanks a lot Peter.
We are currently rebuilding the tilt mechanism of the rear engines. I hope we can test the new firmware in the next few days.
Hover now works correct with Q_FRAME_TYPE 6 and positive p-values - thanks a lot Peter
Next we will adjust the PID values so that it hovers without having to press forward pitch:
https://vimeo.com/364862615
I do not know where the backward trend is coming from. When hovering you have to push far forward (even in calm weather). Next, I want to set the I-part greater than zero (Q_A_RAT_PIT_I) .
Rolf
1 Like
Q_A_RAT_PIT_I will defiantly help, the usual rule of thumb is to set it the same as P. Not sure what was going on when you switched to Q_hover that was quite nasty.
The drift backwards actually was caused by the missing integral part. With Q_A_RAT_PIT_I set the same as P the VTOL hovered very well.
But due to heavy gusts of wind the hover-test took place (between two rain showers) in the lee of the house. Next try-out for transition will be in better weather conditions.
This morning, maidenflight of Mozart II was successful 
Thanks to the developers, especially Peter Hall and Andrew Tridgell. Special thanks to @Walter , who has designed and built this wonderfull plane.
Cheers Rolf
4 Likes
Unfortunately, the weather is too windy and rainy to carry out VTOL flights today. Therefore i use the time on ground to summarize our settings:
FC is a Pixhawk with 1 MB, firmware currently Arduplane 4.1.0 dev from October 06 2019. Like a standard tri-tilt, Q_FRAME_CLASS is set to 7. But Q_FRAME_TYPE needs to be changed from 1 to 6 for MOTOR_FRAME_TYPE_PLUSREV.
MOTOR 1 is the right rear motor, MOTOR 2 is the left rear motor and MOTOR 4 is the front motor. Since only the front motor (motor 4) is tiltable (binary bitmask 0001 = decimal 8 ), set Q_TILT_MASK 8.
Our Pixhawk connections:
The BLHELI32-ESCs have been intentionally connected to outputs 9,10,11 since at DShot is not possible at outputs 1-8.
Q_M_PWM_TYPE,4 (DShot150). (No calibration required, motor cables are directly soldered without plugs, which saves weight. If necessary, you switch the motor direction via blhelisuite passthrough).
Q_TILT_TYPE,0 means continous yaw-servo as yaw-control. Contrary to our posting on May 2, we unfortunately had to give up the idea of driving the rear tiltservos as vectored yaw. Hovering at QSTABILIZE/QHOVER works well with vectored yaw, but unfortunately after forward transition is completed, the PWM decreases down to the “virtual” PWM (e.g. 700 µs - see Reverse Tricopter-VTOL Plane ) and would damage the tilt servos while in plane flight mode.
So the rear Tiltservos are controlled as if they are a yaw servo of a tricopter: Q_TILT_TYPE = 0, Servo5_Function and Servo6_Function is set to 39
Other parameters that depend on frontmotor-power and stall speed are
ARSPD_FBW_MIN,10
Q_TILT_MAX,75
Q_TILT_RATE_DN,10
Q_TILT_RATE_UP,80
Regards Rolf
Today @Walter and me completed flight no.2 - stupidly without SD card and thus without logfile * argggg *. And probably i forgot to activate the ESC brake on the right rear engine - why the right rear engine rotates in flight.
Q-Assist works brilliantly: Shortly after forwardtransition completed, it prevents from stall after I pulled up too much and the plane exceeds critical angle of attack . On the other side, without Logfile it is idle to reason why the plane climbed into the sky after the backtransition to Qhover due to no reaction to the throttle stick. After switching to Qstabilize I was able to sink.
Flight No. 3 will be again with SD card
Rolf
Yesterday and today we tested successfully at wind speed above 5 m/s.
https://vimeo.com/369021227
We noticed a small problem: Immediately after completion of the forward transition, the pitch goes 10-20° up and the engine power goes back only a short time, then raises too high.
It would be nice if the aircraft is flying in a plane-mode, that the rear tiltservos are placed in middle position. That would reduce air resistance
Rolf
hum, could just be transitioning abit slow or the elevator servo is abit out of trim so it takes a little time for the I term to build up. It looks abit windy maybe the wind estimate was abit out. Should be able to tell from the log. Not sure what is going on with the jump in the front tilt, the first bit is very smooth.
Do the rear tilts just stop where they last were? Should be easy to fix to get them to centre. Might be interesting to try with the left and right tilt outputs, we should able to get them to also tilt forwards for the transition.
edit: it looks like they should be centered already
Hallo Peter,
Thanks for the review. Only one servo is centered:
The rear tiltservos are connected to the Main-Out 5 and 6 pins of the Pixhawk. Both are assigned to servo function 39 (SERVO5_FUNCTION,39 and SERVO6_FUNCTION,39). However, both servos have different center trim (SERVO5_TRIM,1600 and SERVO6_TRIM,1400) . But in plane modes, both servos go to 1600 μs.
Please excuse me for not posting the link to the logfiles earlier https://www.magentacloud.de/share/x3tt1at8.b
Video Flight 4: https://vimeo.com/369107177
Rolf
that transition looks much better. Looks like the code is just a little confused at having two yaw servos, should be quite a easy fix.
That would be great.
This is the fix for the yaw servos outputs
I have built the PR on top of master for Pixhawk1-1M arduplane.apj (880.3 KB) and also standard Pixhawk1 arduplane.apj (1008.7 KB)
It turns out @tridge had already done a open PR for this that I overlooked, he remembered to update the quadplane bit too and I forgot. His fix has just got merged so it will be in the daily builds soon!