Dev Call July 16, 2018 2300 UTC

Issues & Pull Requests





Hardware

GSOC

  • Update

Plane

Copter

Rover

  • Non-GPS position estimation using ROS

Attendee count (max): 21

UTC2302 - automatic compass orientation

  • Call for people to test this
  • Orientation is a constant curse
    • Too many logs showing people have gotten it wrong
  • External compasses get orientations fixed based on least-square-error from calibration
  • On by default
    • Need to be really confident of this!
  • Need lots of people to test this!
  • One tester thought it was wrong
    • It turned out to be right and the user wrong!
  • If there’s not enough testing we might need to turn it off by default
  • Only operates on external compasses
  • Tridge is thinking of changing it so it errors out if your internal compasses get the wrong orientation
  • MdB wants compass-cal messages to contain the error message
    • Still need mavlink1 text messages
  • MdB has concerns about fitness scaling
    • If it fails then it adds 1000 to the fitness to make fitness bad
    • So GCS that have completely moved to mavlink-based reporting don’t confuse the users with a very low fitness
      • I.e. good number with failure
      • E.g. it fails with 1000.2 then we know it was because the user’s orientation was wrong
    • https://github.com/ArduPilot/ardupilot/pull/8927/files#diff-3e07895a0da57267a05c962290715e46R816
    • With mavlink2 extension we can display what orientation it found / confidence level in orientation
      • But should still frob it for mavlink1 / old GCS users
      • Add Orientation failure to enumeration
      • Set to fixed value rather than 1000?
        • Tridge wants to know what the fitness was
        • Can fail for two reasons
          • Orientation wrong (internal compass wrong orientation)
          • Maybe just a really wacky compass
            • Knowing fitness is bad gives you more information
      • Add two enumeration values
        • Confidence-level- not-high-enough
        • Incorrect-orientation
        • Best vs second-best
        • Can then not need to add the 1000 offset
  • If orientation is equal to current orientation then it accepts any confidence level
    • I.e. only needs confidence in changing orientation
    • We only use orient on external compasses
    • Could have more values for compass_rot_auto
  • Mechanical engineers aren’t going to stop changing orientations
  • Determining orientation is incorrect is easy.
    • Determining correct orientation is harder!
  • Planes usually sort themselves out
    • Rejects compass
  • Multirotors can go very, very badly
  • [9:18 AM] (Channel) MdB: This does increase free ram requirement by 900 bytes, but it’s definetly worth it…
  • [9:18 AM] (Channel) MdB: (possibly more based on alignment)
  • [9:18 AM] To Weekly devcall: @MdB only during calibration?
  • [9:19 AM] (Channel) MdB: @Peter: Yeah
  • [9:19 AM] To Weekly devcall: Meh :slight_smile:
  • [9:19 AM] (Channel) MdB: Compass calibration is calloc()'d
  • [9:19 AM] (Channel) MdB: Yeah, as I said I think it’s worth it :slight_smile:
  • [9:19 AM] (Channel) MdB: Just noting that I’ve seen people fail because they didn’t have enough RAM
  • [9:19 AM] (Channel) MdB: So something like CAN/DF grabbing all available ram causes issues, but in general we have the memory
  • SITL can now set orientation on compasses
    • And elliptical errors
    • SIM_MAG parameters
  • JC has a new mag calibration maths workup
    • More rejection of groups of outliers
    • Arbitrary custom orientations?
      • Would require a good optimiser
  • Again! Please test this!
  • https://github.com/ArduPilot/ardupilot/pull/8927

UTC2324 - https://github.com/ArduPilot/ardupilot/pull/8872

  • Cleanup and conversation-starter
  • Short-term it’s less to compile
  • Long-term we should rearchitect so there’s a better split
  • AP_ADC is not a sane API at the moment so we wouldn’t want to base new code on it
  • Patches to use more ADC for e.g. battery monitoring?
    • MdB has them - but it’s all custom hardware
  • Could start a proper frontend/backend split?
    • Multiple types / multiple backends
      • HAL backend
      • ADS115 backend
  • Tridge is happy if Lucas is happy
  • Header has no code in it
    • Cpp file is empty
  • [9:29 AM] (Channel) FF: Merge!
    • merged!

UTC2329 - visca protocol redux

UTC2331 - AP_RCMapper

  • Kills some documentation which is pointless
  • MdB and Peter have both tested it
  • [9:32 AM] (Channel) jaxxzer: why don’t we just check the PARAM_FRAME
  • [9:33 AM] (Channel) jaxxzer: instead of adding another identifier (values)
    • This mechanism can cover more use cases
  • Already half-merged!

