Hi Rolf!
So, just to be sure I’ve understood correctly, if I load Rover firmware and then I load Plane firmware again, that should fix?
Test that doesn’t cost anything, so I’ll try. 
Thank you
Paolo
Tried. Unfortunately nothing changed…
Its in the current stable, not sure why its not working tho.
Dear Peter,
did you had time to take a look at logs? Did you notice how output pwm to esc is working reversed compared to pitch attitude…?
Too bad Paolo, it was just an attempt.
The Pixhawk is mounted correctly - with the arrow pointing forward ?
Thanks for the information, I will download the stable version for the Reverse-Tri this weekend
Rolf
Hi Rolf,
yes, pixhawk is mounted with arrow pointing forward.
I’m planning , if no solution available , to proceed with hover test forcing negative PID on pitch.
At least I’ll know if motors (thrust ) combination is ok and if hover stability is achieved (my motors positioning vs. GC is quite borderline…)
Question: what about if I reverse the servo_2 output (elevator)? That should reverse both travel and stab. correction on elevator, correct? Travel can be fixed by reversing servo input or tx.
That way I should have both stab. corrections reversed (nose motor esc and elevator) .
Then forcing PID to negative it should be ok…?
This is not a good idea, the plane will crash immediately if you switch to a non-manual mode.
Made other tests with all 3 motors.
Summarizing: all 3 motors are reversed as stabilization. Moving nose down front motor reduces the speed, rear motors increase the speed.
Despite I’ve Q_FRAME_TYPE,6 (reverse tri copter) it works exactly as Q_Frame_Type 7 so a normal tricopter.
I’ve also tried to change to frame type 7 and motors work exactly on the same way as type 6.
It seems that Q_frame 6 is a copy of Q_frame 7, and not reversed…
Is that possible?
This weekend, I will install the current Arduplane on our Mozart II and report whether the problem occurs there (FC is an F765-Wing).
Dear Rolf,
Do you still have a saved parameters list file for a configuration that worked fine with pixhawk? If available and knowing with which firmware version it was based, I could upload those parameters and firmware and check if my motors problem disappears…
Sorry to bother and thank you
And another question Rolf
How is your experience with F765 wing vs pixhawk? Do you recommend to switch to that?
Hello Paolo,
here is the parameter file: 2019-10-28 14-33-12.BIN.param (20.8 KB)
with the Pixhawk 1-1MB from this flight: https://vimeo.com/369415229 . At that time the ArduPlane V4.1.0dev (4d17a7cf) version was installed.
With the F765 the plane was just hovering. Due to the bad weather in winter and the pandemic restrictions the flight with Transition is still pending.
Thank you Rolf.
I’m quite desperate…
Tonight I’ll try again with DEV firmware version as first test and mine parameters, then as second test I will upload your parameters still with DEV firmware.
@ Peter: do you kindly have any further suggestion?
Thank you all.
Dear Rolf and Peter,
finally I found and solved!!
I’ve approached systematically starting from fresh clean firmware and I’ve checked after each parameter’s change how was the pitch correction.
Step by step I found who is the “chaos” generator: front tilt servo (function 41) connected to servo port 7!!
In fact at beginning everything was fine but, as soon as settled servo7 function to 41, pitch stab. reaction went reversed.
Pixahwk doesn’t like that condition?? It seems.
I’ve then changed to servo 12 port and… it works.
I’m very happy now. 
Thank you very much for your support!
Now I can continue
Thanks to this observation I have been able to track down the issue, should be fixed in master soon.
The tricopter motors backed was failing to init correctly because it couldn’t find a yaw servo. But plane was never checking if the motors lib was happy. Plane should be like copter and refused to arm. Instead you got to arm with the half setup motors backend. So most of the backend was working but the bit had never been set to tell it to be backwards in pitch.
If you were very quick connecting you should have seen MotorsTri: unable to setup yaw channel
In the mean time in order to get this to work you just need to have the yaw servo setup somewhere, despite the fact that plane does not need to use it. SERVO16_FUNCTION = 39, should fix and you don’t loose a channel because you only have 14 on a Pixhawk anyway.
The reason why it was failing when you set SREVO7_FUNCTION to something is that is the default yaw servo channel. So motors couldn’t find the tail servo on any of the other outputs and SERVO7 was free it was setting 7 to 39 and passing the check. Once 7 had something else on it cant find yaw and its not allowed to change 7 so it fails.
Sorry it took so long to get to the bottom of this one.
1 Like
Dear Peter,
you made a great job.
Thanks again
Dear all,
finally yesterday I’ve tested: both hovering and transition to normal flight.
Surprising it has been able to fly! And quite well!!
A little of PID work is still needed on Yaw (higher D??).
Here is a celebration video I’ve prepared 
I’m very happy about result.
3 Likes
Congratulations Paolo. Your VTOL flies great right away. And the CG seems to fit too. Thanks for the also great short film.