Dev Call Jan 3, 2022

Development Team
1

Issues & Pull Requests

Plane

Copter

Rover

2

Attendee count (max): 22

UTC1100 - magfit_WMM: support new compass param naming by IamPete1 · Pull Request #608 · ArduPilot/pymavlink · GitHub

  • Magfit for new parameters
  • Merged!

UTC1100 - https://github.com/ArduPilot/ardupilot/pull/17333

  • Make weather-vaning accessible to Copter
  • Useful if your Copter has an asymmetric body
    • If you’re being blown around by the wind
  • Gains equivalent to existing quadplane weathervaning gains?
    • Tridge thinks they may be higher-effect now
  • This weather-vanes during transition?
    • Should be a patch for that…
    • Might need another patch for tailsitters?
    • Back-transitioning was quite wonky with this new code
      • May have been the gains?!
    • Very aggressive yaw on de-transition
      • Tridge thought it might have actually lost control….
  • Should it be trying to yaw a tilt-rotor during back-transition?!
    • Probably not
  • will take this up on Wednesday evening….
  • Really wanted Randy to look at this patch-set as it affects Copter
    • Off by default
    • Could really benefit Helicopters
  • Works in velocity/position-controlled modes like loiter/autoland
    • “Turn into the roll” was the original algorithm
      • Try to roll right? Then yaw right.
    • This PR adds a factor for pitch
      • Exactly 180-degrees off then problems occured
      • Maybe an indecision problem?
        • Must have roll before doing anything
        • Only speeds up based on pitch
  • There’s ground-speed and climb-rate maximum thresholds
    • Works in region close to hover
  • Weathervaning is critical for quadplanes but not so much on Copters
  • This has been working well on a partner’s vehicle
  • There’s better heuristics than angle available in Copter vs Plane
    • But we’ll stick with lean angle

UTC1104 - Generate board list by peterbarker · Pull Request #18502 · ArduPilot/ardupilot · GitHub

  • Generate list of boards to build rather than adding boards
  • Need to make sure we’re not missing anything
  • New Build list Build List
  • Might be scripts involved for the HerePro?!
  • Peter will get this in later today

UTC1130 - https://github.com/ArduPilot/ardupilot/pull/18946

  • Correct division by zero in compassmot
  • Approved and can be merged

UTC1138 - Plane: tailsitter rate limit second half of VTOL transition. by IamPete1 · Pull Request #19286 · ArduPilot/ardupilot · GitHub

  • Improved transitioning for tailsitters
  • merged!

UTC1142 - Copter: Guided: When yaw is not specified use default yaw behaviour. by lthall · Pull Request #19592 · ArduPilot/ardupilot · GitHub

  • Someone was expecting nothing to be done with yaw
    • We did something with yaw
    • If someone doesn’t specify something we should use the parameter value…
  • Giving control of yaw back to pilot impossible in master ATM
  • Previous behaviour it would hold yaw if you stopped specifying
  • Now it will switch back to the yaw default if you stop specifying
  • If you want the old behaviour then change parameter to “never change yaw”
  • 10:49 AM] rmackay9: BTW I’ve improved the mavlink interface wiki pages MAVLink Interface — Dev documentation
  • merged!

UTC1150 - AP_Airspeed: Sanity check DLVR raw data before accumulating it by WickedShell · Pull Request #19625 · ArduPilot/ardupilot · GitHub

  • We have similar heuristics in the baro library
  • We really want some sort of filter function in our Math library
    • Tridge thinks the baro library filter is better than this one and we should use that as a basis
  • “Gate filter”
  • Tridge has approved this one
  • Can be merged on ci pass

UTC1158 - hwdef: set AP_OPTICALFLOW_ENABLED 0 for SkyViper-v2450 by peterbarker · Pull Request #19634 · ArduPilot/ardupilot · GitHub

  • Don’t include OpticalFlow on SkyViper
  • Merged!
  • Maybe we should exclude on 1MB boards by default?

UTC0001 - Copter: remove pointless wrapper around proximity init by peterbarker · Pull Request #19636 · ArduPilot/ardupilot · GitHub

  • Remove pointless wrapper around proximity init
  • Merged!

