I’ve been working on getting a quad plane to perform an auto mission correctly for about 8 months now and crashed 3 birds so far. It’s the same problem for all the aircrafts, when auto is selected the vtol climbs to the desired altitude, attempts to transition and then tumbles out of the sky right at the beginning of transition. It seems to prefer a backflip for some reason but it looks like the motors are just shutting down, interestingly the pusher motor was only activated in some of the log files but not all. I have plenty of log files from separate flights on different firmwares and videos as well. I feel like I have a pretty good understanding of all of the parameters by now so I must be missing something obvious or purposefully setting something up wrong. I’ve tested multiple firmware versions including the most up to date version.
I can confirm that it is not a hardware problem as in the attached log file I was able to regain control before the vtol crashed by switching into QSTABILIZE mode. I can also confirm that all the control surfaces are in working order with plenty of throw before each test flight.
At first I thought the culprit was setting the Q_ENABLE param to 2 instead of 1 since after make this change I had my first successful flight on a small scale airframe operating without an airspeed sensor. Unfortunately after moving to a larger airframe the issue returned even with that param set correctly.
This issue has been pretty consistent on multiple firmwares as well as on multiple pixhawks/gps modules and air frames. At this point I’m convinced it has something to do with the way I’m setting up the pixhawk, there must be an obvious parameter I have incorrectly set. I don’t think it’s as simple as a compass calibration that could cause this drastic of a failure.
I suspected it could also have something to do with how the mission was setup yet running the known working mission on the large scale airframes cause the issue to persist.
I’m currently running babyshark airframe with all custom wiring as well as setup, after asking them for advice they seem to think it’s because I am not using an air speed sensor. There’s definitely some merit to that but there’s got to be more to it.
I’ve attached the log file from the most recent flight where I saved the vtol before it could crash but if more data is required I can attach more log files as well as videos.
Thanks so much for all the help, really appreciate it.
Missions are not the thing to be using for your first transitions, Qstab to FBWA would be better. Symptoms sound like one of your control surfaces is reversed or the CG is in the wrong place for forward flight. (I have not looked at the log)
Hey peter, thanks for the quick response. If I’m being honest I’m not overly confident in my fixed wing piloting abilities as I’m primarily used to flying racing drones, that’s part of the reason why I’m attempting a mission right of the bat.
In terms of the reversed control surfaces, before each flight I’d lift the uav in FBWA and move it around to see how control surfaces react. I can assure you that they would all move in the correct direction to attempt to bring the vtol back to level flight.
The CG was set based on the images provided from the manufacturers website, it was also balanced before flight.
I agree with Pete’s recommendation. Always test the VTOL manually first.
I didn’t see anything obviously wrong in your setup file assuming you want it set up as a quadplane and not a tilt-rotor. Is this the VTOL you have below? You don’t need an air speed sensor to get this working. On the ground, in FBWA mode, with the flight controller disarmed, verify all the control surfaces and direction of compensation.
With ARSPD_FBW_MIN set to16, I would lower Q_ASSIST_SPEED from 16 to maybe 14. But this is not your problem.
I am a bit confused by your QGC mission plan but I am also not an expert on them. You have the following commands set up. You might want to verify that the second command is correct.
I might have to spend some more time in a simulator and get more comfortable flying this thing manually, and yes that is the vtol I have.
In FBWA mode on the ground all the control surface react correctly to attempt to stabilize the aircraft, I made sure of this before each test flight.
I’ll make those changes to Q_ASSIST_SPEED anyway, thanks for the tip!
This is a bit interesting though, what made it look like I was using QGC? I say that because I’m just using the mission planner in ardupilot. For the mission setup, I was under the impression that the VTOL takeoff command was only that and did not include a transition as well. That’s why the next command was to force a transition to fixed wing before heading to the first waypoint. Do you think the issue is that it’s attempting to execute two of the same transition commands at the same time?
Interesting, on my computer the mission file reads just fine for some reason. I’m starting to think this has something to do with mismatching ardupiloit versions. Since when I was in the process of debugging I was constantly bouncing between my laptop and desktop which I believe are running two different versions of ardupilot. Didn’t think creating a mission on one computer then using another computer to write the mission at the field would cause any problems but there might be something to that.
The “QGC WPL 110” is at the begging of all of my mission files when I save them to my computer, I’m not 100% sure what it’s indicating either.
After reinstalling the most up to date version of mission planner I decided to run some simulations. Using my params (minus the compass/accelerometer settings) I was able to get the SITL vtol to work as expected, I was unable to reproduce the issue however. Regardless of if I force an additional transition command or if I leave it as standard (Vtol takeoff --> waypoint) the mission proceeds as expected without any issue.
Wouldn’t this mean the issue has to be a hardware problem or a compass setup problem? I still find it hard to believe that a compass error could cause such a violent maneuver. I’ve attached a video of the flight to get a better understanding of what was happening. If you know anyone who might be able to identify what is going on here please let me know.
Also the QGC WPL 110 still shows up as the top line of the mission files so I believe it is just the standard.
Yeah it does look like that. The air speed doesn’t look like it was nearly high enough to perform a maneuver like that even with full elevator though. I can assure you the elevator commands were correct for both quad and plane modes.
I also forgot to mention that it’s accent was also pretty bad, toilet bowling quite a bit even though there was barley any wind that day.
On a side note, I’m also confused as to why the quad motors would stop leveling the vtol in the first place. Since there’s a minimum pitch angle as well as minimum airspeed that needs to be reached before the quad motors can shut down at all. According to the logs the motors were powered down well before either of those params were met.
Here’s another video of the same issue with much worse of a transition, this vtol was not so lucky… I have almost zero explanation for this transition behavior. My initial hypothesis was bad compasses and a pusher motor failure but that was not the case. https://drive.google.com/file/d/1I2LOwlYzRYw95-JPDQozMs-zFQZhbKPK/view?usp=sharing
I agree that something is not right. The quad motors should have kept the plane level longer. The video didn’t show what happened to the Baby Shark. Is it ok or did it crash bad?
Were you flying manually? It really looked wobbly on the second video but any Q mode should be much more stable. Can you post a .bin file of the video flights? How about some setup photos of the motor and prop rotations and the flight controller mounting? Even post the rotation and prop direction of the rear motor.
The first video is the video of the baby shark and it should be about 2:48 in duration, near the end of the video you can see the vtol landing safely. In the second video the larger mugin airframe crashed very badly out of frame, it was totaled so I’m trying my best to prevent that from happening again.
The entire flight in the second video was all an autonomous flight video, it is very wobbly throughout. When flying it in q loiter right before that video it is pretty well rock steady, I can provide videos of that as well. Don’t know what would cause such a drastic difference in flight characteristics between the two flight modes.
The bin file for the first flight is the same bin file attached when I started this thread, the second flight bin file is attached bellow.
I can send some photos later of the prop rotation as well as pixhwak mounting but I’m using the standard prop rotation setup as well as a clockwise rotating pusher motor. The pixhawk is mounted directly to the frame with the included double stick foam tape.
Ok, let’s keep the subject on the Baby Shark for now to make things more clear. Something is odd on your v-tail setup…maybe. In the graph below, I have the v-tail outputs on RCOUT.C11 (in red) and C13 (in green). They both peg before the pitch (in blue) starts going up…possibly suggesting a reversal on the flight controller compensation.
Below, the front motors, 1 and 3, seem to cut off first, which is understandable if the back has dropped and the front is too high. My second suspicion is that the VTOL is in some strange mode. I would prefer to see a simple test where you go from QSTABILIZE mode to FBWA mode and back. I don’t think that you can screw up flying it worse than what is currently happening. Keep it high for the transition. You are doing great on the copter flying. Who knows, it may just fly and you can change it back to QSTABILIZE after a few seconds.
Would it be possible for a separate parameter to trigger a pitch reversal? I know the data is strongly pointing to a pitch reversal but when compared to my other flights this one is the only flight that seems to agree with that hypothesis.
The graphs do make it very clear that its desired pitch was to remain level and external factors were causing it to flip.
I might be forced to fly it manually and you might be right, can’t be worse than a backflip haha.
@GregCovey It reminds me what your Ranger EX conversion was doing. I don’t remember if you ever resolved that. Just from a casual observation, it seems like there’s not enough “ramp up” time for the pusher motor to gain speed so control surfaces can be aerodynamically effective. As you know I’m not an ArduPilot user but I usually have a minimum of a 4-second ramp up time (I had one I setup for 6 sec) before the quad motors start blending down. I hope this can be sorted out.
In terms of the ramp up time I don’t think there’s a param for that specifically, I’m aware of Q_TRANSITION_MS (which is set to 4s) but this is for time after the minimum air speed is already reached, not necessarily how long it takes to reach that speed. There’s also Q_TRANS_FAIL(set to 20s) which is the total amount of time allowed for a transition, if the minimum air speed is not reached within that time it goes into Q_land.
It was in auto mode when the tail dropped, I switched modes as fast as I could after I noticed it start to flip.
If I were to try to transition on the ground with no props, starting in Q_stabilize then flipping into FBWA theoretically the quad motors should never turn off right? Since it’s below the minimum speed and q assist altitude. It might be useful to see how the control surfaces will react as well.
Yes, I get that. What flight mode is AUTO mode in?
On the ground, you need to stay disarmed or crazy things happen with the speed estimator. You can test the control surfaces in QSTABILIZE or FBWA mode while disarmed and pressing the safety switch. You can also test your forward flight motor while armed in manual mode.
All Q_ASSIST values should be disabled on your initial flights.
You asked me for a second opinion via PM, here it is:
As Greg already recommended, you should first check if your parametrization is able to successfully make a transition from QStabilze to Qhover to FBWA. Therefore, if I understand correctly, you have never performed autotune nor checked the behavior in autothrottle modes ? If so, please find someone to do it for you, better do it yourself. The problem will certainly lie in the interaction of several unfavorable factors that you will not get out top down.
One factor (which is not sufficient, but can contribute) is that you have the throttle set to zero during the automatic flights. This alone leads to the fact that the airplane sinks violently at the beginning of the transition in auto mode with enabled Throttle Nudge, as recognizable in your first log file.
If the manufacturer has already pointed out to you that you do not have an airspeed sensor (which is not mandatory, but makes things easier) why do you still have 2 airspeed sensors parameterized, although none is connected ? Even if it will not be decisive, for people from whom you expect that they look through your logfiles, this is an imposition.
I think the errors will be found if you first make a transition to FBWA with the remote control. But without knowing how the aircraft flies in FBWA and how it behaves in autothrottle modes, it’s like to read Coffe grounds.
