Dual-motor tailsitters

The pid adjustment is probably cause your hover throttle (Q_M_THST_HOVER) doesn’t match your actual throttle at hover. If you match them then it should need the same PIDs as before.

actually I think the transitions could still be improved a bit, but it is much better than it was, and I don’t think I’ll change things any more for this release.
Cheers, Tridge

Hi, just a thought… could T/O be sequenced from belly sitting to vertical T/O to FBWA in an auto mode with some time /alt adjustment… another thing I ran into if I armed and moved the craft yaw does NOT like it and it does it,s best to crash…I know, don,t move it after arming
Rick

Thanks for the precise explication of the forward transition
Now, I understand the log of Rolf for this sequence.
Regards, Otto

1 Like

I’ve created a video showing how I test TVBS and tailsitter models for ArduPilot in RealFlight8
https://youtu.be/H4iqBJ9LGJs
If anyone here wants to play around with the ArduPilot code, or just wants to experiment with tuning strategies then I’d highly recommend getting RealFlight8, as it is easily the best simulator for this type of work in ArduPilot at the moment. You can find more information here:
http://ardupilot.org/dev/docs/sitl-with-realflight.html
This is also a bit of an appeal for help with creating nice 3D models of tailsitters and TVBS for use in RealFlight8 for ArduPilot testing. Creating the physics model in RealFlight8 is quite easy, but creating the 3D graphics model needs skills that I don’t have. So if anyone wants to have a go at that then it would be much appreciated.
Cheers, Tridge

Hello everybody!
I would like to ask you for help. We have been testing our tailsitter and we crashed. It was flying OK, but suddenly motors turned off and it crashed. It was in QHover mode. Altitude hold controller for sure needs some tuning, but such a sudden motor kill is strange.

I looked at log and I saw, that baro pressure suddenly fell down => altitude went up…so maybe the crash was due to the regulator trying to keep the same altitude. But why baro dropped so much? Different air temperature? I have no idea.

Please look and share your opinion.

Log - https://www.uloz.to/!yyTqkbGSvrx9/2017-11-03-repas-crash-bin

I’d be happy to look, but I can’t seem to download the log. Tried chrome, firefox and edge.
Maybe its still uploading?
Cheers, Tridge

yes, that actually works now. Just do a normal quadplane VTOL takeoff in AUTO mode, or a takeoff in GUIDED mode.

yep, sorry, once you are armed it will try to fly, which means resisting “disturbance”. It can’t tell that the disturbance is the planes owner. We don’t have a pilot detector :slight_smile:

Very interresting. I have experience in 3DStudio (Kinetix) and I will have a look at the requested datas for
custom made Models.
Regards, Otto

great!
The recommended tool is 3DS Max, and the RF8 release allows it to work with current versions, whereas previously it only worked with the 2012 version.
I don’t have 3DS max and its quite expensive so I’ve been trying to teach myself blender, as I’ve read that its possible to use that, but my lack of experience with 3D modelling is making it slow going.
In case you haven’t found it, there is some info here:
http://www.knifeedge.com/KEmax/tutorials.php
http://www.knifeedge.com/forums/forumdisplay.php?f=99
I’d also love to do a quadplane model. Leonard has nice 3D models in SolidWorks for an X8 quadplane, and it would be great if we could get that as a model, as X8 quadplanes are a popular type of aircraft for ArduPilot.
Cheers, Tridge

Exactly, very expensiv. I got the old version when I left my company.
Will investigate the link to knifeedge.
If it works, the complexity is no problem.

Regards, Otto

2 Likes

Hi Tridge,

Q_M_THST_HOVER is reduced from 0,8 (with beta2 and former PIDs-Tuning) to 0.6 (with beta4) after reading your post Dual-motor tailsitters - #748 by tridge?

Just to be sure: How is Q_M_THST_HOVER set correctly?
( I thought by hovering in QSTABILIZE and read out CTUN.Thr_out ?)

Regards Rolf

I usually hover in QHOVER and look at QTUN.ThrOut, that makes it quite easy

Thanks Otto! It would be really nice to have a good TVBS model to use for testing, and for demo videos.

Just the summary of the two flights from yesterday:

1 Like

yes, got it thanks

That is pretty close to what happened, yes.
Normally this is prevented with the arming checks, but you had ARMING_CHECK=0 which disabled all arming checks. So the takeoff was done with the EKF not fully initialised. If you look at QTUN.Alt you’ll see it was flying without a height estimate. Then part way through the flight it got a height estimate and it wasn’t the same as the current height, so it tried to adjust.

The fundamental problem is you are flying indoors, and the secondary problem is that the arming checks were disabled.
The plane code in ArduPilot was built originally for normal fixed wing aircraft that fly outdoors, and it assumes it will have an EKF initialised with good GPS lock. The ArduPilot copter code is setup to handle indoor flight, but the plane code isn’t. That is something I have been meaning to fix as testing a tailsitter indoors is a natural thing to want to do, at least for initial tests.
Right now if you don’t have good GPS lock you shouldn’t fly. If you have ARMING_CHECK=1 then the arming checks will check for that, and will prevent arming if you don’t have a good enough GPS lock and a fully initialised EKF.
If you want to fly anyway then you could fly it with ArduCopter instead (flying a tailsitter with ArduCopter is possible, although it has had very little testing), or you could fly in QSTABILIZE mode. In QSTABILIZE mode it won’t be dependent on the height estimate as the pilot has throttle control. It won’t fly as well as it would with good GPS lock as it won’t be using the EKF for the attitude estimate.
Do you have a test location where you can get good GPS lock?
Cheers, Tridge

thanks Rolf! it’s looking pretty good.
Paul and I discussed a few more changes we should make, though I probably will leave them for the next release in a few weeks time.

  • gain scaling for battery voltage
  • scaling of left control surfaces with left motor and right with right motor, instead of with average throttle
  • better handling of control saturation after gain scaling
    I don’t want to hold up this release though, so I expect to put this version out soon.
    Cheers, Tridge

Great idea! Maybe you can also consider this:

some more ideas:

  • reset des_alt to alt after transition, so it does not fall after it.
  • prefer pitch correction over yaw when both have angle error. So he wont correct for yaw error when pitch error is high.

Hi Tridge, concerning TVBS model.
All existent Exporter Plugins of Knife don’t work on my 2 different 3DMax Programs.
But in the Forum I read, that RF8 is able to import .FBX Files which can be exported directly from 3DMax.
Can you check, if the attached Sample is usable?
Note: You will have to change the file extension from 3DS to FBX (FBX is rejected)

Wing.3ds (32.5 KB)

Regards, Otto

I could load it into Blender as a fbx file, and it shows a wing. I then exported it as a 3ds file from blender, and ran 3ds2kex.exe on it, and got this:
File has no nodes.