Dev Call Dec 21, 2020

Issues & Pull Requests




1 Like

Attendee count (max): 18

UTC1100 -

  • Can be merged
  • Need to do the mavlink rebase dance

UTC1106 -

  • Why is this a fix?
  • Nobody’s really sure, but it doesn’t hurt and isn’t release critical

UTC1108 -

  • Disarm option to not disarm if considered flying
  • Concerns about the vehicle not knowing if it is flying or not
  • Use disarm timeout?
  • Alternative idea: if you’ve just disarmed then we skip arming checks on re-arm
  • Randy isn’t sold on “safe disarm” subtle differences
  • Tridge has seen people fat-finger things so he’s sympathetic
  • Combined switch on transmitter?
  • Not merging this now. Need more input from people on whether it’s useful to have more slightly different RC channel options

UTC1120 -

  • Reworking integrators for Helis
  • Bill’s been working with Randy on these
  • Landing detector fixes
  • Resetting-i-smoothly
  • Still leaky-i by default
    • Will change over to this new scheme later
  • Very much relying on landing detector to work

UTC1125 -

  • Add simulated i2c airspeed sensor
  • Doesn’t switch us over by default
  • Can be merged when ready
  • Can use _sitl rather than AP::sitl()

UTC1128 -

  • Separate tester would be good
  • Arming checks moved into thearming library
  • Henry will test this
  • Can be merged on Henry’s approval

UTC1135 -

  • DSDL implies state-of-charge is required
  • Some of the canbus battery monitors can’t provide the field
  • Neither can the default ap-periph ones
  • Don’t know capacity of the battery
  • XT90 and that’s it.
  • Cuav has no can parameters
  • Ap-periph could use it if you use slcan and change the capacity but its a pain
  • If we started to just use soc we’d break things
  • This PR tries to only use the soc if it valid
  • Current AP_Periph assumes a 3300mAh battery and fills in SoC based on that
  • Two places capacity can be specified - ArduPilot and AP_Periph
  • Currently AP_Periph
  • No CAN field for capacity?
  • State of charge is a 7-bit integer
  • Full-charge-capacity in watt-hours
    • Predicted battery capacity, falls with aging
  • Users won’t know to fill in battery capacity in the AP_Periph?
  • What advantage does this have over the existing aggregation?
  • Need to know whether the CAN node actually has good information about the state of charge?
    • Or is it just a dumb monitor acting as a smart one?
  • Other sensor backends have two different types
    • We could with-state-of-charge and without-state-of-charge backends
  • Tridge wants to support this feature but in a way that doesn’t break existing use cases
  • New DSDL / new message?
  • ArduPilot option?
  • Would need to test the existing uavcan monitors to see what they put into cuav?
  • Couldn’t release this as it would utterly break existing AP_Periph users?
  • Change-behaviour options
    • Bitmask on a battery backend to modify behaviour
    • First bit being “ignore SoC from device”
  • DSDL doesn’t offer range of valid values
    • Not possible to indicate you don’t know the state of charge
  • Default for new bits should be to follow the standard (which will break AP_Periph)
  • Nice to see CAN battery monitors getting

UTC1155 -

  • Thrust-vectoring mucked up in master ATM
  • Disc stuff has to be switched on
  • Marco’s been working on disc stuff in RealFlight
  • Henry’s been testing other aspects of this
  • Lots of options!
  • Merged!
  • Pete and Henry to spend quality documenting time

UTC0001 -

  • Flushing parameters and whatnot on reboot
  • Enabling safety on reboot
  • Should be no pulses until something is commanded?
  • Can cut back the reboot delay
  • Can be merged after safety change is made
  • Notify library in AP_Periph coming…
    • Doesn’t fit on f103

UTC0013 -

  • Make uint16_max -1 release for any channel
  • Capability bit for whether you can release the upper channels?

UTC0022 - Plane update

  • Fantastic progress on quadplane channel
  • New Plane stable coming soon
    • Bug in EKF where it would fuse an unhealthy airspeed sensor
      • E.g. cable disconnected….
    • Testing to be done
  • High-altitude Plane stuff currently underway
    • Better atmospheric models
    • Flight testing over next few weeks

UTC0023 - remember to vote on current proposal to adopt outside project into ArduPilot!

UTC0025 - Copter update

  • Progressing towards 4.1 beta release
    • EKF3 and s-curves
    • Both a little difficult
    • Andy Piper still reporting EK3-still-initialising messages
    • If you wait long enough with no GPS or compass you can’t arm…
      • IMU+Baro flying
        • Paul: should work, need logs
    • Adjustments so you don’t need to turn off too many options when flying compass-less
    • S-curves
      • Some fundamental questions posed in review
      • Currently the flight patterns are squarer than they should be
      • Terrain-following issues have been addressed
        • Drastic terrain changes can cause target point to move too far
          • Can slow down the s-curves so the vehicle can catch up again
    • Maybe another month out from a beta
    • People who’ve test-flown it love it

UTC0032 - Rover update

  • EKF3 beta testing before Rover out
  • No s-curves for Rover in 4.1
  • Probably won’t be adding Rishabh’s 3D avoidance into 4.1 Copter either

UTC0034 - close

1 Like