UTC0003 - AP_InertialSensor: use accels and gyros with lowest number of errors as primary by peterbarker · Pull Request #19641 · ArduPilot/ardupilot · GitHub

  • Use accels/gyros with fewest errors
  • Tridge would prefer not to switch
  • Different drivers declare errors for different reasons
  • Flip-flopping could be bad….
  • Closed

UTC0014 - Tidy Notch filter logging by peterbarker · Pull Request #19642 · ArduPilot/ardupilot · GitHub

  • Tidy notch filtering
  • Can be merged after changing to WriteStreaming

UTC0018 - AP_Arming: Implement ARMING_REQUIRE 3 aka AUTO_ARM_FORCE_CHECKS by Jaaaky · Pull Request #19645 · ArduPilot/ardupilot · GitHub

  • “Arm when ready” option
    • PH thinks this isn’t a good idea
  • Write a script to do it instead?
  • Tridge is thinking of removing ARMING_REQUIRE 0
    • Last user tridge knew
  • Use ARMING_CHECK 0 if you don’t want arming checks…
  • We’ll probably kill ARMING_REQUIRE 0
  • Not firing up forward motor is based on heuristics and they can be bad at boot time so you can end up with a dangerous situation
    • function update()
    • if arming:is_armed()
    • return – kill script after first arm
    • end
    • arming:arm() – try and arm every 5 seconds
    • return update, 5000
    • end
    • return update, 10000
  • Script will go in as an example for those that really want

UTC0025 - AP_Scripting: AP_Param: remove name helper functions and use alias by IamPete1 · Pull Request #19649 · ArduPilot/ardupilot · GitHub

  • Remove the name helper functions
  • We now have aliases supported in the binding generator so these old helper functions can go away

UTC0026 - AP_GPS: drop default GPS lag to 0.1s by tridge · Pull Request #19656 · ArduPilot/ardupilot · GitHub

  • Don’t know what sort of GPS is behind the CAN interface
  • Could be anything
  • Need a default lag
  • Were using 220ms
  • Average CAN is either M8 or F9 or whatever which have 120/110/90 lag
    • So default to closer to those expected values for a typical GPS
  • Detect type somehow?
    • We have magic string in CAN driver now
  • Why not ask the Periph device what its lag is?
  • uBlox knows the model number
  • Does Septentrino use it?
  • 220ms is an insane lag so you’d be insane to use it
  • Different lags for vertical/horizontal
  • Better would be to interpret the model string of the uBlox
    • Best would be to be able to request the lag from the AP_Periph device

UTC0034 - AP_Scripting: generator: use depends for singleton strings by IamPete1 · Pull Request #19652 · ArduPilot/ardupilot · GitHub

  • Depends for singleton strings
  • Merged!

UTC0040 - AP_Airspeed move into AP_Vehicle by hendjoshsr71 · Pull Request #18838 · ArduPilot/ardupilot · GitHub

  • Move airspeed into AP_Vehicle
  • Helis are going to like having airspeed
  • Skidding means we don’t assume fly-forward
  • Need to ensure EKF is in good order before turning on on Helis
  • EKF height with rangefinder is a bad idea…

UTC0054 - Plane update

  • 4.1.6 went out in wake of Copter 4.1.3 and Rover 4.1.3
  • Couple of extra things went into Plane
  • Battery monitor to 14 hang went back in
  • Gaps in EK3 logging went back in
  • Continue 4.1.x even after 4.2?

UTC0055 - Copter update

UTC0056 - tradheli update

  • Substantial progress on autotune
  • Needs another thorough review

UTC0057 - Rover update

  • SCurve updates are going well

UTC0057 - release strategy

  • 6 month releases
  • Beta this month
  • Stable release in April
  • Tridge and Randy would like to do that
  • 4.1 point releases might still want to be done?
  • LTS release?
    • Keep for a couple of years?
    • “Tapered release strategy”?
      • Backport really critical things
      • Further back that a stable release is the less likely a backport?
  • Probably not Copter-4.1-beta ?
  • Multiple stables at once?
    • There will still be only one “stable”
  • MP does allow you to flash older releases but you have to know how to find the page
  • Should we right now do a Copter-4.0.8 for the debug pin fixes?
  • Up to vehicle maintainer to determine what gets backported to really only stables
  • LH: Paid updates for those backports?
  • Some people are only moving to 4.1.x now
    • Current procedures wouldn’t have us patch those past April
  • Maybe just state 12 month support or similar
  • Some sort of planning timeframe
  • We’re being somewhat efficient about how things are done
    • Doing stuff piece-meal
  • Everyone seems agreed that backporting to multiple stables seems like a good idea
  • stable/beta/latest triple

