Today while testing a new VTOL it disarmed during the transition. I’m not entirely sure what happened, but directly after the disarm, it started a calibration of some sensors while connecting and disconnecting from the drone. I had full manual control of the ailerons and elevator (no motors since it was disarmed) the whole flight though and I was able to bring it back in for a belly landing after the motors refused to rearm. Can someone help me analyze the flight log? I’ve been trying to use the Matlab flight analyzer script, but it doesn’t seem to want to load properly.
Here is a link to a video of the crash as well as all the flight logs: google drive link
As you can see, it disarms shortly after the main motor turns on, and it drops like a rock. One of the videos goes very in-depth about the flight plan before we took off, but I’m not too sold on that being the problem. It might reveal something wrong that we did though.
Why did it start at -30 deg? following that, you had oscillations in roll. Maybe something wrong with preflight calibration or some hardware fault. The video mentioned 60m desired height. However, the desired height is achieved as 120m. Maybe something wrong with the mission.
That was a soft crash though. You are lucky.
However, you should have been running the latest firmware.
Thanks for the response, I appreciate you taking the time to look into this! This is how we received the drone from the manufacturer, if we update the firmware, will it affect the parameters?
For the desroll, I am not sure why it started at -30 deg. we did notice the ailerons moving up and down slightly while it was on the ground, about one time per second. once the plane was ascending, it did continue the same pattern. I think in the video you can actually hear one of our team saying it was oscillating in time with the servo movement earlier.
As for the mission, we controlled the drone using QGroundControl on an H16 controller. There is a slightly longer video in that folder where we documented the whole mission and all of the flight settings if you want to check that out. We passed that over to the manufacturers and they couldn’t see anything wrong with it. What is strange is that we had the takeoff altitude set to 60m, with a takeoff in the direction of the mission. our first waypoint was into the wind at 120m. it seems to hover up to the mission altitude, then transition facing the wrong direction, eventually turning around to face the first waypoint.
Also, we were talking to someone else who mentioned the voltage of the cube dropping to under 5v during the transition. Could this be caused by a wiring issue, or would this also be something potentially affected by the out-of-date firmware?
Again, thanks for the help, I really do appreciate it. A lot of this stuff is very new to me.
Yes it might affect the parameters and you might have to change some things as well. Better to ask the manufacturer to provide an update.
Yes i could hear it and heard someone say it on the video as well. However, in my opinion it shouldnt have started from -30. Desroll is the desired roll. The actual roll is what the aircraft has achieved. It might have something to do with the vehicle being moved while it was being started up.
Unfortunately i am also a beginner like you. This might be answered by someone more experienced. However, I can tell you that the aircraft was trying to achieve the height of 120m and it did achieve that.
Not caused by firmware. It did go below 5v but not by a lot. I think it went to 4.9 something volts. I have not seen my cube brownout at this voltage. It does happen with the voltage sag that is experienced at high current draw.
Thanks for the honesty lol, although it does sound like you have a fair amount of experience with the Cube, at least a lot more than I do.
Do you think that the desroll issue on takeoff could have anything to do with why the tractor motor turned on as soon as it was armed?
Regardless, I think I am going to try and update the firmware on everything, after saving all the parameters independently. Also, I’ll be recalibrating the compass and IMU. If the worst thing that happens is that I have to glide it in for a landing, I am ok with that, I just didn’t know that would happen, so I spent half of the descent trying to activate QHOVER or get it into FBWA. I’ll have a better runway scoped out for the next flight.
Do you think it is at all possible that the cross-compatibility between QGC and Ardupilot is causing any issues?
It is possible. Tractor motor is turned on in quad modes only if weathervaning is active. Weathervaning as it can be explaiend by the docs turns on after a certain height is achieved.
So it is either that the plane thought it was already at a certain altitude above ground or there was something wrong with preflight calibration. Preflight calibration is a step which is carried out when the plane is turned on where it calibrates all the sensors. It is recommended that the plane is not moved at this time.
There is also something else. When you open the log in mission planner, the plane is initially in guided mode when auto mode is engaged. That is also a red flag.
You could not have armed mid air because of preflight checks. Without arming, you wouldnt have any access to qhover or fbwa modes.
To tell you the truth, i think that before you go on to auto missions directly, go to the ardupilot quadplane docs and follow them to learn quadplane calibration procedure and going on to first flights. Your work might have already been done by the manufacturer but at least you would be familiar with the craft you are flying. This is also a safe approach as you craft you are flying must at least be 7 kgs and unsafe operation might lead to damages.
I think This is something to do with QGC. i was trying to wrap my head around this also. Even in latest QGC , VTOL take off is buggy or unclear. I’m also using the H16 controller. Try with mission planner.
Or maybe have to take off in Qhover mode manually and switch to auto. Not sure though
This ended up being the main issue. Because we were sent an outdated version of QGC (3.5.4) by the manufacturer, there was an error that prevented us from clearing the flight by hitting the “clear flight” button when prepping a new flight plan. After playing around with it for a while, we hit the “clear and upload new flight plan” button. the flight plan uploaded just fine and didnt throw any errors, so we thought we were in the clear. apparently, it was trying to run both missions though, which is why it started out in Guided mode with the prop on and oscillating and crashed the IMU almost immediately when it began the mission. Good catch on seeing the guided mode and the desroll.
we have since written this plane off as a learning experience. We opened the parameters and saw that there are tons of issues with the parameters that were on board. the drone probably would have crashed even without the problems with QGC. For example, flight speed was set to 1m/s faster than stall. the battery was input as a 5300mah, we are flying a 22000mah battery. there are more issues, but those stuck out to me the most as the biggest indicator that we would be needing to start over. After gaining more experience with Mission Planner and QGC on other (smaller) models, I’ll be trying to build this one up from scratch with the correct parameters.
It took us long enough, but we finally figured out how to use the TCP connection to a laptop running mission planner to create missions. IMO QGC is not far enough along to offer adequate support for planning missions for VTOLS inside its own app. Even running the most recent version of QGC, it registers the aircraft as a fixed wing, even though it is recognized in Mission Planner with no issues. My opinion is not worth that much, but I would recommend using Mission planner on the TCP connection instead of trying to force your way through all the error codes and problems cause by using QGC natively. It seems to work very well for us on the H16 and MX16
You can set Q_MAV_TYPE to 20. Then QGC will identify it as Quadplane.
Btw did you try to create a mission with new QGC. It doesn’t let me define the transition direction. I’m also trying to do my maiden flight. Hopefully this weekend.
Can you kindly know if you have tested it with new QGC. And if there’s no abnormalities…
Thank you
Also never trust those manufacturer claims. Its never plug and play. Unless you buy E bee , wingtra or Quantum UAVs.
You always have to double check and follow the wiki instructions. Like for my airframe I got this old parameter file which is not compatible with the newest version of arduplane. And with pixhawk Cube orange I can’t run old firmware as well. So have to do it from the beginning.
for some reason, we are running into the same issue with not being able to set the transition direction. it pins the takeoff and transition points together. If you really want to use QGC I would recommend placing a waypoint in the direction you want to transition, at an altitude you want to transition at. we found that it would just hover to the altitude of the mission, regardless of takeoff altitude, and transition in the direction of the first waypoint if we did the planning in QGC. I would recommend using Mission planner through the TCP though. it is much easier and everything runs a lot smoother.
