ok, thanks, try this settings in next fly
1 Like
Below are my attempts to make auto-tuning on AR Wing Pro. The result is not very good, after tuning there are fluctuations at low speed.
https://1drv.ms/u/s!AgyvhCRrlh2RmWG9zT2SkyHZbjAl?e=Dp75Jf
https://1drv.ms/u/s!AgyvhCRrlh2RmWAFWbdaK9OaQisV?e=NjjZHF
I see you’ve already tuned the SMAX down to 140. The oscillations seem worse on pitch, so maybe try PTCH_RATE_SMAX at 135 or 130? The other thing that helped my tune (AR900) was to increase the AUTOTUNE_LEVEL to 7.
ArduPlane V4.1.0dev (40ec8c72)
Dragon V2
After the autotune swing on the roll axle.
log
https://drive.google.com/file/d/1aOlpDAU_FUBby1BPEIH5XP7qEVLtp965/view?usp=sharing
dvr video https://youtu.be/Iw40L__SSK4
greeting schachti
I’ve flown 4 different aircraft on 4.1.0 Beta 3, and so far, MOSTLY good. First complaint is that BLHeli ESC telemetry sometimes takes SEVERAL reboots for the telemetry feedback to correctly initialize. I only use the ESC’s for battery monitoring, so it’s important that they work every boot.
My secondary complaint was not having reverse thrust in FBWA due to the USE_REV_THRUST parameter update and challenge setting that bitmask (Had to beta update Mission Planner).
I think the navigation controller may have gone through an update as I used to turn NAV_L1_Period to about 9, but that caused oscillations using this firmware. 13 works about right, and now the plane turns sharp even with higher NAV_L1_Periods. That could be a total coincidence, but I don’t think anything changed except the firmware.
Another thing I remember noticing; going from manual to FBWA after sitting on the bench for quite a few minutes, I thought I saw the servos jump once quite a bit. I’m not sure if some I-term buildup was happening or what, but it was slightly unusual.
Last, but not least, I received internal errors on both of my survey missions, and even though it read “failsafe” while in the air, it continued the mission: https://github.com/ArduPilot/ardupilot/issues/18046
Hi Nathan, This was my solution to the internal error…Mine appeared to have been triggered by the camera settings (servo and relay inputs) even after I removed all the servo inputs I still had the internal error that was finally fixed by changing the relay default to 1.
My RELAY_DEFAULT was 1, and changing to 0 did not help.
Just had a crash during transition to forward flight on a quadplane 4+1 in 4.1.0beta2. Loss of pitch and roll control. Aircraft has at least 5 hours on it with 4.1.0beta2.
Very similar to the setup that had this happen, but that was on 4.1.0beta1
can you post the log of the successful flight just prior to this one on the same aircraft?
Thanks for looking into this @tridge!
Nominally identical aircraft, same day, 4.1.0beta1. Log
Same aircraft, different day. Much of the FBWA flight was using RC overrides from a companion computer. Largest number log in this folder is the flight immediately before the mishap flight. Log
how much throw do you have on the elevator? I’m wondering if it is too much throw and you are stalling the elevator.
Basically the crash log makes no sense. The control surface and motor output values all look good. It could be a failure on the rear VTOL motors when the voltage drops as the fwd motor kicks in, but I don’t see a current drop that would point at that.
The current draw is a bit higher than in the previous log on the same aircraft I looked at, but not by a huge margin.
I’ve just released ArduPilot Plane 4.1.0beta4. This is a large beta update, with significant changes over beta3.
The biggest changes are in EKF3, with a move to double precision floating point calculations on MCUs that support it. This also includes changes to support very long distance flight (flights around the world have been tested in simulation). Previously the EKF would start getting some degree of error at a few hundred kilometers, and would fail completely at 1000km from the startup location.
The beta also includes major changes to the fixed wing autotune based on the great feedback and logs from users running the earlier beta releases. You can watch a video showing the changes in autotune here:
I would really appreciate logs from anyone still having issues with autotune with beta4.
Other changes include:
- added MAN_EXPO_* parameters for input expos in MANUAL, TRAINING and ACRO modes without having to set them up in your transmitter
- added ONESHOT_MASK for oneshot output on control surfaces
- GPS-for-yaw enhancements including using position and yaw from different GPSs
- major improvements to EKF3 stability
- BLHeli fix that could cause failure to boot
- CRSF message spamming and firmware string length fixed
- Display re-enabled on 1MB boards
- DShot always sends 0 when disarmed (protects against motors spin while disarmed due to misconfiguration)
- DShot fix that could cause main loop jitter
- DShot buzzer tone disabled during motor test to remove bad interation
- MatekF405-bdshot NeoPixel LEDs re-enabled on PWM5
- Serial port performance improvements using FIFO on H7 boards
Please report all test results and happy flying!
5 Likes
Thanks @tridge for the great work a friend was getting oscillation in pitch after auto tuning an AR Wing Pro. We will give this a go I have mine ready for a post lockdown maiden!
1 Like
I looked at the log and agree that the crash doesn’t make sense. Throw is about 35-45 degrees. For what it’s worth, I have probably 28+ hours on airframes of this type with that much elevator throw. Though perhaps the 4.0.1 autotune was more aggressive with the elevator…
I have a QuadPlane on 4.1.0Dev (Build back in late 2020), how easy/safe is it to upgrade to the 4.1.0Beta4?
Is it as simple as backup params, flashing the firmware and load params back?
@tridge, I saw the latest beta release notes and haven’t seen anything about the internal error that’s been reported here: https://github.com/ArduPilot/ardupilot/issues/18046
I can’t point to PERFECT hardware, but I can say that this behavior definitely didn’t happen with the 4.0.xx firmwares, and the other hardware (an Emlid reach M2) attached to the camera feedback circuit logs accurate timestamps.
@Naterater @tridge
Isn’t this exactly what the removal of the BRD_PWM count is supposed to sort, amongst others?
Or is that not removed from this beta yet? https://github.com/ArduPilot/ardupilot/pull/18018
Nate, your issue is relay related is it not?
Yeah; may be… I’ll have to revisit the plane to see what parameters I have access to; it could indeed be a misconfiguration, and in that case, possibly prearm checks or a warning in the release notes could help solve the problem.
just load the new firmware and the params will take care of themselves. Doing the “backup/reload” of params is more likely to cause problems as that defeats the automatic parameter upgrade that the firmware does.
the message in the log is:
2021-07-18 07:16:41.039 ISR flood on pin 53
what this means is the interrupt handler for that pin saw 10k interrupts in 100ms. The code that detects this is the same as in plane 4.0 (the feature to detect this was added in plane 4.0.7).
The cause is almost certainly EMI causing the pin to rapidly change value. The fix should be a pulldown resistor on the pin (or if you have a pulldown, then change it for one with lower resistance).
If you want to investigate this properly then you’d need to reproduce it with a scope attached and see exactly what is happening on that pin.
I don’t see any problem in the parameters, and the patch removing BRD_PWM_COUNT (which is not in the 4.1.0beta4 release) won’t make any difference.