I love this! With the sub-version numbering, Mission Planner/QGroundControl now know that there is categorically a new update and pops up a prompt when I connect to the plane.
Previously they would show multiple updates with the same version number, with nothing to distinguish them.
In this case I know I don’t need this update for what I’m doing. Thanks!
Dears
Pitifully, I crashed my quadplane yesterday. I am very interested to discover the causes. The problem occurs in the last part of the landing process. I tried the new QRTL mode 3 (Q_RTL_MODE = 3), with the last firmware 4.1.4. As you know in the new method exists the “airbraking” phase in order to make a fix wing approach.
The plane reached to ALT_HOLD_RTL (65) in good shape, made the first “airbrake” to 80m from home and altitude to 34m ( v=18.1 d=80 sd=81 h=33.8), at this moment the forward motor begin to stop. The Q_RTL_ALT parameter was defined at 20m, but the plane maintain an altitude of 30m for a few seconds. The problem occurred when reaching the VTOL POS1 position (v=16.8 d=49.7 h=32.2 dc=14.0); The plane pitch down suddenly. As you see in the next graph the nose was down all the way (behavior channel C2 and C4, Vtail). In the same way, the quad motors were activated, the front ones (channel C5 and C7) push higher in order to do a final “airbraking”, I think. But the inertial was too high and the plane go strain to the ground. I tried to change to QHOVER mode in order to get out manually the situation but was not enough. The plane crash to the ground at 23m/s, the plane is destroyed.
Here is the time when reached the VTOLPOS1 position and pitch down the nose.
One last detail, when I made the mission I forget to change the command TAKEOFF to VTOL TAKEOFF and RETURN TO LAUNCH to VTOL LAND. The takeoff process was as VTOL, without issues, but the landing was a disaster.
Maybe can improve the Mission builder process, due to VTOL command only being enabled when the quadplane is connecting to MissionPlanner. So, if you work your mission in the office you cannot complete the takeoff and landing part.
Here are my BIN data, hopefully can review it and give me some clue about source of the problem.
can you upload the bin log so I can take a look? (I think you accidentally only uploaded the parameter file)
So sorry, I updated my message, now it is ready. thank
Hello Tridge, Thank you quick answer. I update my message, the BIN are ready now.
You can see what happened in this graph:
Hi Tridge
I realized that behavior but never thought that quad motors can fail. Never happened that in the past. But It is true that the current consumption is not expected. I am not sure if the Quadmotor started, all was so quick, but the propellers of the front motors were broken, So I thought that they were rotating. About my quadmotor system:
Motor: T-motor F80 pro KV1900
ESC: Cobra MR30-FPV
The aircraft weighs around 2.5kg.
Thank
Hi Tridge
I wonder if the parameter THR_SLEWRATE can affect the response in this state. I used the value 55 in order to reduce the power request from the battery. What do you think?
no, THR_SLEWRATE has no impact at all on VTOL motors.
you definitely had a hw failure of some sort. The PWM values logged as going to the ESCs should have had them spinning the front motors at nearly full throttle.
Ok…I will change the ESCs, and motors too. And test it, with another plane…thank you so much.
I expect this beta to be out for about 1 week
Happy flying!
Hello!
There’s a bug in vtx control functionality.
I’m using switch to choose power between 25, 800 and MAX
The problem is when I set max power with a switch, in 1 sec in automatically switches to 800 mWt
(yes, my switch is configured to be 25 mWt at lowest position)
Thanks and regards.
@tridge can you add a parameter that will disable tuning D when auto-tuning? I found is that on small aircrafts, it seemed to me from D there is more harm than good. Therefore, I would like to check autotune without D
Would it be possible to include in the next point release the parameter LINK_Q_EN to show Link Quality in the OSD?
Thank you!
if the " * fixed reset of ground steering lock for landing" is what i think it is (rudder kicking hard on landing approach problem), that is big for me.
i will looking forward to this one becoming “stable” so i can update.
Happy flying!
I’ve recently started getting this weird bug where whenever the FC is onboard logging the missionplanner and the yaapu telemetry keep throwing “Bad Compass Health” errors. With the default LOG_BITMASK I can successfully arm, but as soon as I do I start getting “Bad Compass Health” as it begins logging. If I set LOG_BITMASK to 0 then I stop getting the errors. I can even have the plane armed and actively giving the error, and as soon as I write the parameter of LOG_BITMASK to 0 I stop getting the errors. Conversely, if when disarmed I enable LOG_DISARMED I start getting the messages as soon as I write the parameters, and can’t arm so long as LOG_DISARMED is enabled and I’m getting the messages. The real kicker is when I look at the onboard logs afterwards, Mag.health has a value of 1 for the duration of the logs!
I’ve seen this behavior in 4.1.4 and 4.1.5 on a Matek F405-Wing, but only recently started with ardupilot so didn’t get a chance to see if this happened in earlier versions.
@Didymo I can’t immediate think of a cause. Can you post a tlog from the GCS for when the problem is happening?
@tridge Yep, here is a tlog which shows the basic behavior, but not the effect of writing the parameters because that was done over several other tlog sessions.
https://drive.google.com/file/d/1WJYm4p5WogVHqukT2uV5OdtYjJxcKw6u/view?usp=sharing