UTC2337 - https://github.com/ArduPilot/ardupilot/pull/7970

  • Not tested yet
  • Will test when JC finishes his ChibiOS rebase
  • The ArduCopter patch should go away
  • Needs tests for each of the cases
  • w/e it amounts to the same result
  • [9:39 AM] (Channel) FranciscoFerreira: The Copter commit should go away
  • [9:40 AM] AndrewTridgell is now muted.
  • [9:40 AM] AndrewTridgell is now unmuted.
  • [9:40 AM] To Weekly devcall: @FF I really hope the code in that commit isn’t ever crossed; it should be in the prearm checks.
  • [9:41 AM] AndrewTridgell is now muted.
  • [9:41 AM] (Channel) FranciscoFerreira: it is, which is why it’s not needed now
  • [9:41 AM] AndrewTridgell is now unmuted.
  • [9:41 AM] (Channel) FranciscoFerreira: it was needed before we always run pre-arm checks
  • [9:41 AM] To Weekly devcall: Any idea how this patch might have come about?
  • [9:41 AM] AndrewTridgell is now muted.
  • [9:41 AM] (Channel) FranciscoFerreira: As said, Jon did this for Matternet which didn’t have the pre-arm checks always running
  • [9:41 AM] AndrewTridgell is now unmuted.
  • [9:42 AM] To Weekly devcall: Oh, they were latching the

UTC2344 - CAN i2c splitter

UTC2345 - GSoC

  • Ebin’s making good progress
    • Tridge did some work on brushed motor support in IO firmware
    • Rebase got really messy
    • F103 support conflicted with f7 support
    • Complex rebase
  • Arnav’s doing really well
  • Three more weeks in GSoC

UTC2350 - Plane update

  • Positive feedback on F4 and F7 with latest Plane
  • Tridge is wondering about doing a 3.9.1beta RSN
    • Or put stuff in 3.9.0?
  • Autodetection of all compass types on small boards
    • Put a define in hwdef.dat saying probe for all external compass types
      • Like we do on Cube, PixHawk etc
  • Lots of OSD improvements
  • Leaning towards getting 3.9 out as-is
  • Nate thinks putting 3.9.1 out soon after 3.9 would look like a bugfix release
  • Tridge says he would make it clear it’s a feature release
  • Lots of people test-flying master on ChibiOS channel
    • MdB: release it now

UTC2355 - Copter

  • Safety-switch fix out in 3.5.7
  • Back to beta-testing 3.6
  • Pushed out 3.6rc6 now
  • [9:56 AM] (Channel) RM: https://discuss.ardupilot.org/t/copter-3-6-0-rc6-available-for-beta-testing
  • ChibiOS boards
  • Still quite a lot of issues outstanding
    • ~15 issues people have reported
    • Still quite some ways to go
    • Releases tend to take 3-4 months
      • Always something which makes it hard
      • This time it’s ChibiOS
        • Weren’t planning on making this “THE” ChibiOS release
          • But bringing ChibiOS support way up there
  • Need to document the various firmwares
    • E.g. the _bl thing
    • [9:58 AM] (Channel) RM: http://ardupilot.org/copter/docs/common-loading-firmware-onto-chibios-only-boards.html
    • Setting bootloaders can indicate board_type so if you can’t differentiate based on sensors you can still differentiate the boards
    • Dropdown list for boards?
      • Autodetection is probably going to be extremely problematic
      • [10:00 AM] To Weekly devcall: Maybe guess and ask for confirmation?
    • A README in each directory explaining what the files are?
      • Need to change auto-generation
      • Clickable link in each directory
      • Jani will look at
      • Release notes too?
  • A list of 15-odd issues that Randy’s looking at
    • D-shot not working?
    • Relays not working?
    • No noise during compass calibration?
    • Septentrino GPS not initialising?
    • Compass issues on fmuv4?
    • Logging not working on one board?
    • New-loiter rapid-deceleration problems?
    • Zubax issues?
      • Might be documentation?
    • RC failsafe triggered and flight mode switched?
    • Tuning gains for small copters
    • Bl53l0x lot working?

UTC0009 - Randy and Rover

  • 3.4.1 beta later this week
  • One bugfix in pivot turning
    • Nomination for contribution-of-the-month
  • Successful test of Rover follow mode
  • Working on non-GPS position estimation using RPi Lidar and ROS

UTC0011 - back to batteries

  • When we re-add the frontend/backend split it would be good to get the 115 code for batteries in

