Dev Call Jun 22, 2026

Development Team
1

CI workflows

Release Update

Issues & Pull Requests

2

Attendee count (max): 17

UTC2304 - CI ci · Workflow runs · ArduPilot/ardupilot · GitHub

  • Colcon possibly fixed withThomas’ patches
  • FFT
  • Lots of little problems fixed

UTC2306 - https://github.com/ArduPilot/ardupilot/pull/27767

  • ABOVE_TERRAIN frame in guided mode posvel case
  • Randy’s concerned that it is going in a different direction
  • Copter does guided wp following
  • Sub does “just go here above terrain”
  • Two different features here
    • Specify height above terrain
    • Terrain-follow to this place
  • Leonard thinks they might be misunderstanding a little
    • Copter does full posvelaccel
  • They want a rapid-update approach
  • Copter doesn’t support pos/vel terrain following
  • They’re setting a target at 10Hz and a target 10 seconds in front of the suv
    • Pilot can control yaw
    • Follow-the-carrot
    • Leonard can see why Randy doesn’t like it
    • Reminds Leonard of requests for Copter where no vel is specified
    • What they’re doing feels a little like zig-zag mode, a semi-autonomous mode which takes pilot input
  • Do we need another altitude frame type in mavlink so we can tell if you want to do terrain following?
  • Copter slews its altitude down as it is going over that way?!
    • Can’t do straight line unless you know what the terrain altitude is at that location
  • Leonard’s a bit worried about making sure things can move forward correctly
  • Leonard will chat with the sub guys

UTC2332 - https://github.com/ArduPilot/ardupilot/pull/30291

  • Add horizontal noise test for Sub
  • Needs a rebase but good past that

UTC2339 - https://github.com/ArduPilot/ardupilot/pull/33067

  • Add GPilot P1
  • MergeOnCIPass

UTC2339 - Tools: autotest: Copter: add test for time-constant change during a maneuver by IamPete1 · Pull Request #33464 · ArduPilot/ardupilot · GitHub

  • Roll over in stabilize mode
  • Need Leonard or Randy

UTC2342 - .github: fix ccache reuse between SITL build and autotest jobs by khancyr · Pull Request #33474 · ArduPilot/ardupilot · GitHub

  • Fix ccache flags
  • Merged!

UTC2345 - AP_AHRS: update AP_Notify based on active backend filter status by peterbarker · Pull Request #33476 · ArduPilot/ardupilot · GitHub

  • Update notify flags from the active backend
  • Merged!

UTC2346 - Correct matrix used for wind estimation in DCM by peterbarker · Pull Request #33494 · ArduPilot/ardupilot · GitHub

  • Correct matrix we use for wind estimation
  • Merged!

UTC2348 - AP_Logger: retry blocks when doing replay logging rather than dying by peterbarker · Pull Request #33520 · ArduPilot/ardupilot · GitHub

  • Make sure writing blocks succeeds
  • Change to timing out in wallclock time
  • Change to wrapping _WritePrioritisedBlock pure-virtual

UTC2358 - Add simulation support for HeliQuad by peterbarker · Pull Request #33521 · ArduPilot/ardupilot · GitHub

  • Add heli-quad simulation support
  • Bill will have a look

UTC0007 - AP_GPS: include attitude correction in moving-baseline GPS yaw by lthall · Pull Request #33380 · ArduPilot/ardupilot · GitHub

  • Correct geometry for moving-baseline-yaw
  • Currently looks at the horizontal projection of the GPS on the ground
  • If you are rolled then your apparent yaw changes
  • Want to avoid a loop between the state estimation and its inputs
    • If you include roll then your input is being permuted by the current estimator output!
    • We’ve already moved away a bit by looking at rapid-rotations
      • Pull angular velocity and check it in the sensor library
    • This partially breaks replay
    • If you tweak EKF outputs then your sensor input changes!
    • We should possibly fuse this in the correct frame rather than correcting the data
    • There’s already some yaw fusion techniques to choose the one that’s most accurate knowing the geometry of the GPS yaw
      • Tait-Bryan stuff in MagFusion files
    • EKF lane switch would change your yaw input!
  • Maybe do a projection on the data we get from the GPS within the EKF
  • Maybe put this inside an option bit?
  • Maybe we pass different measurements into the EKF rather than the yaw?
  • Need to check it’s the same for dual-antenna and two-GPS
  • We should push this through the DAL at the very least
  • Might still have a loop within the EKF
  • Leonard will look at error bounds based on the code
  • Leonard will also get it through the DAL
  • But this is probably just fine for flight

UTC0035 - Tools: autotest: Copter: add test for time-constant change during a maneuver by IamPete1 · Pull Request #33464 · ArduPilot/ardupilot · GitHub

  • Test which shows roll-over in stabilize mode if you change parameter at the wrong time
  • Flip mode shows a similar problem if you abort the maneuver
    • Maximally worse behaviour where it comes to a zero-roll-rate while upside-down
  • Leonard has looked at taking into account shortest-duration to get back to target attitude generally
  • Shortest-time-path in quaternions is hard vs shortest-physical-path
  • This is all known behaviour
  • Testis an interesting observation
  • This is kind of a fundamental thing where you’d decide to not change stuff based on e.g. your current movement rates or whatever
  • A case that might occur in reality?
    • Recovery from inverted
    • Backflipping quadplanes
      • Didn’t recover its attitude in time
    • New recovery code removes limits
    • New smoothing code is disabled when past certain angles
      • Unconstrained recovery
    • When you enter the constrained phrase, the numbers change meaning you might over-shoot
    • Input shaping only changes your target set-point
    • Attitude controller follows the set-point
    • A flipped aircraft where you want to be right-way-up this only changes the target
    • Its only the raw position controller trying to close the distance
    • You get as fast-as-possible a correction
    • Leonard thinks if changing the TC affects your recovery then the input-shaping may be mis-implemented
    • Mode-changes?
      • When the aircraft flips over the first reaction is to change mode
        • E.g. qloiter/qhover
      • When the mode change happens a reset might occur
        • Target might now move slowly from being inverted?
        • E.g. in forward flight CFG might be wrong and suddenly a nose-over-tail backflip occurs
        • If the pilot didn’t hold their nerve and flipped out of the mode then you might end up locking in a slow recovery
          • Leonard would consider that to be a mistake in the implementation
  • Input shaping still to be merged on Plane Plane: add input shaping to roll and pitch controllers by IamPete1 · Pull Request #32743 · ArduPilot/ardupilot · GitHub
    • Leonard’s happy to look at this!
  • Could potentially slew the parameter over time?
    • That’s a timeconstant for a timeconstant parameter….
  • Maybe change the test to lock in the current behaviour / be an example

UTC0104 - off the floor

UTC0105 - close