@lorbass The BiWing.parm file in SITL_models has also been updated, so try loading those parameters first. Just copy the updated file to ArduPlane/Biwing then start up SITL and type (in the mavproxy console):
param load BiWing.parm
mavproxy will print out the changed parameters as it loads the file.
This post: Copter Tailsitters
shows a plot of pitch and motor outputs for transitions from FBWA->QHOVER and back.
It should never pitch down during the transition to QHOVER, but there is a large overshoot on transition to FBWA (nose down about 45 degrees) that I haven’t managed to eliminate. @losawing Any advice on how to adjust parameters to reduce that overshoot?
@lorbass Regarding your question on recording RealFlight SITL sessions:
To record the whole screen (about 1920x1080), I use Flashback Express 5 at 15 FPS with mpg encoding. I get about 120 physics FPS in RF8 this way, and it seems sufficient for the BiWing model. This is a flashback recording exported to mp4: https://1drv.ms/v/s!AhgZy5vN7uiNgS-6yIGovksdKbyV?e=M1nFuW
In this recording I had Q_TAILSIT_MOTMX set to 3 instead of 15, and motors 3,4 shut down in FBWA. The forward transition also loses a lot of altitude (more than with all 4 motors enabled in FW modes).
To record just the RF8 window without impacting the physics framerate (much), I use the XBOX gamebar app for Windows 10. The RealFlight recordings are also useful, (and I think have zero impact on frame rate), but must be played back in RealFlight instead of a video player.
try to reduce q_a_rat_pit_I.
RF9 received but not tried yet. I am building a new model for flying in my garden…
edit: @kd0aij, I was too fast, if it is an integrator problem the parameter is the fw one, I am not sure of the name, ptch2srv_I
edit2: do you still have +2° for the rear wing. It probably gives a downward pitching moment and the integrator need some time to compensate. Could you try -1° instead ?
The problem was partly due to low ptch2srv_p gain. Autotune raised it from .33 to .95
With the higher gain, the overshoot is only ~12 degrees and is corrected pretty quickly. The best way to fix that might be to reduce the pitch rate in the second half of the transition, but I’ll have to look to see whether that is already implemented in the FW controller.
Changing top wing incidence to zero or -1 degrees reduces the overshoot, but the plane then has a strong tendency to pitch up at high speed; needs a lot of down elevon to compensate and outside loops become difficult.
Perhaps RealFlight’s simulation of pitching moment (Cm?) is not very realistic?
Sometime the biwing is a little sluggish, I will try the FF parameter to see if it helps.
Today I tested
Auto mission with takeoff and landing: OK
QRTL from hover and FBWA with the biwing facing rally point or not: OK
normal RTL with q_rtl_mode=1: OK
Weather vanning was enabled and Q_wp_speed=10m/s
Increase Q_VELZ_MAX to climb faster in qhover. It is currently only 150 cm/sec.
Tailsitters often have problems transitioning to hover when in high-speed knife-edge flight. Since transitions from qacro to other Q modes are not automatic, you must take care to avoid that situation. The safest procedure is to switch from qacro to fbwa first.
Or you could just establish a hover in qacro before switching to qhover.
To recover from high-speed knife-edge flight in qstabilize/qhover, either switch to fbwa to level the wings, or pitch nose-down until the wings are level, then gradually raise the nose while slowing down.
Thanks for the quick answer. Something strange.
I use QHover and FBWA. I can’t fly in Acro and during this flight I put full Roll and it made a bank of 45°.
In acro it would have rolled more. No idea why in the log it markes Acro because in Ubuntu it showed QHover and FBWA. Will test it again.
You started off in qacro, then switched to qhover. Right before the crash you switched back to qacro while in knife-edge flight. Here’s what the end of the log looks like in Google Earth (qhover is the green line, qacro is yellow):
may be I’v posted the wrong log. Here the new one.
It needs more than 20m altitude to switch to FBWA, else it crashes even with full stick pulled.
Back to QHover is looses about 30 m and then looks in the other direction.
To update the master branch in your local git repository, open an Ubuntu bash shell and type these commands (I’m assuming you cloned the ardupilot repo in your home directory):
cd ardupilot
git checkout master
git pull
The ArduPilot developers have put a lot of work into the wiki to help people with getting started; take a look at this section: https://ardupilot.org/dev/docs/where-to-get-the-code.html
You might want to look at one of the graphical git clients for Windows or Ubuntu, but I don’t use them myself. For me, google search and the command line interface are the easiest way to get things done
Because I had difficulties with the Translation of the BiWing, I tried the Caipirinha2 where I know the truth about the behavior due to long experience in the field.
It was a good training to repeat all your instructions. With the Params in git it does not Hover and crashes in Roll. The reason is, RCOut 5 and 6 goes verry quick in saturation, e.g left to zero, right to full. And this is not enoughe to hold the balance. I worked the whole day with the Q_A_Rat_P, I and D. All physics in RF8 are perfect according the real wing. But in the reality I never hat issues about.
The Plane Mode is verry realistics and the Transitions without loss of altitude or same as in the field.
I set the Engine Power in RF8 from 100 to 120%, its better but not enoughe.
Did you order a controller or a Interface to your TX?
Just when everything worked, a Plastic-Part which takes the lever in center of the left Gibal has broken in several pieces without force. (exept spring)
The other has cracks too. May be due to the several crashes of the aircraft?
And to use the Interlink Controller as interface to a Taranis as described in the manual does not work.
I have no solutions, I can just share my troubles…
I spent some hours trying to get my turnigy 9XR to communicate with windows. Through USB the turnigy in boot loader mode is recognized and I can read eeprom but no way to set it as a joystick, boot loader mode or not
An other solution I found is to connect the trainer port to the laptop microphone plug and use smartpropoplus software. That seems to work on my son computer but not on my windows laptop. Drivers loaded again, still not work, It seems the microphone plug is dead. Again
I also have a spektrum DX7 and spektrum provide is a wireless dongle WS1000 or WS2000 to communicate with the laptop. That might be the best solution except the WS1000 is obsolete and the WS2000 not already available in France.
So for the moment I am still hesitating.
