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.
Thanks a lot Peter.
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:
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) .
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.
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
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
Yesterday and today we tested successfully at wind speed above 5 m/s.
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
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
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
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.
Autotune in calm conditions:
This is the fix for the yaw servos outputs
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!
Finally got round to having a quick look at this log, looks to me like a bad wind speed estimate. On the point of transition there is a big jump. Forward flight tune is a little loose, abit of a tune up would probibly help and then running servo auto trim for a bit would probably help also.
edit: the third line is total estimate wind speed
thanks for the efforts. Best will be to flash a daily version ?
Only for understanding: What role does wind speed estimation play if we have an airspeed sensor ? We use an airspeed sensor just to avoid being dependent on estimates.
(ARSPD_TYPE,6 = SDP33, ARSPD_USE,1 )
Yeah, its in the daily builds by now.
The estimate should be more accurate with a airspeed sensor. I’m not sure exactly how this works for VTOL stuff, ie is the estimate updated when hovering, I theory always transitioning into the wind should result in the real airspeed being higher than the estimate. This is much better than the other way round. I think such a jump in airspeed seen here could be due to the sensor suddenly becoming enabled once the transition is complete or something like that but I’m not familiar with how it work in the code.
Was it windy in the test? Was the transition into the wind? Have other transitions in different wind conditions done the same thing? I’m not an expert with this log analysis stuff but the airspeed change did jump out to me.
It happened on all flights. Flight 4 was in very windy, flight 5 in calm conditions. . All transitions were against the wind
I am looking to implement this very same configuration of a Reverse Tricopter - VTOL plane on a NAVIO2. The only difference will be that the motor at the front will not tilt to provide forward thrust.
I just had a couple of questions -
- I have updated mission planner to the latest and also got the latest 4.1.0Dev binary however in mission planner I can’t see the option for Q_FRAME_TYPE = 6 (for the motor mixing mentioned here -Reverse Tricopter-VTOL Plane). My guess is that this is because this has not been included in the stable version yet and hence Mission Planner has not been updated.
- Secondly, just curious to know when v 4.1.0 will be a part of the stable branch.
Thanks for all the great work to support this config!!