Dev Call Aug 13, 2018 2300 UTC

Development Team
3

Attendee count (max): 21

UTC2301 - SPI

  • Members removed due to them not voting
    • So some critical bylaws could be changed
  • Could not get votes through without doing this as a majority is required
  • [9:08 AM] (Channel) FF: Peter: if it helps, SPI meeting log will show up at http://spi-inc.org/meetings/logs/

UTC2305 - altitude frame type on vtol commands

  • Taking off adds altitude regardless of frame type
  • Relative vs absolute is ignored
  • Change this to understand the frame type on the command
  • MP doesn’t really support mavlink frame types
  • Patch as proposed doesn’t try to address the corner cases which might cause problems
    • The work should be done to ensure that we’re not going to crash with an existing aircraft
      • E.g. height errors causing vehicles to transition at 0m
    • If there are existing missions that have a relative height and then it starts being interpreted as absolute planes might get into trouble
      • Add a sanity check that your takeoff alt is higher than you are
    • Mission resets mid-mission may also cause issues
      • Even with the current code
      • Mid-air takeoffs adding altitude?
  • Maybe use a mission option bit
    • We use one bit to force vtol landings
    • Bit would say takeoffs are always relative (the current state)
  • Fundamental change
    • Could crash aircraft
    • Need to consider each scenario to make sure they’re OK
      [9:15 AM] To Weekly devcall: @MdB problem is that the “correct” solution here isprobably to bounce any mission items not in the relative frame as a sanity check. That would be the safe change.
      [9:15 AM] To Weekly devcall: (takeoff mission items!)
      [9:15 AM] (Channel) rm: i agree… relative is what most people use
      [9:15 AM] (Channel) MdB: Peter: you can’t bounce items when planning
      [9:15 AM] (Channel) MdB: (not this type anyways)
      [9:15 AM] To Weekly devcall: On upload or as an arming check.
      [9:15 AM] To Weekly devcall: I don’t think that’s a great solution. But safe.
  • The assumption that all takeoffs should be the same needs to be examined
    • Vtol takeoffs are almost always going to be relative alt
    • Having to calculate the absolute takeoff altitude would seem error-prone
      [9:16 AM] (Channel) rm: if the mission item is set to absolute frame though… then the alt should be interpreted as abs
      [9:16 AM] (Channel) MdB: rmacky9 thats the fundamental debate here…
      [9:17 AM] (Channel) rm: when you takeoff the alt is normally accurate though
  • MP has a checkbox to indicate whether all items are in absolute or all in relative
    • Nixes the idea of bouncing absolute takeoffs
  • Problem scenario if doing AGL in MP
    • VTOL aircraft OBC
    • Can only set AGL for entire mission with MP
    • AGL takeoff at remote location is a bad idea
    • Would need to set a 50m or 60m takeoff altitude to clear everything in the environment
      • Rather than a 30m to clear local trees
  • Maybe a new mission item that understood the frames correctly?
    • One implemented in terms of the other
    • We have a large address space now

UTC2326 - parameter threads

  • No return paths where you don’t release the semaphore
  • Want feedback from core developers on whether anyone is unhappy
    • C++ trick to guarantee semaphore release
    • Can still do the old way of doing it
    • Good pattern?
      • Less error-prone
      • Need to know about scoping
      • Can remove lots of gotos that are only there to release semaphores
      • Infinite blocking
  • FF is worried people people might use the semaphore to protect too much code
    • They already can with the existing take/give
    • AP developers will need to be more thread-aware i nthe future for AP development
    • https://godbolt.org/g/JFSVea
      • optimal
  • Tridge will be making a PR to move to the new semaphores
  • All good!

