Dual-motor tailsitters

Here is a link to my most current configuration backup file:

I did some more flying today, and the hover control authority with the larger elevons was excellent. I did a forward flight hand launch in AUTOTUNE to try to get the forward flight tuning done, with mixed success. The airplane was flying generally OK, but it has a tendency to yaw to one side in forward flight. I could make pretty good turns to the right (in the direction of the yaw), but trying to turn to the left resulted in more of a sideslip. I’m guessing that I’m getting more thrust from one motor than the other, but I haven’t dug into the logs yet to figure out why. I attempted a back transition into a hover to land, which wasn’t successful. I suspect that the extra pitch authority on the elevons, along with the constant yaw, caused it to snap roll as it pitched up into a hover attitude. I’m pretty amazed how durable this Skywalker has been. Other than my little carbon landing gear leg, a bunch of props, and (on this crash) the control horns, I haven’t seen a whole lot of damage!

@mrjadkowski
I analysed your Params of the link.
There is no Parameter RUDD_DT_GAIN. May be you used not the latest Firmware from
here: http://firmware.eu.ardupilot.org/Plane/latest/PX4/
Version 3.8.0beta4 does not support it. And I had to go to the FW of April 9th.

Sorry, that is the parameter backup I made before I did the firmware update. I set my RUDD_DT_GAIN to 0. After looking at my logs for the previous flight, I think my ESCs may have been calibrated with slightly different values. I noticed that in a hover, the flight controller was giving the right motor slightly more throttle signal to keep the airplane level. In AUTOTUNE mode in forward flight, the two signals were matched, and I was seeing right yaw, which I would expect if the left motor was producing more power than the right for the same throttle signal. I recalibrated my ESCs and as far as I can tell both motors are running at the same RPM. Hopefully that takes care of my yaw problem so I can get the tuning done and move on to transition testing.

, Hi, Tridge and fellow avation pioneers, got gray to fly in hover, it’s going to be great,
my comparison on hover, pitch needs 90 deg+ to counter wind, way to quick on roll,
yaw could be a little faster. got some roll oscillations, but overall I am very impressed
"yonika" system, unlimited pitch in hover, I think tilt allows that.
transition switches control to mode2 airplane I think quad flying and airplane flying are inbeded in me and very dificult for me to fly, one the other way. Can that be in firmware?
or in the transmitter the only way?
posted video on youtube

@tilt Congrats, that’s looking pretty good already. Do you stop the motors after landing by switching to FBWA mode? The default delay is 10 seconds in Q-modes and it was obviously faster than that.

excellent! For those who missed it, video is here:

Did you just configure the motor tilts as elevons, or did you mod the code to do vectoring separately?
Can you put the DF log somewhere so I can take a look? Get it from the SD card, or download it over MAVLink with MissionPlanner.

yes, looks like the differential thrust gains are a bit high. The logs will show the contributions to that from P, I, D and FF (in the PIQR log message, which logs roll PID elements in hover). From that you can probably work out what to change to fix it.

yes, transition will be automatic, just change to FBWA mode.
I should have a first cut at support for vectoring in the code done soon. I’ve built a model in FlightAxis, so I have something to test now.
Welcome to ArduPilot!

. Do you stop the motors after landing by switching to FBWA mode?
switch to manual mode , did you mod the code to do vectoring separately? no just split the signal
Can you put the DF log somewhere so I can take a look? yes I will send via google
yes, transition will be automatic, just change to FBWA mode. that’s perfect
pitch needs 90 deg+ to counter wind, doable?
thanks

Tridge, logs on the way, google drive
also if you get a chance take a look at paparazzi chimera controller
I would like to build, then modify for our use ?

I’ve created a pull request that adds support for vectored tailsitters:


