I’ve just released plane stable 4.1.2. This is minor update with a few important fixes and some new features:
added EK3_PRIMARY parameter, to allow for selection of other than the first IMU as initial EK3 lane
added ESC_TELEMETRY_1_to_4 to list of mavlink message selections
fixed burst read ftp error causing bad ftp param download
fixed H7 FIFO issue with RTSCTS flow control on UARTs
apply takeoff throttle slew limit in TAKEOFF mode and forward transition in quadplane
reset target mission airspeed on disarm
added RC_OPTION bit to enable multi-receiver systems
don’t apply fixed wing pitch limit to tailsitters when hovering
fixed turn rate coordination when inverted in fixed wing flight
fixed bug in AUTOTUNE mode that could leave gains from part way
through the tune
Of these fixes the only one that is not backwards compatible is the
new RC_OPTION bit which needs to be set if you have multiple RC
receivers on your aircraft and want to fail over to a backup receiver
while in flight. You will need to set the new RC_OPTION to enable that
for the 4.1.2 release and later.
you would need to do a custom build to get EKF2. See https://custom.ardupilot.org/
We can’t fit both EKF2 and EKF3 in flash along with all the other features
@Triage, I have been using 4.1.0 stable successfully and saw that 4.1.2 came out recently so I decided to update my Matek F765-Wing. During update something got spooked (Don’t know what) and now the board won’t connect to MP, nor my laptop would recognize the target device. In device manager it pops up for few seconds, but then get disconnected and the red LED on F765 is solid red. I think my FC got bricked.
Do you know how to recover from this situation?
I change the parameter PTCH2SRV_P 4.0.x Pitch PID Values, but the parameter PTCH_RATE_FF 4.1.x Pitch PID Values changes. Why doesn’t the 4.1.x Pitch PID Values PTCH_RATE_P change? Is the calculator working correctly ArduPilot Plane 4.1.x PID Calculator
?
it is working correctly. The new P term is equal to the old D term. That is why I did the calculator to help people, because it isn’t really obvious the way the relationships work.
The old system was a fairly complex relationship which was created in order to preserve PID values from the very early days of ArduPilot when we had an angle controller instead of a rate controller. We converted to a rate controller a long time ago, but decided at the time to auto-convert from the angle PID values to rate PID values on the fly. That was a mistake which is fixed in 4.1.x. We now use direct rate PID values.
Thanks for the quick and accurate reply. It’s really just a recalculation in the ArduPilot Plane 4.1.x PID Calculator. For example, if increase RLL2SRV_D in the 4.0.x PID Value then that would also increase the feed-forward gain 4.1.x RLL_RATE_FF and RLL_RATE_P. Now I can use these parameter 4.1.x Pitch PID values according to their definitions.
@tridge , I observe that the issues regarding the RPMs not showing in MP and also the motor not reversing are related to not rebooting phisically the ESC ( Holybro Tekko 32 F3 Metal). I can reproduce all this issues if I dont reboot the ESC and just reboot the AP. Dont know if this is a bug or just normal behaviour. BLHeli is not updating the new settings and this is the reason that it does not “sync” with ardupilot. If its not a bug it should be advised to reboot the ESC after making changes in BDSHOT and BLH parameter settings.
The F.PORT still does not work in this release. Same behaviour as reported before. Sorry, but from my point of view this is CRITICAL as it fakes you in having the control of the aircraft but after 3 or 4 minutes the connection is lost and AP turns failsafe. I have a MatekH743 together with FrSky Archer RS receiver.
Below is the image I take after 25 minutes runnign with Fport (full control with no issues, besides the warnings being indoors)
It is unlikely to be bootloader related. I have an Archer here and a MatekH743. I’ll see if I can reproduce the issue.
When you are testing this how is the FPort receiver being powered? Which exact pins is it connected to on the MatekH743?
The reason I ask is that the most common cause of a receiver losing connection in bench tests is marginal power to the receiver.
Also please send me a tlog of when it loses the receiver link, and let me know which MatekH743 variant it is.
You should be able to reproduce it in the bench. I have 2 aircrafts with the exact same setup concept using the Matek with same peripheral in same interfaces, I observed this F.Port issue in both of them, so its not an HW failure, remember F.Port was working in both aircrafts in FW 4.0.9.
Why not? This way I can configure SBUS for control and S.Port for telemetry or switch the F.Port to do both. This setting is done in the parameters. If I use the BDSHOT ( timer is occupied) I have to switch on the F.Port. If I don’t use the BDSHOT I can rely on the SBUS, as you see the F.Port is not reliable.
Sorry, one more question, if you are doing this you should not wire it like this?
I thought that you could not share the same port for RX and TX using SBUS + Sport.
