what’s happening is when the airplane accelerates = more airflow… the elevons work more and the system senses it and corrects with tilt and elevons, drops the nose and does it, again and again, you have too much elevon but easy to fix by reducing elevon throw till it stops… probably less than 1/2 that you have now… it will still have enough control because you have motor tilt and that is very powerful. with my setup, the elevons work to keep the wing parallel especially in yaw… watch the video in roll/yaw
also, the flat spins are caused by the t/e moving up faster than the l/e with lots of induced drag from the overcontroled elevons with no airspeed and no rudders…no yaw control= flat spin
If I am correct, your flat spin issue begin around line 95. As far I understand, the yaw follow what the pixhawk demand. The pitch is an other story and I dont understand why the pixhawk demand 0 pitch from line 96.
Also at the beginning of the log there is a message concerning compass (switching to compass 1 then to compass 0) I have never seen before !
Are you sure that all your calibrations are corrects ?
While flying do you check EKF status ?
Can we get your parameters, it seems to me that there is not enough authority from your vector thrust. what throw do you have ?
Yeah, not sure exactly what this is about, I get “BAD AHRS” messages until I get a message that says something like IMU is using GPS0 then all errors go away. I thought I was in the clear
I believe so.
No, how would one check, and is it not available in the log after flight?
Bad AHRS is a very bad warning. You must not fly with it. AHRS means attitude and heading reference system. I saw on your log that your HDOP GPS is very good so bad AHRS is likely a compass related problem. If you are allowed to arm with bad AHRS, it means you have disabled arming check. You should not do that. Onboard compass calibration is more reliable that former offboard calibration, I suggest to make it again also with the wing pointing upward. I have struggled a lot against this AHRS warning but for me it was a GPS issue (HDOP >2) due to RSSI of my frsky rx connected to SBUS input of pixhawk. As a general requirement, locate your rx (even more if it is a rx with telemetry) and any EMI source as far as possible from your GPS/Compass.
You can check EKF status by clicking on EKF in mission planner HUD. It will pop up a window with 5 gauges. If one of them turn red, this is very bad.
I will have a look at your parameters this evening.
Power sag saw by tilt can be the result of bad AHRS too.
Yes, upon further review I guess only 2 of the 4 flights I’ve posted resulted in “spin” and the other 2 resulted in more of a “tumble”
I’ve made a few successful transitions, every time it feels like the motors stop and wait for the nose to come down, then the elevons catch it. That transition was the first with elevon output halved using ServoN_min and Max (Is there a preferred way to accomplish the elevon output halving you suggested) Weather is looking bad for 2 days, but will attempt again on Friday.
I have all prearm checks on, which leads to another post Ive made, with a different concern.
Maybe I wasnt clear, the Bad AHRS message goes away and the prearm checks pass as a result of a message “IMU using GPS0.” I assumed this was normal startup procedure.
Thank you very much! I look forward to any findings.
of course, you realize that falling backward with no power could be the root of all the transition problems, the reduction in elevon throw will help but more with the galloping forward flight
being a hardware guy a simple linkage adjustment is my preferred method, and may not need to be as dramatic as first thought…how is the handling in hover? also looks pretty loose in the yaw department, Losawing could probably help more in that department
I have had a look at your parameter.
-regarding AHRS
Your pixhawk is rotated 270° and your external compass rotated also by 270°. Right ?
-regarding EKF, The right setting is
EK3_ENABLE = 1
EK2_ENABLE = 0
AHRS_EKF_TYP =3
-regarding Q parameters
Q_VELZ_MAX is way too high, reduce it from 250 to 100 or less. I think this the most important of all.
Q_A_rat_yaw_P is low, increase it to 0.3 and more until you get oscillation or pumping. I have 0.4. This may improve a lot the loose behavior in yaw Tilt talked about.
Q_A_RAT_YAW_D is 0. I suggest 0.01 not more. This may help to increase the P term.
Q_A_ANGLE_PIT_P is 8, default is 4.5. Why to change ?
Q_M_THST_HOVER is 0.35. It means your wing is over powered. Right ? This value is used to scale the PID, so if your wing hover at 0.7 and not 0.35, your PID are reduced.
Other rates are not very different from mine.
-regarding fixed wing
ROLL2SRV_P and PITCH2SRV_P are 0.6. I think this is too high and might be responsible of oscillations we can see on your video. I have 0.3 for both. Autotune works fine for tuning the fixed wing.
Also, during your next flight, have a close look at the EKF gauge status to be sure that you do not have a EKF issue.
I agree it would be clever to have a list of relevant parameters because there are so many…
regards,
Pierre
Same issue as above. My compass will fail calibration when I change compass relative to FC. Right Now my compass is relative to Aircraft: none, Relative to FC: Yaw 90.
Here is another flight that with your suggestions:
hello travis,
This is not easy but this is the reason why it is interesting.
Firstly I am about my knowledge limit so I am not sure to be very helpful.
At least we know EKF is not happy as compass gauge turn red from time to time and other gauges too. The first thing is to fix this problem as it is the root cause of unstable flight. We have a doubt about compass orientation. Tridge propose a method to test the compass orientation in post 138. Post 138 was an answer to tilt, I hope he has the solution, personally my pixhawk is parallel to the plane… Last week when I looked at your parameters I saw that your compass 1 offsets are close to the limit but within the spec according to the rule :
In Copter-3.2.1 and later offsets are considered acceptable provided their combined “length” is less than 600 (i.e. sqrt(offset_x^2+offset_y^2+offset_Z^2) < 600).
But I saw that your compass 2 offset was out of spec. Normally does not matter as compass 1 is selected.
About fixed wing: the flight is even worst so my advises were bad. Hopefully this is an unmanned plane and nobody was hurt. Again it can be an EKF issue or a CG issue. A CG at 15% of mean cord is a safe value to start from.
About hover flight: still very very sluggish… I remember now that you fly Q_stabilise. Q_hover is much better to test the wing as vertical speed is limited by the controller, but this is not the problem.
Where is the best place for discussing implementation of quad-motor tailsitters?
I appreciate this is the dual motor forum, but currently the tailsitter code only supports this configuration (frame types appear not yet implemented) and this thread has the attention of the tailsitter experts.
I am looking at extending the code so that a custom tailsitter quadmotor airframe (already constructed) can fly with ardupilot. I have established a github thread here https://github.com/ArduPilot/ardupilot/issues/7852. I am an aerospace masters student with programming experience, so I am happy to implement this myself, but I would appreciate your thoughts/suggestions.
Apologies again for posting here if slightly off topic.
Hi guys, I am struggling with simulation of tailsitter in SITL + FlightGear.
According to documentation I tried to run FG by running “ArduPilot/Tools/autotest/fg_plane_view.sh” and executed following simulation “sim_vehicle.py -j4 -L KSFO -f plane-tailsitter --console --map”. The problem occur during arming, with Gyros inconsistent error msg. If I understand it well the parameter -f defines only frame but the model of the plane is selected directly in fg_plane_view.sh. So I guess that problem is that I am using params for tailsitter but with Rascal110 model. Can you help me where to find suitable models, or how to handle it?
regards,
Jiri
You are right, the dual motor tail sitter code does not support other configurations. I think you have to open a dedicated discussion. I already have a quad running arducopter, I would be happy to attach a depron wing to it and test your code. A dual motor tailsitter is basically a plane that rely on its own stability and equilibrium as a fixed wing. As a copter, a 3D plane with a single motor and an efficient rudder will fly with the same code. What you want to do is a totally different logic as it will rely on differential thrust whatever the mode. It will be probably difficult to get the right attitude as a fixed wing. An airfoil give positive lift provided its has positive pitch within roughly a ± 3° range so I can imagine the pitch attitude will have to be very accurate.
Hi, I have been building a VTOL aircraft to fly with a companion computer (a raspberry pi and a pixhawk 2.1). I have recently changed the configuration to a vectored tailsitter but cannot find any documentation for guided modes. Is this currently available?