UTC0012 - call for more nominations to SPI liaison

  • Great update on finance stuff!

UTC0013 - github bot / issues / PRs

  • What does it do?
    • Does it auto-close?
    • Comments-with-warnings?
      • E.g. we are going to close this in one month or whatever
  • Do we host it or does github?
  • Issues are our todo list?
  • MdB a valid set of current PRs
    • If it is not on the first page it doesn’t get looked at
  • RM: What are we after?
    • Reduce embarrassment of open PRs?
    • Get more code in?
  • Tridge sorts by recent activity when looking at PRs
    • Sort-by-recently-updated
    • Rebasing may not make it recent-activity
    • Might need to add a comment on the fact it has been rebased
      • E.g. “Rebased on master”
  • FF wants to focus more on issues
    • Not closing PRs
    • Much more time spent on looking at issues than creating them
    • Automated system ensures issues are relevant
  • Tridge doesn’t want to see PRs automatically closed
    • Conversion of IO firmware to ChibiOS is an example of an old PR that shouldn’t be closed
      • And GPS timestamping
    • Can’t trust bots
    • Even if the user is nudged before it is closed
  • So just issues for the time being
    • Funding for an issues-master?
    • Can we make it more glamorous to work on issues?
      • So the community can work on things
    • Moving PRs to be first-in-call worked really well
      • Can we do issues in the call somehow?
        • Probably not
  • [10:25 AM] To Weekly devcall: I think we should try using the “devcall” tag on issues to see what happens.
  • CE: Sometimes there are issues that are tagged
  • Bounties?
  • Lots of people have lots of distractions
    • Interferes with their volunteer efforts
    • Need to get more time from more people
  • Some sort of team of people that triage?
  • [10:28 AM] (Channel) MdB: We also need to do a better job at seeing if changes we do fix old issues. I’ve closed ~20 issues in the past that we had already done but never closed
  • [10:29 AM] To Weekly devcall: @MdB we should encourage use of “Closes #xxxx” to avoid that
  • [10:29 AM] (Channel) MdB: Peter: I think a number of them were actually just unaware there was an issue it was addressing
  • [10:29 AM] (Channel) JM: Honestly hiring someone in Mexico is not so expensive
  • Some sort of university-course tie-in?
    • Like GSoC it would be a huge amount of work to teach people the ropes
    • Very broad range of skills required
      • Logic analysers
      • Uart protocols
      • Networking stuff
      • Communication skills
  • [10:33 AM] (Channel) RM: i think we can start with advertising that we’re looking for an “Issues Maintainer” role…
  • Start closing issues older than 3 years unless people confirm it is still an issue
  • Exempt feature requests?
  • So FF to start to play with the issues-culling system
    • But recognise need to have issues-maintainer
      • And discuss further
  • Project manager role?
    • Diverse project like AP might not take well to that
    • Difficult job
      • But could be done
    • Project management team! --RM
  • Merging PRs begets more PRs - merging may not reduce count
  • Does using an automated system or strict project management remove the fun, human, organic factor?
  • Tools help ensure issues that many people care about get looked at
  • [10:46 AM] (Channel) RM: i think we can’t expect the PM roles to get to force a dev to do something…
  • [10:47 AM] (Channel) RM: they can just advise and try and convince the devs…
  • Milestone tags?
    • Tridge finds them mildly useful
    • Were using them pretty well for a year or so
    • We’ve drifted away
    • RM uses projects instead
    • Giving people expectations would be nice
      • Requires management which is why noone does it
        10:53 AM] (Channel) JW: I think milestones is good for what you just talked about
        [10:53 AM] (Channel) JW: you just tag items for certain release
  • Community manager?
    • We had one in 2013/2014
    • We’re more organised now?
    • Craig is looking for sponsorship to help out there

UTC0050 - plotting thing

  • Working with Maxim on improving the plotting tool
    • Lots of features it didn’t have a couple of weeks ago

UTC0057 - CAN

  • Tom’s PR would seem to duplicate some work Olli’s done, which isn’t great
    • Wasted effort

Hello Everyone,

I have a question/proposition that is also related to issue and PR management.
Let me describe on the recent example (but this is not the single case of course):

So the problem is there no way to developer to know somehow that a design is discussed, is final and everyone agrees it.
As a result, there is a good chance developer will need to rework his original fix.

I think it makes sense to have some ‘DESIGN CREATED’ tag for that. So owners could tag a ticked after they believe the design is finalized.
@rmackay9 @tridge @CraigElder

1 Like