Plane 4.1 stable


I’ve just released plane 4.1.4 stable. This is a minor release with some important bug fixes and small number of new features.

  • fixed RC parachute release to only trigger on RC input channel above 1800, fixing an issue with trigger on power on
  • added QRTL flight mode as an RCn_OPTION
  • display VTOL position1 state change when landing approach and airbrake logic is disabled using Q_OPTIONS
  • limit Q_VFWD integrator to be below TRIM_THROTTLE to prevent very high forward throttle building up in some landing approach conditions
  • fixed an issue with high position1 landing approach target speed causing the nose to dip when going between VTOL approach and position1 states
  • allow for a wider range of Q_A_THR_MIX values to be configured, to better support landing quadplanes in high wind

Happy flying!

6 Likes

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!

1 Like

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.

ParamMinitalonVtol_v10_Tmotor_firmw4_1_4.param (20.8 KB)

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:


ArduPilot put full throttle on the front two motors, and dropped the rear two motors right down, yet the plane kept going nose down. At that point there is nothing more the autopilot can do, it already has maximum pitch up.
I’m pretty sure your front motors did not spin up on the landing. You can see that from the current draw, comparing the takeoff and the landing.
In the takeoff we can see this:

you can see that the current draw (red line) was around 65A when the 4 motors were at 80%. Now look at the landing:

we have 2 motors at 100% and the current draw is under 10A. That is impossible unless those motors have failed to start up.
All you could have done is to switch to FBWA and try to fly it out as a fixed wing, then try the landing again and hope the front motors spin up properly on the 2nd attempt. I know it is almost impossible to think of doing that quickly when something is going wrong.
One of the things we’re working on is to automate this for aircraft that have ESC telemetry so we know the RPM of the motors. We will have an option to automatically abort the landing and try again if one or more motors don’t spin up correctly.
What type of ESC were in the plane?

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’ve just released plane 4.1.5beta1. This continues the small updates to the 4.1.x series as issues are found and fixed.

  • fixed switching airspeed sensors based on EKF3 affinity
  • added servo voltage pin on CUAV-X7
  • make 2nd reduction of P gain in AUTOTUNE smaller
  • fixed a bug causing the wrong max throttle to be used in takeoff
  • fixed fence count on upload from old fence protocol
  • fixed reset of ground steering lock for landing
  • reset VTOL takeoff if not armed
  • fixed 16 bit timer bug on MatekH743
  • added FETTec onewire ESC support
  • set slew rate to zero while in QUATOTUNE twitch
  • fixed rate of notch filter to follow configured rate

I expect this beta to be out for about 1 week

Happy flying!

4 Likes

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.

1 Like


I have just released plane stable 4.1.5. This is a minor release with some important bug fixes and small number of new features.

  • fixed switching airspeed sensors based on EKF3 affinity
  • added servo voltage pin on CUAV-X7
  • make 2nd reduction of P gain in AUTOTUNE smaller
  • fixed fence count on upload from old fence protocol
  • fixed reset of ground steering lock for landing
  • reset VTOL takeoff if not armed
  • fixed 16 bit timer bug on MatekH743
  • added FETTec onewire ESC support
  • set slew rate to zero while in QUATOTUNE twitch
  • fixed rate of notch filter to follow configured rate

Happy flying!

6 Likes

Great work @tridge and all developers… I like to test this version… Thank you…

1 Like

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?