UTC011 - no Copter 4.2 beta release yet

  • Might be pushed to late January as Randy’s currently lacking time
    • Maybe 2 instead of 3 months
      • More intense beta period
  • Releasing Copter/Rover/Plane procedure has been good where all patches get swept up
  • Are we lacking beta release testers now?
    • Seems to
    • Stable is too good / contains what people want/need
    • 4.1.2 got basically got zero comments
    • 4.1.3 got about 5
    • 3.6 got pages and pages of them?
    • Testing for dramatic new feature is easier than tests for bugfix
    • Asking individually would probably get a higher rate of testing but that doesn’t really scale
    • Provide better feedback to beta testers?
    • Badge system on Discuss/Discord?
    • New Plane autotune got a lot of beta testers
    • Quadplane VTOL users are using Kris firmware
      • Master + patches
      • Untested == very bad
      • We’re not getting fixes back into master
      • GPL violation

UTC0027 - Conference

  • Covid surge means conference will be online again in April
  • Travel will not be generally doable in April, probably
  • Time-lag and momentum means issues canceling late
  • Not going to hold it at a Hotel

UTC0028 - links to diydrones?

  • Nope

UTC0029 - Plane: add radius for GUIDED mode by magicrub · Pull Request #19297 · ArduPilot/ardupilot · GitHub

  • Add radius for guided mode for Plane
  • Include radius for given command then it is ignored
  • Come back to this one

UTC0032 - partners call tomorrow

UTC0032 - close

3

An observation from my somewhat brief time as a bleeding edge user of ArduPilot (probably skewed by some misperceptions):

Development seems to have ramped up significantly over the past year. Between September 2021 and present, there have been 7 major and minor releases, where in the 6 months preceding, there were zero, and prior to that (when I was testing and using moving baseline for Rover), development almost seemed stalled at times.

When releases were spaced farther apart, there was more time for beta testers to respond, and the changes were more significant, likely increasing motivation to test and try something new.

A few of the recent 4.1.x releases and release candidates have included bug fixes that were targeted to very specific audiences (many hardware specific), so it could be expected that feedback should be minimal.

In my own case, once 4.1.0-stable was released, I began to focus on 4.2-dev, specifically testing the Rover S-Curve branch. I continue to use 4.1.x on vehicles that are not my primary focus, and nearly all of the release candidates have included fixes for things I cannot specifically test.

EDIT: Reply count alone probably is not the best metric for determining beta tester engagement. A single reply can often be proof positive that a fix was successful or not, while many of the release topics include unrelated, drawn out discussion from new users needing help.

TLDR;
The pace of development has been refreshingly rapid lately, and as such, beta testers are probably less motivated to test minor bug fix releases while awaiting the “next big thing.” Perhaps victims of your own success!

The fixes? I’m not sure, but two suggestions above stand out to me:

I have always been quite happy with Randy’s direct feedback regarding testing, but other devs are less engaged here, which may be off-putting to some testers who may feel undervalued. More tester/dev engagement would likely be very welcome, including specifically asking individuals at times for their help in field testing features/fixes specific to their known hardware configs (perhaps that doesn’t scale well, but it does solve a near term need).

5 Likes
4

I think there could be a few things that could be done to streamline beta testing, first thing would be to get a list of beta testes and their hardware available for testing, that way if something new needs tested it’s not just left to chance, there will be a good odds someone that we know has the hardware that can asked to test it. It would also help with issues found on the forum where bugs are regularly discovered but end up difficult to diagnose without having another one to verify the results. Receivers, ESC and servo incompatibilities are seen regularly and it becomes difficult to determine if it’s an incompatibility or a bug.

If known beta testers don’t have the hardware put up on a front page notice somewhere with a list what the new hardware or features are that currently needs beta tested, very few people look at release notes.

If something has been confirmed working, it should be documented how it was tested and on what setup with what version of ardupilot so its much easier to replicate a known working specific hardware and software combination down the road to help with troubleshooting without spending hours searching through forum posts.

1 Like