Randy: No GCSs rely on the bug. Peter: We should be using the method to get the value, not multiply manually. Andrew: Let’s use the AMSL accessor in the future.
Merged for now.
A: Would require testing.
Requires a switch to operate the engine.
Seems like a reasonable approach.
Missed an ICE_START_CHAN instance in a parameter file.
The hidden parameter technique is a valid approach.
Marked as needs testing, SITL will have to do, unfortunately.
Would be nice to prevent arming when there are old, non-existent parameters in parameters default file.
A: Needs flight testing.
Better also use the Filter Review Tool.
Andy: Tested on this new vesrion. A: Marked for backport.
Merged.
Andy: The changes are included in #27335. Let’s merge that instead.
It’s a wonder how this was working before. A: Closed.
A: Would be nice to tell between forward and rear transitions.
Apply the minimum it only in auto throttle modes.
Use does_auto_throttle to differentiate.
Also convert thrust_type into a getter.
A: Merged. Peter: The failing test is known flapping.
Peter: It now catches invalid numerical values. A: We’re better off rejecting invalid values in the future. Randy: Would be nice to have a pre-takeoff mission checker.
Approved. A: Merged.
A: Would be nice to have definite values in the enum members, to ensure that logs will be consistent.
Merged.
A: Leonard mentions a bug. R: But a fix has been merged already. Leonard probably approves. A: save_tuning_gains() is redundant. The current gains will be saved on landing anyway. P: Maybe it’s in preparation of the QuickTune integration. A: Soft disarming needs to happen before saving the gains. Otherwise only the first 30 will be saved. Andy, R: Could be a separate PR. A: Rescheduling for Tuesday.
Andy: A partner had an issue with the recommended 1/4. A: Okay, let’s give up on this prearm check.
Would be nice to know how much gain/phase/noise margin we need in each control dimension. Leonard: SYSID gives the system response. It doesn’t characterize noise effects.
And then SYDID would characterize hover only, while the issues will appear at the edges of the flight envelope. A: Flight testing with an increasing parameter (gain/attenuation/bandwidth) would be a fine approach for estimating those margins, no? L: Gain and phase margins are easier to measure, but you might still have no oscillation past the crossover, until something introduces the oscillation. A: Would be nice to have some way to warn users about blatantly wrong configurations. But perhaps it’s impossible to find one rule for all cases. A,L: (Discussion on the potential existence of a valid/reasonable and at the same time useful checking threshold.) A: Merged.
A: Ideally we would want these parameters to appear only for the Septentrio backend.
(Bonus coding session included in the dev call.)
Chiara to test Andrew’s commit.