UTC2332 - servorelayevents

  • https://github.com/ArduPilot/ardupilot/pull/9107
  • Plane Mask off first channels as not available
  • Copter masks off motors channels
  • Doesn’t sit well with remapping
  • MdB would like help checking the logic
  • Mark channels as not-a-control-surface-or-motor?
  • Servo as sprayer pump
    • Should you be able to toggle it using the relay?
    • [9:37 AM] To Weekly devcall: They should be owned by the sprayer library (e.g.)
    • MdB owned by library
    • Wouldn’t work anyway as the sprayer would reset it
  • Check for K_NONE and you can’t use it for servorelay otherwise
  • MdB: MP has a servos page
  • [9:39 AM] (Channel) MdB: I have not clue how to use it though :stuck_out_tongue:
  • [9:39 AM] (Channel) MdB: I got confused the one time I tried :slight_smile:
  • [9:39 AM] (Channel) MdB: But its there for sure
  • Two categories of servo function
    • One-offs and multiples
    • Anything updated as an event might be allowable as settable from GCS
    • Rearrange?
  • K_none with servo channel
    • Can eliminate the mask
    • And the reboot
  • Sending statustext on rare error events is fine!
    • Low-bandwidth telemetry systems will have problems
      • Eating all the bandwidth
    • [9:45 AM] To Weekly devcall: “Failed to attach interrupt” is what I’m thinking - not high bandwidth!
    • [9:46 AM] To Weekly devcall: If you’re attaching interrupts in flight you’re probably doing something wrong :wink:
    • Some sort of new message to convey errors?
    • Add a minimum-statustext-severity-level on a GCS object?
  • Try not to add send-texts unless they’re useful
    • It’s not a great way to transfer information and is wordy
  • Rename a function to init
  • Will go with the k_none approach

UTC2351 - yaw from GPS

  • https://github.com/ArduPilot/ardupilot/pull/7215
  • NMEA thing
  • Pending for a long time
  • Rebased
  • Issues addressed
  • Ready to go?
  • Blocking reviews from MdB and FF
    • Please check whether you are sufficiently satisfied
  • Paul didn’t love the way it was integrated on EKF side of things
    • But could live with it
  • Dual antenna doesn’t necessarily give you heading
    • If you are flipped
      • How does the GPS know?
      • It may not
      • User must know
      • Might cause EKF to blow up if a user is manipulating their vehicle upside down
    • Does accuracy
  • Ekf3-only
  • Stepping-stone for supporting yaw from two GCSs
  • FF: https://github.com/ArduPilot/ardupilot/pull/7215/files#diff-0391c77a0ed972bb6a80621462b73883R231
  • can you explain this code Tridge?
    • Could probably be removed
  • How about if you stop getting yaw but still getting position?
    • Should stop using yaw of position unhealthy
  • Two parameters have to be set at the moment
    • One opt-in in EKF (source 5 for yaw)
    • Drop HDG_ENABLE?
      • But maybe there’s a bodgy device out there
  • Can’t be used with blending at present
    • EKF switching heading sources may be problematic
    • Pre-blending PR….
  • High bank angles?

UTC0008 - https://github.com/ArduPilot/ardupilot/issues/5988

  • Solo slew-rate software fix
  • No developments
  • General agreement it should be in as an optional feature
  • Leonard has been messaged on it

UTC0009 - broken follow-me on Tower

  • Probably change in relative-vs-absolute vfr-hud message
    • But could also be a change on the Android side
  • Follow-me arducopter
  • Anybody else out there with the skills?
  • Grant?
  • Bill?
    • Might be able to get to it
  • Use dev options bitmask to change behaviour?
  • Solex does everything Tower does (but costs)

UTC0016 - system-check fix

  • Merged!

UTC0018 - https://github.com/ArduPilot/pymavlink/pull/212

  • Which scenario does this cover?
  • Usually works…
  • Needs to be checked on Windows

UTC0021 - https://github.com/ArduPilot/MAVProxy/pull/529

  • Add an option for this

UTC0021 - new classes in ap namespace?

  • Instead of AP_Logger have AP::Logger
  • AP::Baro class and AP::baro() is a problem

UTC0026 - GSoC

  • Projects to be turned in by tomorrow
  • In future we should not permit development in private repositories
  • Separate repos for projects to make them reusable by both APSync and Maverick
  • Discoverability?
  • Looking at unmaintained repositories
  • Some of the GSoC stuff isn’t ready for prime-time
    • Tag them as GSoC2018 repositories in the name
  • Maybe in the Companion repo for some of these
  • Redtail
    • Uses docker image to work with ArduPilot
    • More self-contained and probably shouldn’t be added to APSync repo

UTC0036 - Plane update

  • Plane 3.9.1beta coming soon
  • Not rebased on master
  • Incremental improvements

UTC0037 - no-fly-zones on Plane

  • inclusions and exclusions and no-fly-zones
  • Contact tridge if you’re working on similar things!
  • Protocol for uploading static no-fly-zones may not be compatible with what QGC does
    • Would be nice to be compatible
  • https://www.youtube.com/watch?v=fRItYXRiEYY
  • Extension of AP_Avoidance
    • So not just running away or landing
  • OBC requirement

UTC0039 - no Copter or Rover update

  • As Randy’s run off

UTC0040 - AC_Avoidance fix