@iter thanks, I’ve changed the message:
1 Like
We have just released 4.3.7-beta1 for plane, copter and rover. This is the first time we have done a beta of an earlier stable release while a beta of a new release (4.4.0-beta) is in progress.
The reason for this 4.3.7-beta1 is that we had a nasty bug reported by CUAV that could result in not regaining RC input after RC input was lost and the aircraft then came back into range. The bug only affects boards using an IOMCU (generally any board with separate “main” and “aux” servo output pins).
We tracked down the bug and it was first added in 4.0.6 when we added FPort RC input support. The bug is usually rare which is why it has gone undiscovered for so long, but in some setups the bug happens easily.
The 4.3.7-beta1 release for plane also synchronises with the copter 4.3.7-beta1 release (plane 4.3.5 did not have some patches that were in copter 4.3.6). We have skipped the 4.3.6 release number for plane to get back into sync with version numbers with copter and rover.
The full list of changes since plane 4.3.5 in this beta is:
- fixed a fault in the INS batch sampler code if you change the INS_LOG_BAT_CNT parameter without rebooting
- fixed the RC input on IOMCU bug explained above
- fixed a bug in ICE engine control if you do a “delay engine start” mission command while flying
- added MCU voltage monitoring for the H757 microcontroller (eg. CubeOrangePlus)
- servo gimbal mount yaw handling fix (only affects 3-axis servo gimbals)
- PiccoloCAN fix for ESC voltage and current scaling
- Gremsy gimbal fix when attached to autopilot’s serial3 (or higher)
- added CubeOrangePlus-bdshot build
- fixed a bug in handling bad UART data in the megasquirt serial EFI driver
- added -g option for configuring with debug symbols without full debug (helped with RCIN bug diagnosis)
- fixed airmode switch for QACRO and QSTABILIZE modes
- fixed a rare memory corruption bug in the STM32H757
- fixed an EKF3 bug in accel bias calculations
- adjust EKF3 accel bias process noise for greater robustness
- cope with compassmot impacting GSF yaw numerical stability
To install this beta you need to jump through some extra hoops as the MissionPlanner “beta” button will only take you to the main beta, which is currently 4.4.0beta1. To install press the “All Options” button on the Install Firmware screen:
then fill it in like this, selecting the right board:
Note that you will need to choose the apj file for your vehicle type from the list of possible files.
Alternatively you can download the apj directly from here:
https://firmware.ardupilot.org/Plane/beta-4.3/
Please report any issues you find with this beta!
Many thanks to CUAV for finding this RC input bug and reporting it! Luckily it was found during ground testing.
1 Like
Would this be the bug if the rc signal is lost and then sometimes does not reconnect for a while and when it does it has a brief erratic behaviour?
@Chaoschoppers yes, it can manifest as taking a longer than expected time to reconnect. On the “erractic” behaviour that is harder to know - if you have an example log I could look. In general you would not expect either to get back good RC inputs or not get them.
1 Like
I have a Holybro Pixhawk4 flight controller with firmware version 4.2.0 and an RFD 868X modem, the RC channel is connected as SBUS. After your error message that the RC input does not recover after the RC input has been lost, I performed an RC signal loss test. I performed the ARM procedure for the Holybro Pixhawk4 while I turned off the power on the RFD 868X ground modem. After that, I paused for 10 minutes and turned the RFD 868X back on. I made these attempts several times and got different results:
-
RC channel control is restored without pause, telemetry works
-
The RC channel control is not restored, the green LED on the RFD 868X terrestrial modem flashes, the green LED on the RFD 868X air modem is solid. Telemetry works one way, MP accepts telemetry, but is not managed with MP. After I turn off the ground RFD 868X and turn the power back on, the telemetry and the RC channel is working correctly, the RC control is restored.
I performed this test with a MATEK 743WING with firmware version 4.2.0 and an RFD 868X modem. The result is stable, telemetry and RC is restored without pause.
A question for developers. Is there a second result of the error of not restoring the RC channel or is it a connection problem with the RFD 868X modems?
Earlier I found that there are cases of modems not connecting when I first turn it on, I corrected this by turning the power on again. I also set the order of inclusion, the transmitter turns on first, the ground RFD 868X turns on second, and then the airborne RFD 868X.
@egunak95 thanks for testing. It wasn’t quite clear to me if your test where you did not regain RC control was with the 4.3.7-beta1 release. If it was can you please post the tlog?
Thank you for your quick response!
The purpose of my test is to check the firmware 4.2.0 to restore the RC channel after losing the connection of the RFD868X modems. I did this to make a decision about firmware version 4.3.7-beta1. My two planes are successfully flying with firmware 4.2.0, I have to decide whether to re-flash. Is flashing a rational solution? However, with the new firmware 4.3.7-beta1, will it be necessary to repeat the AUTOTUNE processes? In the list of changes from version 4.2.0 to 4.3.7-beta1, many features have been added that will require additional work to configure the aircraft. However, an aircraft with an electric motor is easier to set up for the new firmware than an aircraft with ICE. For an aircraft with ICE, I will need to repeat the Dynamic Harmonic Notch Filters setting due to the improvement of these functions. As a result, there is a lot of work to be done to adapt my aircraft to the new functions, this will not be limited to checking the recovery of the RC after signal loss. And to do such work, you need to use a lot of time and money.
I think it’s better to fix version 4.2.0, so I won’t spend time adapting with new features, and my planes will continue to fly with firmware 4.2.0. At the same time, it is better to spend time testing new versions of flight controller firmware for new aircraft.
It was very difficult to make adjustments to the plane with ICE, it was a successful adventure, it is happiness that no one was hurt, not a single animal became a victim of my plane. However, I would not like to repeat this adventure again, the plane flies with firmware 4.2.0 and it is not dangerous, you just need to fix one bug.
Thank you for your attention to flight safety issues.
@egunak95 unfortunately this RC input bug is quite erratic. You could do hundreds or thousands of tests with no issue and then it will happen at the worst possible moment. I can assume you the bug can happen with all versions since 4.0.6.
There are also other important bug fixes since 4.2.0. We don’t do a new stable release unless we think users should be using it. For example, this release fixes a bug in handling of ICE engines. You probably won’t hit that bug, but better to have the fix than not have it.
You should not need to repeat any of your notch filtering, or any other setup in fact. We are careful to auto-update parameters when you load a new firmware.
There are improvements in filtering, but we made the changes in a backwards compatible way. You won’t get the new features unless you turn them on.
Best of luck with your aircraft.
2 Likes
Thank you for the quick and accurate response! Now I have no doubts about the rationality of installing firmware version 4.3.7-beta1 instead of 4.2.0. I’d rather spend my time, but I’ll get a better result in terms of the reliability of the flight controller. Thank you for your great work in improving the algorithm of the flight controller program.
1 Like
ArduPilot plane 4.3.7 stable has now been released.
This stable release is for the 4.3.x stable series and is being done because of a serious bug that has been found with RC input on boards that use an IOMCU for RC input (boards with a separate set of 8 “main” outputs from “aux” outputs).
The bug was that when RC input is lost and the receiver is one that uses “no pulses” for loss of RC input then there is a chance that when the RC link is regained that ArduPilot will not regain RC control and will continue in RC failsafe.
The bug is an old one, first introduced in the 4.0.6 release in September 2020. The bug does not occur often which is why it has been such a long time before it was noticed. We would like to thank CUAV
for noticing and reporting the bug!
This release also has some other changes, some of which are to sync with the Copter 4.3.6 release (which will go to 4.3.7 with this RC input bug fix) and some are other bugs found since the 4.3.5 plane
release.
This release skips the 4.3.6 number to sync with copter.
The full list of changes is:
- fixed a fault in the INS batch sampler code if you change the INS_LOG_BAT_CNT parameter without rebooting
- fixed the RC input on IOMCU bug explained above
- fixed a bug in ICE engine control if you do a “delay engine start” mission command while flying
- added MCU voltage monitoring for the H757 microcontroller (eg. CubeOrangePlus)
- servo gimbal mount yaw handling fix (only affects 3-axis servo gimbals)
- PiccoloCAN fix for ESC voltage and current scaling
- Gremsy gimbal fix when attached to autopilot’s serial3 (or higher)
- added CubeOrangePlus-bdshot build
- fixed a bug in handling bad UART data in the megasquirt serial EFI driver
- added -g option for configuring with debug symbols without full debug (helped with RCIN bug diagnosis)
- fixed airmode switch for QACRO and QSTABILIZE modes
- fixed a rare memory corruption bug in the STM32H757
- fixed an EKF3 bug in accel bias calculations
- adjust EKF3 accel bias process noise for greater robustness
- cope with compassmot impacting GSF yaw numerical stability
Thank you to everyone who contributed to this release with code, testing and documentation!
3 Likes
up dated to 4.3.7
Hi all i am using frsky R8 Pro access receiver on an orange cube set to no pulses
so did test the fail safe the cube going to RTL fine but the rc passthrough channels holds the last input revived which is not good for an fpv camera pan and tilt and also it hold the rc channel for rssi which i have on CH16 can we set failsafe position on them ?
Hello @tridge ,
I just test my Quadplane 4+1 MFE Fighter using stable 4.3.7 and try to run Lua Script to do Quick Q-Aututune. I download the Lua script from here
But there is Error Message of this VTOL-quicktune.lua .
I need help from experts here how to solve this problem.
Could you or other experts @rmackay9 @Yuri_Rage could take a look on this problem?
Here is the error message display:
I have followed all procedure and copy the lua script file on the micro SD card under folder:
…APM/scripts
And here is t the parameter :
My Vtol Param1.param (20.6 KB)
Any advice is hightly appreciated.
Thank you…
It appears you’ve downloaded the entire webpage rather than just the script itself.
And you definitely do not need the markdown (.md file) on your SD card.
Hi @Yuri_Rage
I have deleted the “.md” file, but same error message… I did not download the whole webpage, but I did download only the lua script file… Yes that is true… I did right click mouse , then “save file link” . Then I got only the lua script… The downloaded file has original extension as … xxx. lua
You may try to download that lua script, just to check if it does not work…
But, Thank you for your comment…
Tony
There is no scenario where line 8 should have a < symbol if you downloaded the script correctly.
Use this link to download, as it is a direct link to the raw file:
VTOL-quicktune.lua
1 Like
@Yuri_Rage ,
Ok, I will try and will let you know…
Just basic question, can I copy a script (just a sample), and then change the extention file from txt into … lua ??
Thank you .
Tony
Indeed they are just text files with a .lua extension.
Hi @Yuri_Rage
The “quicktune. lua” works on the bench. I will test in the field within this week if weather is good.
After finishing this quick tune, I will run the standard tuning on plane mode.
Then I will do some testing on the “mount_poi.lua”.
I think lua script is very interesting topic to enhance our drone capability.
Next, I will move to “lua script” thread, for further discussion.
Thank you
Hello @tridge,
I found out, that after update to 4.3.7 in all of my controllers it has been changed the parameter EK3_ABIAS_P_NSE to 0.02, even if this value is out of range (0.00001-0.005):
Please, can you explain it.
I’ve done a PR to fix the docs - AP_NavEKF3: fix docs on ABIAS_P_NSE_DEFAULT by andyp1per · Pull Request #24282 · ArduPilot/ardupilot · GitHub