Tiltrotor support for plane

Easy enough to put it back to the AvA configuration and probably better for consistency’s sake.We’ll make it happen.

Looking at the RC config in OpenTX it indicates CH6 for transition, CH7 for gear. Greg would be a definitive authority on all of that however. I’ll put the AvA configuration we used in OpenTX in dropbox:

I took a nap and woke up to all these posts. :slight_smile:

Here is the Pixhawk mapping for AvA on the Main and Aux Outputs. The optional Relay on AUX6 is for mapping.

The motor numbers, 1 thru 6, are then shown on the spin direction diagram below.

for transition servo, what PWM values, and is high PWM for fwd flight or hover?
same question for landing gear

Transition Servo:
Hover Mode PWM = 1005
Forward Flight PWM = 1995

Servoless Retracts
Gear Down PWM = 1100
Gear Up PWM = 1900

The transition servo takes the range above on my FireFLY6 DIY15. Other DIY15/DIY25 models may need the max. and min values tweaked for proper alignment in both hover and FF modes. The most recent BEV Aerobotics firmware, v1.2, also tweaks the setting in flight for better efficiency…in case the user didn’t get it perfect.

Values for ours…

Transition Servo:
RC9_DZ,0
RC9_MAX,1830 (forward flight)
RC9_MIN,1030 (hover)
RC9_REV,1
RC9_TRIM,1500

Same values for gear as Greg.

@tridge
there is a bug in the current firmware beta2. Airspeed is not working. I opened a issue.

Besides that we did some transitions today. Because of the wind we flow just in QSTABILIZE and STABILIZE. We flow the first battery with ~5 successful transitions(QSTABILIZE -> STABILIZE). The second battery was reserved to produce some short log files and videos. There just one transitions was successful. Because of that I would like to focus on the transitions STABILIZE -> QSTABILIZE.

Information:

  • YAW_P = 0
  • Wind SE ~6m/s
  • Transition QSTABILIZE -> STABILIZE was difficult because of some wind and no airspeed data
  • Transition STABILIZE -> QSTABILIZE was always nice but the motors throttled up after switching to QSTABILIZE, I don’t know why.

Here three logs:
2017-02-02 14-53-16.bin.zip (8.1 MB) https://youtu.be/piBjsb7iwkU (successful QSTABILIZE -> STABILIZE)
2017-02-02 14-57-31.bin.zip (4.1 MB) https://youtu.be/f_i4dSa02-I
2017-02-02 15-00-24.bin.zip (4.3 MB) https://youtu.be/zheFfF0qy-Y

EDIT
Here the flights with the first battery with more successful QSTABILIE -> STABILIZE transitions.
2017-02-02 14-22-43.bin.zip (38.9 MB)
/EDIT

I hope this flights and logs are useful for the tiltrotor development.

Tridge,

Just wondering if an airspeed sensor would be beneficial for the FF6? While having one hasn’t been necessary thus far, we happen to have one sitting on the shelf, unused at the moment.

Solved. With the new firmware a new parameter is not correctly set. Instead of ARSPD_USE there is ARSPD_TYPE, wich was set to 1 (I2C-MS4525D0) instead of 2 (Analog).

Hi, I’ll post for a friend that ask if it’s possible use the firmware of the DL-84 in a flying wing that have just elevons control.
Setup: SkyWalker X7 + tricopter with tiltable front motors (toghether or indipendently).
Thanks

Hi @TimWallace and @GregCovey, I’ve setup the SITL simulator to have the same motor ordering as AvA for the FireFlyY6. See this PR: https://github.com/ArduPilot/ardupilot/pull/5671
It flies fine in SITL, now it just needs testing on a real aircraft.
As this PR is waiting review for going into master I have put a prebuilt firmware here:
http://uav.tridgell.net/FireFlyY6/
in the same directory I’ve put a file firefly.parm which is the parameters you’ll need to set. Note that I am not sure if the ELEVON_OUTPUT value is correct - please check on the ground in FBWA mode to make sure the elevons move correctly for both stabilisation and manual input.

