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.
I’ve just released plane 4.1.0beta5. This is a small beta update, with a few important fixes.
Changes are:
- Flywoo F745 supports external I2C compasses
- GPS-for-yaw arming check added
- GPS_DRV_OPTIONS allows forcing UBlox GPS to 115200 baud
- Lua scripts can be placed in ROMFS_custom directory
- Q_P_VELXY_FILT renamed to _FLTE, Q_P_VELXY_D_FILT renamed to _FLTD
- CAN threading fix to resolve potential lockup when lua scripts use CAN
- EKF3 GSF can be invoked multiple times with source switching (no longer limited by EK3_GSF_RST_MAX)
- EKF3 IMU offset fix (vehicle’s reported position was slightly incorrect if INS_POS_XYZ params set)
- OSD overwrite and nullptr check fix
- RCOut banner displayed at very end of startup procedure to avoid invalid output
- allow for VTOL flightmodes after AHRS fallback to DCM
- fixed a bug in Z accel initialisation (particularly affects tailsitters)
- added LOG_BITMASK bit for logging attitude and PIDs at full loop rate
Happy flying!
6 Likes
When will this be available for download?
Hello, I have flown my tailsitter Dual Motor with stable manual transitions and I have also flown in very stable plane mode with 4.1 Beta4. Today I have tested AUTO mode for the first time and AHRS: DCM active> AHRS: EKF3 active appears sequentially.
I switched to Q modes to take control but it was almost impossible to fly it
I just read this in this beta5:
“Allow for VTOL flightmodes after AHRS fallback to DCM”
…and I don’t know if it really has any relation to what I have comment.
it is available now, the build servers take up to 10 hours to totally finish a new build
Hello.
Thank you very much for your achievements.
I have a request
In the in-flight OSD, is it possible to see the voltage cell by cell?
INAV looks good on this feature.
Actually I see 6 cell voltage and it’s hard to know the voltage per cell.
It would be very nice to show the voltage in cells.
thank you.
I get these slow oscillations in throttle and in altitude while in cruise mode. My throttle and altitude look sinusoidal when graphed. Amperage slowly oscillates between 5 and 12, while altitude oscillates over a difference of 20 ft, back and forth. It is as if there is a PID for throttle that needs to be adjusted. Which parameters can I tune to try to flatten out this undesirable throttle/altitude oscillation?
it is almost certainly the TECS tuning parameters:
https://ardupilot.org/plane/docs/tecs-total-energy-control-system-for-speed-height-tuning-guide.html
@tridge I’m not seeing a TECS parameter that looks like it would help for this specific issue. Most of the parameters would affect cruising behavior AND scenarios where the plane needs to ascend or descend quickly to the next waypoint. In other words, if I were to adjust parameters to get rid of oscillations, it seems like it would ALSO hinder the planes ability to quickly ascend to a waypoint with a higher altitude.
I’m flying a volantex ASW-28 powered glider with no airspeed sensor. Surely this issue of oscillating altitude and throttle is common (to varying degrees) and surely there is already a common few parameters (or less) that have already been proven to help. Going down the rabbit hole of adjusting many different TECS parameters, even though none of them seem to directly affect this issue by themselves, seems like a huge headache.
The problem is poor pitch PID tuning causing the pitch control to be very laggy. It doesn’t look like you’ve run an autotune (the PID parameters are not ones the autotune would produce).
Try running an autotune with 4.1.0beta5 and see if your pitch control improves.
@tridge Autotune seems to have fixed it. I also got rid of some play in the elevator horn. Elevation is pretty solid but throttle still oscillates.
[1.] Is there a simple, single parameter that has a high chance of calming cruising throttle oscillations, while NOT affecting the aircraft’s ability to quickly ascend or descend if it needs to?
[2.] Does TRIM_ARSPD_CM definitely not control cruising speed (when no airspeed sensor is used)? I remember setting this to the equivalent of 30mph (and not changing TRIM_THROTTLE) and then in subsequent flights, observing that it had the desired effect of changing the average cruising speed to 30mph. The documentation states that only TRIM_THROTTLE is supposed to affect cruising speed (when no airspeed sensor is used).
Dear all,
enjoying alot what you achieved! This week I tried out some auto land approaches with 4.1.0 beta which looks very promising, but still room for improvement.
Here is the video: https://youtu.be/RfChrJlRPzw
Specially the precision of the touchdown point is quite off as you can see in the logs (2m to the left, ca 30m too far). It also seem that it does not track the lading slope very well.
But I really dont know where to start with tweaking which parameter. So far I did Autotune, tune TECS (as far as I could), tuned LAND parameters and many others.
Logs here: https://www.dropbox.com/s/6ila5w38jkf0w63/21-08-20_18-32-14.bin?dl=0
Above landing is at appr. 13:45 minutes
Thanks in advance for quickly analysing the problems.
Cheers
Guido