Nose level or 5 deg up…
I’ve just released plane 4.4.0beta3. Changes since beta2 are:
Flight controller specific changes
- Holybro KakuteH7-Wing support
- JFB100 external watchdog GPIO support added
- Pixhawk1-bdshot support
- Pixhawk6X-bdshot support
- SpeedyBeeF4 loses bdshot support
Camera and Gimbal related changes
- DO_SET_ROI_NONE command support added
- ADSB sensor loss of transceiver message less spammy
- AutoTune Yaw rate max fixed
- EKF vertical velocity reset fixed on loss of GPS
- GPS pre-arm failure message clarified
- SERVOx_PROTOCOL “SToRM32 Gimbal Serial” value renamed to “Gimbal” because also used by Siyi
- SERIALx_OPTION “Swap” renamed to “SwapTXRX” for clarity
- SBF GPS ellipsoid height fixed
- Ublox M10S GPS auto configuration fixed
- fixed memory corruption bug with scripting restart
- added LP5562 I2C LED driver
- added IS31FL3195 LED driver
- added QUIK_MAX_REDUCE parameter to VTOL quicktune lua applet
Plane specific changes
- fixed takeoff mode to ensure climb to takeoff alt before turning
- fixed error in quadplane wait for rudder neutral
- improved handling of forward throttle during VTOL landing
- fixed TECS state reset in VTOL auto modes
- fixed early exit from loiter to alt
- fixed display of started airspeed wait on forward transition
QGC keeps throwing this error when a board first boots. I can’t be sure when this started happening but it is new and definitely happens with 4.4.0 beta 3. It doesn’t seem to happen with MP, but not sure if that means it’s a ArduPilot problem or QGC problem.
@timtuxworth that is surprising as I don’t think there are any mission changes. Maybe this is a change in QGC?
I flashed 4.3.7 and this issue went away. Re-installed 4.4.0 beta 3 - problem came back. I’m enclosing a LOG_DISARMED log from a reboot after putting 4.4.0 Beta 3 back on the FC. The QGC, cables, USB ports etc where all the same, the only thing that changed was the AP version, so …
what we’ll actually need to diagnose a GCS interaction like this is the tlog, not the bin log. Could you see if you can find the tlog on the device running QGC?
We should be able to look through the tlog to find what operation is failing.
This problem is still unresolved…
With 4.3.7 y 4.4.0beta3 releases > the error also appears
Hi. MatekF405-TE-bdshot, FC MatekF405-VTOL, The configuration of the aircraft VTOL is 4+1 motor. Only three motors work on Servo 1.2 and 4.
ESC configurator also sees only ESC 1.2 and 4. With a rollback to version 4.3.7, all motors work.
@Aticof can you please set LOG_DISARMED=1 to get a log while you have the issue and we can try to work out why
If you have a log with LOG_DISARMED=1 with 4.2.2 not showing the issue that would be good too, and would help us determine if there is an actual change of behaviour or that we are just being stricter in the check now
@tridge Looking forward to the ArduPlane 4.4 stable release. Any planning time now?
Doest it mean CUAVNora AND CUAVNora+? I have two Noras (non-plus) and I’m a bit unhappy about this…
Randy and I have just released 4.4.0-beta4 for copter, plane and rover. We hope and expect this will be the last beta before 4.4.0 final.
Changes from 4.4.0-beta3
- flight controller specific changes
- Diatone-Mamba-MK4-H743v2 uses SPL06 baro (was DPS280)
- DMA for I2C disabled on F7 and H7 boards
- Foxeer H743v1 default serial protocol config fixes
- HeeWing-F405 and F405v2 support
- iFlight BlitzF7 support
- Scripts may take action based on VTOL motor loss
- Bug fixes
- BLHeli returns battery status requested via MSP (avoids hang when using esc-configurator)
- CRSFv3 rescans at baudrates to avoid RX loss
- EK3_ABIAS_P_NSE param range fix
- Scripting restart memory corruption bug fixed
- Siyi A8/ZR10 driver fix to avoid crash if serial port not configured
- Plane specific fixes
- fixed cross-tracking during airbraking in VTOL land
That’s so great! Thank you
I’m seeing this when downloading logs on the Zealot H743.
Critical: PreArm: Internal errors 0x8000 l:442 main_loop_stk
It used to just throw 0x8000, I think the “l:442 main_loop_stk” is new
@tridge, I can’t confirm this isn’t my fault with some parameter changes, but the takeoff pitch-down is HARD now. The step-change in demanded pitch in the logs confirms my observation. TKOFF_PLIM_SEC is set to 2, but it’s not being honored like it was before. Log with several takeoffs here: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
Updating firmware hung during the scan components. Pix racer pro. will try again.
EDIT: Got it to work must of been a cable issue.
the log you sent is with 4.3.7. It will likely be less severe with 4.4.0, but the core problem is the very high pitch demand of 30 degrees you put in the mission for the takeoff. That is a lot more than is needed.
30 has significant advantages on our aircraft coming out of the hand; otherwise there’s not enough AOA at the lower airspeeds to climb and we get very close to impacting terrain. This also was not a problem on previous releases; the pitch down was much more gentle and followed the parameters. We’ll test 4.4.0, but can you explain the regression with 4.3.7?
The plane_aerobatics.lua in master is a month old but significantly different (hundreds of lines of code) from the one in 4.4.0 beta 4, which is 5 months old.
I noticed it because I put the 4.4.0 beta 4 firmware on this plane (my Extra 260 running a Durandal) and it threw a syntax error message at runtime:
Does it make sense for 4.4.0 to go out with a 5 month old version of plane_aerobatics.lua?
I tested VTOL crosswinds landings in a mission after @WickedShell contributed this improvement last month . I am very satisfied.
Tomorrow, for once, I hope for more crosswind to make more approaches
Note: I created the mission for VTOL landing by LUA script: When pressing a button on the transmitter, a mission is created from the current position (WP 1) to the home position (WP 2) and automatically switched to auto mode.