Hi Tridge,
I would like to ask,what is the total weight of your CL-84 (including 5.2Ah battery and pixhawk and all accessories)? how long can fly?
Thank you!

yes, that setup should work, assuming that it uses a tiltable tail rotor for yaw. If it uses tilt of the front motors for yaw then it won’t work yet, but I plan to support that soon (I have ordered an E-Flite convergence aircraft for testing that)

Thanks for the info Tridge, my friend (and me to) prefer use ardupilot instead of Px4.

no argument from me on that!
can you post a picture of your aircraft? Are you OK with working out the right parameters to set or do you need some help?

When my friend send me some photo I’ll post, now he building the mechanism for tilt motors. I thinks that when we started the test the help will be appreciated

the airframe is 1.7kg without the battery, and the battery is 433g, so it is 2.1kg total

Thank you very much for the reply! I have a question about modification. Since quadplane is using multicopter code for hover and then transitions to plane mode if I insert my own frame in these lines in quadplane.cpp:


case AP_Motors::MOTOR_FRAME_BICOPTER:
setup_default_channels(6);
break;

Is that all I need to change? Or if I simply keep let’s say MOTOR_FRAME_TRI, but change the AP_MotorTri.cpp to bicopter, will that be easier? I currently just modified AP_MotorCoax.cpp because it has same amount of motors and servos as bicopter of mine. Also, how can I build the file? Do I type smth like: make px4-v2-quadplane? And then change to Q_ in mission planner?

It depends how your airframe is setup. There needs to be extra code if the code that handles the hovers shares the same output channels as the code that handles forward flight. For example, you will see extra code in ArduPlane/tiltrotor.cpp to handle use of some of the vertical lift motors for forward thrust.
If your bicopter frame uses separate output channels then it is indeed very simple to integrate the new frame type. If not there there is some extra work required. If you can post a picture of your airframe and explain the control outputs then I may be able to offer suggestions.

You don’t need to do a special build, just build the plane code as usual, and set Q_ENABLE=1 as a parameter.
I’d also strongly suggest you get it flying in SITL first before you test on a real aircraft.
Cheers, Tridge

Rotors are tilted with servos, roll works with thrust differential, yaw works by tilting one rotor forward and another backwards, and pitch is controlled by tilting both rotors in the same direction, and the mixer is as following:

actuator[0] = - rp_scale*pitch_thrust + yaw_thrust; // Right
actuator[1] = - rp_scale*pitch_thrust - yaw_thrust; // Left

_thrust_yt_ccw = thrust_out - roll_thrust; // Right rotor motor
_thrust_yt_cw = thrust_out + roll_thrust; // Left rotor motor

output pins are same as Coax: pins 1,2 - servos, 5,6 - motors, 3,4 - elevon servos.

Thanks in advance

Tridge,

Took a week to get everything set up but we flew our first hover test yesterday with FF6 utilizing Arduplane. Other than me setting up the pitch control incorrectly and having it reversed from what I’m used to, it flew beautifully. Very responsive and very stable. Some hefty vibrations at times, more than likely due to using the beat up props from previous off field landings (don’t want to sacrifice the good props if I don’t have to just yet…). Looking to fix a few things and hover more before transitioning to forward flight but should be in the works in the next two weeks.

Quick rundown of what hardware we’re running:

  • FF6 DIY25 w/High Efficiency T-motor MT3506’s
  • Modified battery bays/fairings to hold two Turnigy Multistar 6S 5200 mAh Li-Po’s wired in parallel
  • RFD900x Telemetry Radio @25 dBm airside, 30 dBm GCS
  • Emlid Reach RTK onboard as GPS2; Base Reach injecting corrections via MP over telemetry
  • Seagull UAV #MAP2 camera trigger. Sony A6000 camera removed for hover test.

There was some RF interference from the RFD900 that was affecting the Reach initially and I’m not 100% sure we have it isolated just yet but we’ll chase it down.

Bin:

Log:

Params:

RC set up: