Plane 4.1 stable

when it shows zero, does it still show voltages and current?
I’m wondering if we’re getting a negative RPM?
also, when it doesn’t show in MissionPlanner, does it still show correctly in the onboard BIN log? Look for the ESC message.

Hi @tridge ,

I also though about that but when reversing it shows also the rpms (positive). Here is another bin file where I could catch the F.Port issue. Mission Planner was showing the rpms and in the logs I can see also the rpms, in principle is working. But let me keep repeating the test to see I can catch when the rpms are not showing in the screen. https://drive.google.com/file/d/1RfiT2-3m7bCiMM-aShixNIIiMfsgmNHs/view?usp=sharing

I catch it :smiley: !!
https://drive.google.com/file/d/1Ia25fm4jTIH4gkz4PLMjBLAnM-SHf8KQ/view?usp=sharing
The Mission Planner was not showing the rpms and guess → the ESC is not showing in the log!!

Here you are: https://drive.google.com/file/d/1S0C3QR7Pxg5RzS2BDRLaZa3yg6C6iSxM/view?usp=sharing

This is the Tlog for the bin in the last post minute 22:59:21

Cheers!

@Pedro_Claro, I noticed a change in the “instance” of my ESC when moving to 4.1. More specifically, my aux 1/2 chanels were no longer “ESC1&2,” instead they were ESC 9&10. Maybe check the other ESC numbers in Mission Planner. I don’t have problems with that.

Improvements: Ready to Arm from a cold boot is definitely under 30 seconds. That’s fast.

I’d recommend setting the default parameters to include FBWA as reverse thrust capable (as it’s effectively manual throttle anyway). I’m getting a TON of CAN messages in my logs now, and I don’t really like it. Oh well I guess. Camera triggering and feedback appears normal. Do you see anything else obviously wrong here @tridge?

Log: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

yes, it is a bit annoying. Those are debug messages from the Here CAN firmware. It would be nice if CubePilot could do a new fw release that removed those. You didn’t see them before as we just ignored CAN debug msgs, whereas we now log them, which can be very useful for diagnostics.

right, they now align with the SERVOn number

that log ‘2021-10-13 22-59-21.bin’ has quite a few param changes over the previous 4.1.1 log you sent. The key one is that it has SERVO_BLH_TRATE=200, which is way too high. The telemetry is at 19200, you can’t fit 200Hz data at that rate, even with only a single motor. Drop it back to 20Hz.

If you are using bi-dir dshot , you can set this really low - even to about 5Hz

I will set it down to 5Hz. Do I have any advantage in using the BDshot when using the single ESC Rpm for the Harmonic Notch ( for single motor in plane or Heli)?
Right now the F.Port is not working, so I will kept the RCIN + Sport for the receiver. Any advice?

I would expect on a plane that the motor RPM will not vary so quickly as on a copter, so I would expect little advantage to using bdshot

No idea on F.Port - I don’t use it

Hi @tridge , Hi @andyp1per ,
Like said the F.Port feature is not working and this was reported before during the Beta testing.
Already provide several logs, Let me know if you need more support from my side. Thank you!

Here you are! The bin and Tlog for the rpm issue not visible in Mission Planner and also not logged in the bin file. I drop the SERVO_BLH_TRATE=20 as you ask, Still the issue is there.

https://drive.google.com/file/d/19mvzFJBL_kb3P-a08o9Ynq41PKJWBSZA/view?usp=sharing, https://drive.google.com/file/d/1wrgdz5DL7S-0e-DIvC4JgdVb37dLUKMF/view?usp=sharing


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.

Happy flying!

9 Likes

For matek f405WING,can it be changed back to EKF2? I can’t find the EK2 parameter in parameters tree。

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?

Thanks!
This is sounds great!

Can you please tell me more about RC_OPTION bit for multi RX configuration?

Thanks and Regards!

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.

1 Like

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.

1 Like