Copter-4.3.5-rc1 has been released for beta testing and can be installed using MP or QGC’s beta firmwares link or it can be manually downloaded from firmware.ardupilot.org
Changes vs 4.3.4 are in the ReleaseNotes and copied below.
Bug fixes
a) GPS unconfigured error fix for non-M10 uBlox GPS
b) Gremsy gimbal fix when attached to autopilot’s serial3 (or higher)
c) Landing detector fix with large AHRS_TRIM values (>0.1)
d) MambaF405 2022 gets VTX power on support
e) MCU voltage enabled on H757 CPUs (including CubeOrangePlus)
f) PiccoloCAN fix for ESC voltage and current scaling
g) Servo gimbal mount yaw handling fix (only affects 3-axis servo gimbals)
The most serious fix is 1c which can cause the landing detector to fail if the AHRS_TRIM_X,Y values are too large which makes it difficult to disarm the vehicle after landing.
As always, any testing and feedback is greatly appreciated!
Regarding firmware 4.3.5-rc1 Install went well, GPS working nice and Stabilize is on mark on the 260 gram quad. Yaapu is failing looking for the second battery not installed making a false failsafe, demanding beeping sounds like a snow goose going south, I Need to fix this error as it hard to get into the zone. LOL. Possible I can install a fake battery 2 that is set to zero?
I’ve been messing with 4.3.5-rc1 all afternoon on my Shendrones Terraplane, which was a bit dated in firmware, since I haven’t flown it in a while. Decided to wipe all params and start fresh.
BlHeli passhthrough and BDSHOT are working great on the Matek H743-Mini, along with ExpressLRS and passthrough telemetry. I did a basic HNOTCH setup and started an autotune before it got dark, all of which was going well. The firmware even kept me honest with a couple of RC failsafes due to a low TX power setting on my radio (fixed by enabling ExpressLRS dynamic power - not an ArduPilot issue).
I did have a radio failsafe happen as I was trying to rudder-disarm after landing, which resulted in an unexpected liftoff. Not sure if that was compounded by overly conservative landing detection or just my bad luck.
I “upgraded” from 4.4 dev to 4.3.5 RC1 and I have strange behavior in auto mode. I don’t know whether to attribute this to 4.3.5 RC1 or it’s a different issue. However with 4.4 I had gotten the desired behavior. Here I described the problem better and added a log. Thanks for any suggestions
I flew a quick little bit with this beta using pixracer and crossfire for RC module. I didn’t see any issues flew great just flew in stab, loiter and tested rtl.
This got me thinking. When we teach our UAS class to wildland fire personnel, we tell people to fly with a purpose and not just go out and fly (often times many of the students don’t have much experience at all with UAS).
Is there a standard mission/flight we could come up with that can test these beta release better. I know there is often a lot of fixes and what not in them but I was just wondering if there was something we could have user fly as a standard test for all beta tests that way folks that do actually want to help have a purposeful mission to fly and aren’t just out there spinning rotors for fun. Or even just a few basic items to make sure and hit whenever you fly these betas?
I have attached a log from my short little flight.
I don’t think having a standard profile is actually in the best interest of testing unless there is a specific feature or bug-fix that is of interest, in which case we typically see an alpha release with some specific requests attached.
Having the widest possible array of users and use cases should result in the best test data for major/minor firmware releases.
I often do not see that many people testing or at least responding so wasn’t sure that wide use case was actually getting hit. sure seems like the same ppl test each time. I am sure there are others out there and they probably share feedback else where. just trying to maximize the testing so not to waste time. In plane there are even fewer folks testing so you are almost certainly not getting that “wide” use case as you are saying. I doesn’t have to be a standardize mission but are there specific flight modes and other items that would be beneficial to use when providing testing. or does simply flying ins stabilized provide enough? although useful I would imagine using other flight modes and what not would be more beneficial than just a log in stab and nothing else.
Is copter v4.3.5 released as stable or is it still in beta? Firmware v4.3.5 is what gets installed when I click the co-axial octocopter v4.3.4 icon in mission planner. It’s also posted as a stable folder on the firmware page.
Yes, 4.3.5 has been released as the stable version now. Sorry for the delay on the announcement, it takes some time for our build server to actually produce the binary for everyone and it appeared while I was asleep.
