Great idea,
we will first look how the plane will behave as a copter. The wiring is done/planned as follows:
Motor 1 output with rear Motor right (instead of right frontmotor as usual)
Motor 2 output with rear motor left (instead of left frontmotor )
Motor 4 output with front motor (instead of the rear mtoor)
Q_TILT_MASK = 8 (only Motor 4 is tiltable)
Q_TILT_TYPE = 0 (no vectored for der Controler)
ServoXX_Function 41 to the front motor tilt servo
Motor 7 Output (usualy for yawservo) with both ±30° tiltservos of the rear motors.
Might even work right out of the box if your lucky, if I get a chance I will add a reverse tricopter mixer. With those settings I don’t think you will need anything custom on the tilt rotor side.
I think a new Q_FRAME_TYPE makes sense for this. I think we’ll also need some work in the ArduPlane/tiltrotor.cpp code, as we’d need to support vehicles where some motors only tilt by a small amount and others tilt a large amount.
I have done a PR for reversed tricopter, should make it into master before you need it hopfully, otherwise I can build it for you.
This just inverts the outputs of the PID’s so is the same as using negative PID’s but now you wont get the errors and you can autotune. You need to set Q_FRAME_TYPE to 6 for MOTOR_FRAME_TYPE_PLUSREV.
As soon as the ESCs will arrive, we want to perforn the first hover tests (still without wings. The wings still under construction are outlined in yellow) @iampete Peter, could you build us a binary for a pixhawk 1?
So we do not need to use negative PIDs and will set Q_FRAME_TYPE to 6 for MOTOR_FRAME_TYPE_PLUSREV
yep. I hope it doesn’t matter that it’s nominally a motor output because I switched the motor outputs to Dshot. If not, I have to switch the motorutputs to PWM.
For the first hover-tests we have vectored yaw enabled - with a little trick:
Our rear servo mechanics tilts the motors at PWM values between 1100µs and 1900µs by +/- 45°. The rear servos of course can not tilt the engine completely forward, but the software does not know. You simply have to set SERVOn_MIN down to a suitable “virtual” value, as in the following example:
Unfortunately, in one of the tests, a mechanical failure caused the front servo to break. Better on the ground than later in the air. It will take a few days until a new servo is installed.
After repair of the servomechanics we wanted to complete the first hoverfly in qstabilize today.
Unfortunately, the pitch regulation goes in the wrong direction. The aircraft would therefore jump over immediately after taking off. AHRS_ORIENTATION is 0, Pixhawk shows forward, Q_FRAME_TYPE is 6, Q_FRAME_CLASS is 7. PIDs are positiv. (Roll is okay).
Here is the full parameterlist: mozart2.param (20.8 KB)
I turned the plane by hand alternately forward and backward or to the sides.
Roll works properly, Nick stops the front engine when the nose is down (instead up)
Motor 1 (rear right) Servo9_Function=33
Motor 2 (rear left Servo10_Function=34
Motor 4 (Front) SERVO11_FUNCTION=36
not sure whats going on, the log also shows its backwards. I guess you rebooted after setting the frame class and type params?
I’m 95% sure I tested this and it worked fine in SITL Maybe you could also try in Qacro? although i doubt that will make any difference. I will double check its all working in SITL.
edit: although i tested on copter rather than plane, maybe there is a initialisation difference or something