Plane 4.3 stable release

Aha! So a big problem here is my compass(es). I had wondered about that. I really don’t understand how it can be the motor because it’s a twin with both motors and ESC’s out in the wings - ah the wires, that might be it.
I’ll take another look at that. Ta!

1 Like

4.3.3beta1 flights with 2 airplanes (QUAD VTOL, Mateksys F765 and fixed wing, Mateksys H743) in QHOVER, FBWA, AUTO, QLOITER, CRUISE, MANU and scriptgenerated Waypoints no problems at all.
Thanks to Tridge and other developers.

Rolf

2 Likes

Here’s another screen shot of the MagFit screen from Ubuntu 22.04 running on a new install on bare metal. I’m running MAVExplorer.py 1.8.59 from a clone I took direct from GitHub on the weekend. Also python 3.10.6

thanks Rolf! much appreciated


I’ve just released plane 4.3.3 stable. This is a minor release, and likely the last of the 4.3.x releases unless a serious issue is found.
Changes from 4.3.2 are:

  • AIRLink LTE module enable pin added
  • CUAV Nora/Nora+ bdshot firmware (allows Bi-directional DShot)
  • CubeOrange, CubeYellow gets fast reset of ICM20602
  • PixPilot-V6 support
  • Attitude and Navigation controllers use real-time dt (better handles variable or slow main loop)
  • Analog rangefinder GPIO pin arming check fixed
  • Arming check of AHRS/EKF vs GPS location disabled if GPS disabled
  • Position Controller limit handling improved to avoid overshooting and hard landings
  • PSC_ANGLE_MAX param reduction causing WPNAV_ACCEL to be set too low fixed
  • Servo gimbal yaw jump to opposite side fixed
  • Siyi A8 gimbal driver’s record video feature fixed
  • SToRM32 serial gimbal driver actual angle reporting fixed (pitch and yaw angle signs were reversed)
  • Takeoff in Auto, Guided fixed when target altitude is current altitude
  • Takeoff in Auto handles baro drift before takeoff
  • Takeoff twitch due to velocity integrator init bug fixed
  • moved FTP MAVLink transfers to FTP thread and better control bandwidth
  • switch to QRTL if indide RTL radius when using Q_RTL_MODE=3 (approach)
  • check for 3 good frames for CRSF
  • allow for ELRS at 420kbaud
  • support MambaH743-v2
  • support MambaF405-2022B
  • fixed nullptr checks on new
  • fixed a bug in terrain handling for ship landing lua script checks on new

Many thanks to the following people for contributing to code, documentation and testing of this release:

Happy flying!

6 Likes

Tim Tuxworth tim@objectivedata.com tim@smartfleet.systems - thanks @tridge !

So finally if a qplane has a failsafe inside RTL radius will not perform transition and will remain in quad mode isn’t it?

yes, I know this has been wanted for a while, sorry for the delay

More than wanted, was a safety concern. Thanks again for the fix :slight_smile:

Will it do that even if Q_RTL_MODE is not 3 (approach)?

If not, I don’t think the feature request/safety concern is addressed.

When returing from the AUTO mission we are not using QRTL, only manual flying in FBWA and QSTABILIZE mode.

Battery failsafes have caused seriously dangerous situations in past. I will be disappointed if that is still the case. Have not tested yet.

I tested the 4.3.3 firmware on the Pixhawk V6 platform and everything works fine.

I tested the 4.3.3 firmware on the FMU V3 platform, and there was a problem in the automatic landing stage.

It is normal before it is automatically lowered to Q_RTL_ALT. It started to oscillate back and forth around 15 meters, and I don’t know why. I’ve flown a few times with the same problem.

I don’t think it’s a PID problem, I use q_loiter to test the attitude is very stable.


00000003.BIN.param (21.5 KB)

Below is my flight log:https://drive.google.com/file/d/1KB90fNi6mlNRACoefA1HIBeAKGm8SGoG/view?usp=share_link

Tested firmware version 4.2.3 on the same platform today and landed smoothly.
In the 4.3.3 version firmware, the problem of shaking during the automatic landing stage did not appear.

Today I was visited by the Guardian Angel of Radio Control.

https://drive.google.com/file/d/1xqcluucTIJvGcW6Q_NLZ1Qt3op1htz-H/view?usp=sharing

I had been flying for about 10 minutes without any problems. At some point I switched to cruise (all fine) and shortly after I decided to push the throttle to full throttle.

At 14:10 I started to lose altitude: red (barometer) and blue (TECS). The system (TECS) is aware of the desired altitude (green).

The TECS detects the negative vertical speed (red) resulting from the loss of altitude and therefore the demand (purple) is positive.

Despite having the elevator control down (yellow) I have hardly any authority… it continues to descend.

The roll control (red) does have authority (blue).

Despite fully down throttle (yellow) the engine is still at 100% (red)… and going down.

According to the barometer I escaped the disaster by 1.02m and according to TECS by 2.85m.

Here the crash was avoided (14:25) but this is still going on.

20’’ later I was still with the throttle control at zero and the engine at full throttle. To scare me, right?

I decided to switch it to RTL without any appreciable result and at the end I switched it to FBWA; everything was back to normal.

I would be very grateful if you could tell me what could be happening.

I have made a TREMENDOUS MISTAKE:

TECS_PTCH_FF_FF_K=-0.6

when it should have been TECS_PTCH_FF_K,0=-0.06

To devs attention, please review my issue, it could be a very bad tecs malfunction:

Is it possible that the TECS.iph bug is back?

I repeat, there was a wrong setting of TECS_PTCH_FF_K=-0.6 instead of TECS_PTCH_FF_K=-0.06.

@tridge we had a loss of a plane today due to an internal errors 3000. This was a new CubeOrange+, Mauch power supply, 2x iFlight BlHeli ESC’s, SDP3X airspeed sensor, Here3+, and LightWare SF30/C. After the 2nd takeoff and turn to the first waypoint, I looked at Mission Planner and saw INTERNAL ERROR, DISARMED, and (SAFETY) in the air while in auto mode. I had no ability to gain control with mode changes as safety disables our servos in the few seconds before impact. In gathering information, I also noticed POWR.VServo appeared to drop to significantly lower values a few seconds before this catastrophy.

Log here: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

0x3000 indicates iomcu reset + iomcu fail, which seems pretty bad

Unsure if it’s related, and I haven’t dug into it, but I’m rather certain that I saw automatic disarms on the ground just a few seconds after arming in FBWA and maybe even Manual mode. I was assuming due to a safety switch (that parameters were set to disllow changes while armed). I’ll search for logs.