multiple flight hours with https://github.com/ArduPilot/ardupilot/pull/14203 and https://github.com/ArduPilot/ardupilot/pull/14299 added with good results. thanks @andyp1per for a bunch of great additions!
basti
multiple flight hours with https://github.com/ArduPilot/ardupilot/pull/14203 and https://github.com/ArduPilot/ardupilot/pull/14299 added with good results. thanks @andyp1per for a bunch of great additions!
basti
copter has a nice FS_OPTIONS parameter. I’m thinking in future of adopting FS_OPTIONS for plane, possibly with some extra bits defined
The key changes to existing behaviour to watch out for in this update
are:
ArduPilot has now switched to it’s own USB IDs for all boards. For
most users this won’t cause any change, except they may notice the
drop down list of devices in MissionPlanner will have the ArduPilot
flight controllers labelled more usefully as “ArduPilot” instead of
just “STM32”. If you hit issues on windows please try reinstalling the
device drivers from this URL:
https://firmware.ardupilot.org/Tools/MissionPlanner/driver.msi
A bug fix in the format ArduPilot uses to store terrain data means
that your flight controller will need to re-download the terrain data
onto the sdcard via your GCS. If you fly without a GCS and you use
terrain data then please re-download the terrain data you need by
setting up a mission when you have internet access and allowing your
flight controller to request terrain data from your GCS.
This release adds in the missing hook for the VTOL motor controller on
a quadplane to compensate the VTOL gains using your pressure
altitude. For most people this will not have a noticible effect, but
some users that have tuned their aircraft for high locations may
notice a tuning change.
The new compass ordering system in this release gives a lot more
flexibility and should preseve existing configurations and
calibrations. If you hit issues then please have a look at the new
compass ordering user interface in recent beta releases of
MissionPlanner.
For people flying before visual range (with appropriate
authorisations) there is a new option which allows for safer
operation. By setting THR_FAILSAFE=2 you can setup the R/C failsafe so
that R/C input will stop being used when one of the receiver failsafe
conditions is met, while not triggering any failsafe actions. This is
a significant improvement over setting THR_FAILSAFE=0 as it prevents
the receiver inputs being used for stick mixing and other inputs that
would be inappropriate when in receiver failsafe.
Many thanks to everyone who contributed to and tested this release!
Happy flying!
Now that’s a novel
Thanks’ to all who worked on it
now i have something to do in lockdown
Stable 4.06 doesn’t appear to be available in MP?
Just getting ready for a flight tomorrow. Currently flying 4.06beta5.
Thanks!
Is that a beta of MP?
i don’t think so but it may be i did read some where to up to the latest
My MP is 1.3.7530.26934 and if I check for updates it only offers a beta update that fails “Error getting Parameter Information” so I canceled it. I guess I’ll wait a day or two. Was headed out flying tomorrow morning so hoped to get this loaded.
if your using windows 10 you need to run it as ADMIN to update it
Interesting - started it with admin and mp updated to 1.3.7555.20712 but still only offers 4.05 stable and beta up to 4.06b5.
Maybe I’ll check the github repository… Yep 4.06 stable is there but for some reason it won’t show in my MP. It uploaded fine manually but still odd that it doesn’t show in MP for me.
Hi.
Thanks for great work and detailes information. I had Matek F405 wing board and R9mm frsky receiver. Till now i cant the telemetry work through inverted F.port of R9mm (on 4.0.5 version) to TX2 uart pad on fc with frsky passthrough protocol(serial protocol 10) Everybode recommended an inverter for fport in case of f4 boards. Will this release solve this issue so can i use R9mm receiver inverted Fport without diode and ttl converter to get telemetry.?!
What is the right setup: is serial2 prtocol10 or 23 ? serial_option 0 or 7?
Many thanks
I could not get F-Port working with the latest FrSky firmware. I think it’s a bug because it works with the older version. Cross posted here: FrSky FPort support - testers wanted
I downloaded the latest version of ArduPlane today to a Kakute F7 but now I cannot control the flaps from the transmitter. I cannot find how to control it anymore.
My fault or code change?
Mr Anders W
Sweden
can you send me a tlog showing you trying to move the flaps on the ground? Or a bin log with LOG_DISARMED=1
Hi Tridge
Nice to hear from you.
If I am correct there was something like “FLAP_RC_CH”. Now there is not.
I have no clue how to connect an RC channel to the control the flaps.
The RC input is working.
The Flaps are working in Setup -> Servos and if I click Reverse they move as they should
I’m running the code on a Kakute F7. The Flaps on CH 5 and Dshot on Ch 6.
Motor, and all other servos are working perfectly but I cannot control the flaps.
Anders
in 4.0 there is a parameter FLAP_IN_CHANNEL that you are probably referring to.
For 4.1 (in development now) this has been replaced with a RCn_OPTION “FLAP” (value 208). So you RC7_OPTION=208 to make flap input come from channel 7.
The changes are:
The most critical fix in the above list is the ISR flood issue.
ISR Flood Issue
The ISR flood issue happens when a misbehaving external sensor (such as an RPM sensor for a petrol motor) starts providing pulses faster than the flight controller can process them. If this happens then the CPU can be overloaded in the interrupt handling for the sensor and stop flying the vehicle. The level of interrupt rate needed to cause this issue is around 500k interrupts per second, so to be safe we have added a limit of 100k interrupts per second. If a single interrupt source produces more than 10k interrupts in a single 0.1 second period then we disable that interrupt source, print a warning to the user and raise an internal error.
Happy flying!