The way it works is very simple. The plan is to add complexity after we have initial results.
To use it, you need to do the following:

  • set SERVOn_FUNCTION to 75 for the left motor tilt servo.
  • set SERVOn_FUNCTION to 76 for the right motor tilt servo
  • set Q_TAILSIT_VFGAIN to the forward flight thrust vectoring gain
  • set Q_TAILSIT_VHGAIN for the hover thrust vectoring gain
    You also need to set the REVERSED, TRIM, MIN and MAX of the two motor tilt servos appropriately. The trim should be set for the motors to be pointed straight forward.
    You can also control the relative gain of the elevon mixing with the MIXING_GAIN parameter. So if you set MIXING_GAIN=0 then your elevons will never move and you will be flying purely as a thrust vectored aircraft (in both fixed wing and hover). If you set MIXING_GAIN non-zero then it will combine elevons and thrust vectoring.
    I have tested it in the FlightAxis simulator flying it with pure thrust vectoring (setting MIXING_GAIN=0) and with both thrust vectoring and elevons with various gains. It flies nicely in the simulator!
    I must say though, flying in fixed wing modes with only thrust vectoring (with MIXING_GAIN=0) is interesting. Landing is hard, as when you drop the throttle to land you lose all control authority. So you have to land fast!
    It’s much easier to fly when you combine both elevon and vectored control.
    I found the following parameters worked well in the simulator, with the left motor tilt on channel 3 and right motor tilt on channel 4. I’ve setup the tilt servo throws so that 2000 is 90 degrees up, 1000 is 90 degrees down and 1500 is straight forward.
  • MIXING_GAIN=0.5
  • SERVO3_FUNCTION=75
  • SERVO3_MIN=1000
  • SERVO3_MAX=2000
  • SERVO3_TRIM=1500
  • SERVO4_FUNCTION=76
  • SERVO4_MIN=1000
  • SERVO4_MAX=2000
  • SERVO4_TRIM=1500
  • Q_TAILSIT_VFGAIN=0.2
  • Q_TAILSIT_VHGAIN=0.3
  • Q_A_ACCEL_P_MAX=40000

the reason for setting Q_A_ACCEL_P_MAX a bit lower than the default is to smooth out fixed wing to hover transitions, preventing it pulling up the nose too quickly.

I’ve tested QHOVER, QSTABILIZE, FBWA, LOITER, QLOITER, takeoff in QHOVER, takeoff in FBWA and transitions between all the modes. It flies nicely.

1 Like

@tilt, I don’t know if you’re setup to build the ArduPilot firmware from a PR yet. If not, let me know and I’ll do a build for you of the vectored thrust PR. Just let me know what board you want it for.

thanks!

I see this: Chimera/v1.00 - PaparazziUAV
is that what you mean? Looks like different hardware. We can add new boards, but its quite a lot of work.

thanks for the logs. I think it would be best if I taught you a bit about log analysis, do you can look at the effects of tuning yourself. Would you like to do a G+ hangout with shared screen sometime and I’ll show you how to read the logs? Or a skype call?

Hi, I can build almost anything, but not that mystical code magic.
yes, that board looks like next gen, but you have a full plate now .just lookin.
. Just let me know what board you want it for, the pixracer would be great.
I think it would be best if I taught you a bit about log analysis, that might be the hardest i’m an old dog besides you do such a good job. G+? skype? I will read up to start,
thanks!

I’ve built a firmware for pixracer for you here:
http://uav.tridgell.net/RickYonika/plane-vectored-test1-fmuv4.px4
It supports the vectors gains mentioned in my post above. Good luck with it! Make sure you test on the ground in MANUAL mode first, and check the thrust vectoring is going in the right directions.

great , I will swap pixracer to Ilusion tomorrow and…

@tilt, the most interesting thing in your logs isn’t the controller gains, its the fact that the 2nd EK3 instance goes crazy. You were setup to run two copies of the EK3 state estimator (the bit of code that estimates your attitude, position, velocity etc from your sensors), one for the first IMU and one for the 2nd IMU. The second one went very bad. It automatically locked onto using only the first one for your flight which is why it flew OK, but we would like to find out why the 2nd one went bad.
Paul Riseborough (our state estimation guru) thinks its a vibration artefact, but we’d like to know for sure as it could be a bug.
To get to the bottom of this we need to get some flights with different logging parameters. First though we need to fixup your logging so you don’t lose so much data. Right now you are losing a few hundred log messages per second as your microSD card isn’t keeping up. Do you have a better quality microSD card available? You can also raise LOG_FILE_BUFSIZE from the default of 16 to a larger value (eg. 32) to raise the amount of memory used to buffer the logging.
Then we’ll need a “replay” log. Change these parameters:

  • LOG_REPLAY=1
  • LOG_DISARMED=1
  • LOG_FILE_BUFSIZE=32
    note that by setting LOG_DISARMED it will log continuously even when disarmed. That means you will end up with really large log files. You may like to set LOG_DISARMED=1 just before you reboot for the flight, then set it back to 0 afterwards.
    If the microSD card still isn’t keeping up then you could lower the main loop rate. Change SCHED_LOOP_RATE from 300 down to 200 or even 150. I think it doesn’t need such a fast loop rate to fly this aircraft. That will reduce the amount of data logged a lot.
    Cheers, Tridge

@tilt can you also tell me what vibration isolation you are using on the Pixracer? Is it hard mounted, or does it have some foam or similar isolation? Can you send a photo of the mount?

what telemetry interface were you connected over? (wifi? usb?) and what GCS were you using?

the green gel vib mount don’t remember the name( good stuff)

the vibration is probably coming in via the cables.
How much of the area of the pixracer is supported by the vib sheet?