Plane 4.2 beta release

I’m struggling with how to describe this in the docs. RTL_AUTOLAND = “Automatically begin landing sequence after arriving at RTL location.”

So the table would look like this:

Value Meaning
0 Disable
1 Home - Enable fly HOME or to a Rally point then land
2 Land - Enable go directly to landing sequence
3 Go Around - Disable but allow Arming with DO_LAND_START in the mission for go arounds.

This is because in QGC - only the first part of the text is shown, so the options will all look the same otherwise. Here is a screenshot:

close, but on (1) a rally point may be used

I just copied what was there

thanks, i’ve updated the PR to clarify

Are the docs generated from Parameters.cpp? If so can I suggest you use the text I have put above, including the rally point , I think (maybe), it’s clearer than just “OnlyForGoAround”. I added a screen shot to show why it’s important.


I’ve just released ArduPilot Plane 4.2.0beta4. Several important fixes are included since the previous beta, plus some new features.

  • added BATT_OPTIONS option to send resting voltage (corrected for internal resistance) to the ground station
  • fixed a bug when a blended GPS is lost, where the wrong GPS could be used for a short time
  • prevent rapid RTL/AUTO switching with DO_LAND_START and fence breach
  • added RTL_AUTOLAND=3 to prevent arming check about DO_LAND_START with no RTL_AUTOLAND
  • fixed yaw in AUTO mode on the ground on quadplanes when using rudder to disarm
  • fixed failover between IOMCU RC input and a secondary RC input on a uart
  • display source of RC input with protocol
  • fixed DShot reversal bugs with IOMCU based boards
  • fixed battery remaining percentage with sum battery backend
  • added KakuteH7-bdshot
  • added terrain reference adjustment and TERRAIN_OFS_MAX parameter
  • fixed param conversion bug (impacts airspeed enable)
  • changed MatekH743 to use a 32 bit timer

Happy flying!

6 Likes

Where can I find any details to “DJI FPV OSD multi screen and stats support” please?

there is more information in this PR which added the feature:

1 Like

Hello @tridge
Thank you very much for all you and all developers effort to make this system better and better.

About this issue:

Could you please clarify, how this works?
My key question is how to callibrate this battery remaining percentage ??

The reason of my question is, I found “problem or issue” when using Cuav Nora PM lite using CAN , that is supllied by CUAV.
I did posting this issue some times ago. The problem was, Mission planner display the remaining battery percentage WRONGLY. Eventhought Voltage and current display are correct… Also battery consumed was correct (in MAH). This is very confusing. So the battery remaining percentage is much lower than it should be.
Thank you…

we have two fixes for this in 4.2.0

  • you can set a BATT_OPTIONS bit to ignore the “state of charge” from a CAN battery monitor and instead use integrated current
  • there is a BATT_CURR_MULT factor you can use to adjust the current multiplier

Not sure if this is on purpose but it seems Custom Firmware Builder Server is stuck in a commit of 20+ days ago.

Links to: a19fa24ccd

@Lanza thanks for letting us know! It was stuck as it was using the old git:// protocol. I’ve fixed it now.

1 Like

@tridge, I just received a support request for EKF’s not aligning and preventing arming on the beta 4 firmware. Maybe this is unrelated to the beta, but the log is attached here. I flew the aircraft without prearm issues just prior to this, so I’m not sure what the cause is. My flight was totally successful, although I did have to reassign the trigger and feedback servo_function parameters to -1 to get the camera working normally. That will be helpful for the release notes when 4.2 goes live.

the log shows EKF3 aligning and being ready 73 seconds after power on, which is really pretty good. Maybe the wrong log?


I’ve just released plane 4.2.0beta5. The changes since beta4 are:

  • fixed a timer bug that could cause boards using flash storage to watchdog
  • added OTG2 USB on QioTekZealotH743
  • increased stack size on log and monitor threads
  • fixed rudder control when ARMING_RUDDER != 2 on quadplanes
  • fixed accel bias when an IMU is disabled in EKF3
  • improved QSPI support for SPro H7 Extreme
  • fixed @SYS file logging
  • fixed buzzer on MatekH743, going back to 16 bit timer
  • fixed H7 flash storage bug that caused re-init on overflow
  • fixed incorrect lock class in UART driver

The most critical change is the timer fix that could cause H7 boards with flash storage (eg. MatekH743) to watchdog.

Happy flying!

3 Likes

@tridge, I believe this log shows internal errors in the middle of a flight line that I have no other explanation for. Based on the trajectory, it appears to me like one ESC may have been inadvertently reversed causing a totally flat spin. Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

Hello cool developer, it’s great to see you continue to develop.
Q_ENABLE = 1
Q_FRAME_CLASS = 1
Q_FRAME_TYPE = 16
Q_TILT_TYPE = 2
Q_TILT_MASK = 8:
Q_TAILSIT_ENABLE = 0
Q_TILT_YAW_ANGLE = 0
Function = 39 Please develop the tailtilt servo to respond to QSTABILIZE as well.
In QSTABILIZE mode, the tailtilt servo does not respond to the rudder stick.
Can you make the reaction visible on the Servo output screen when armed?

@tridge, we had a serious crash, I believe from an internal error in the log I posted a few days ago using the beta 4 firmware. Please check it out. Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

I think you may be right about a motor reversal. It looks like the left motor went into reverse at the same time that you got an ISR flood internal error.
@andyp1per can you have a look at this?
The sequence seems to be:

  • two ESCs running normally with DShot150, on PWM(5) and PWM(6), both giving ESC DShot telemetry. ESCs setup as 3D, to allow for reverse thrust landing
  • ISR flood on pin 57, the camera feedback pin (on SERVO8)
  • both ESCs stop reporting telemetry for around 1.5s, battery sensor current draw remains steady during this time
  • 2nd (right) ESC starts reporting telemetry again, then stops, then starts again
  • 1st (left) ESC starts reporting telemetry sporadically, only giving data infrequently, and the aircraft starts to yaw left, ending up spinning at over 1000 degrees/second, which is remarkably fast for a plane of this size (I presume this is a believer?)

I don’t understand the relationship between the ISR flood and the ESC reversal. An ISR flood is an external event, triggering lots of pin toggles, causing us to shut down that interrupt source. Was there some other event that caused both the ISR flood and the motor reversal? Or did the flood somehow impact the ESC?

@Naterater is the aircraft undamaged enough to run ground tests? Do the ESCs/motors still work? Do they operate in the right direction?

@Naterater can you send me a link to a normal flight where reverse thrust is used in landing?