here is some log its working fine the current sensor working as well
this got me beat why this is but if i put stable it stop working
thanks for your time Andrew
https://drive.google.com/file/d/1bzv_gtZ7_-pR2GRWdd1iudJ6PTKOGByZ/view?usp=sharing
1 Like
Well that was interesting. I set FORMAT_VERSION to 1 while running 4.1.7, then upgraded the firmware via Mission Planner to 4.2. On the first boot it came up fine, so I loaded up my saved parameter file from 4.1.7 and wrote it to the hardware. A few warnings about readonly parameters but so far so good. I then power-cycled the board by unplugging the USB and plugging it back in, and when it started up again it gave the starting-up trill but then got stuck on the last note and just played a continuous tone.
I’ve attached my parameters file in case someone wants to try and figure out what part of it is incompatible with 4.2.
ardupilot_h743_wing_v2_explorer_after_upgrade_4.2.0.param (21.0 KB)
I’ve just released plane 4.2.1beta1. This is a minor release on top of the 4.2 firmware. It has a number of bug fixes and safety improvements. The changes are:
- fixed a bug in handling wrap in log download when 500 logs are on the microSD card
- added FlyingMoonF407 and FlyingMoonF427 support
- fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
- fixed update of gyro FFT throttle tracking
- removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
- improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
- added fuel usage integration on Lutan EFI
- refuse arming in AUTO when in a landing sequence due to a failsafe
- account for sprung throttle (from RC_OPTIONS) in throttle suppression code
- improved safety of in-flight compass learning
- fixed automatic airspeed ratio calibration for 2nd airspeed sensor
- increase safety of GUIDED → AUTO takeoff sequence used by QGC
- added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency
The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL
takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.
One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.
Happy flying!
5 Likes
after update to 4.2，the battery voltage display wrong，the flight mode can’t not display in message position,the current also can’t update
please tell us what flight controller you are using, and provide a telemetry log of it working with 4.1, and a telemetry log of it not working with 4.2
@Sampson can you try to reproduce this? Have you heard of any issues with 4.2 plane on a MatekH743-Wing2 ?
I don’t remember users reported this with H743-WING V2. In the past, some users reported that the V1 had stuck booting with 3.9/4.0. I haven’t heard much about this in recent one year. I usually do full chip erase before flashing in DFU mode with STM32CubeProg.
TRIDGE ,THE FC is matek F765 WING.the firware go back to 4.17,osd display normal.
2022-05-22 13-16-12,4.2 DJI OSD DO NOT DISPLAY RIGHT.tlog (210.3 KB)
2022-05-22 13-33-37 DJI OSD DISPLAY NORMAL.tlog (162.2 KB)
in both those logs the OSD is disabled as OSD_TYPE=0. For the DJI MSP OSD you must set OSD_TYPE=3
See the documentation here: MSP OSD — Plane documentation
I’ve just released plane 4.2.1 stable. This is a minor release with the following changes since 4.2.1beta1:
- fixed handling of safety state on boards with no safety switch
- fixed bug where a false positive could trigger quadplane landing disarm while land repositioning is active
For completeness, here are the changes from beta1 over the 4.2.0 release:
- fixed a bug in handling wrap in log download when 500 logs are on the microSD card
- added FlyingMoonF407 and FlyingMoonF427 support
- fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
- fixed update of gyro FFT throttle tracking
- removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
- improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
- added fuel usage integration on Lutan EFI
- refuse arming in AUTO when in a landing sequence due to a failsafe
- account for sprung throttle (from RC_OPTIONS) in throttle suppression code
- improved safety of in-flight compass learning
- fixed automatic airspeed ratio calibration for 2nd airspeed sensor
- increase safety of GUIDED → AUTO takeoff sequence used by QGC
- added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency
The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.
One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.
Happy flying!
3 Likes
@tridge, I have successfully tested automatic flaps in mission with SERVOn_FUNCTION,3
But now my flaps/ailerons configuration is crow:
SERVO10_FUNCTION,86
SERVO9_FUNCTION,87
SERVO8_FUNCTION,17
SERVO7_FUNCTION,16
With this setup, is there any chance in this release to activate this crow mix in auto landing?
yes, if your differential spoilers are setup to allow for flaps then it can activate in landing if LAND_FLAP_PERCNT is non-zero.
See Differential Spoilers & Full House Wing — Plane documentation for more info on differential spoiler options
1 Like
I set OSD_TYPE=3, but I don’t know why the record shows OSD_TYPE=0
Did anyone else working with a quadplane have trouble getting the ESCs to work/respond normally after updating to 4.2 from 4.1?
I’ve had one other report of that, and it was caused by Q_M_PWM_MIN and Q_M_PWM_MAX both being set to zero.
Please post a bin log while running a motor test with LOG_DISARMED=1 to help diagnose
In your config you have:
Q_M_PWM_MAX,0
Q_M_PWM_MIN,0
Try setting these to 1000 and 2000
Hi Tridge, thanks.
Q_M_PWM_Min/Max were set at 0/2000 and all was well on 4.1.7
Q_M_PWM_TYPE = 0
SERVO[1-4]_Min/Max 1100/1900
This log has a motor test + arming in QStabilize before and after changing Q_M_PWM_MIN to 1000 (from 0) and leaving Max at 2000.
https://drive.google.com/file/d/1qS8o4SC5m4EPuTXDHz8F5KUeaE_J44ic/view?usp=sharing
To clarify my situation - this was the fix for me.
It worked with q_m_pwm_min/max as 0/2000 on Plane 4.0.9 and 4.1.7
Flashing 4.2.0beta5 and 4.2.1 stable caused bizarre behaviour with the quads
Changing min/max to 1000/2000 resolved it.
- I did need to redo Q_ESC_CAL though, because after flashing the new firmware and changing to 1000/2000us only 3 motors responded