Dev Call Dec 7, 2020

Issues & Pull Requests

1 Like

ArduPilot Dev Call 2020-12-07


Attendee count (max): 19

UTC1100 -

  • Non-controversial PRs
  • Looks fine
  • Hard to validate the changes
    • Need some automated help
    • Something similar to EKF thing
    • Generate headers
    • Shift .h to one directory
    • Then do a recursive diff and show the user

UTC1107 -

  • Why doesn’t the RP lidar map the quality onto a covariance?
  • The field costs us bytes for no gain

UTC0114 -

  • Takes away option from user to specify the distances
  • Maybe take the minimum of the minimums?
  • Larger of the minimums, shorter of the maximums
  • Do whatever we do sending DISTANCE_SENSOR
  • Can be merged after the min/max think
  • Tag it documentation

UTC1120 -

  • Missing expected delays after flashing bootloader…
  • Not a grace period coming out of delay?
  • So any time we erase a sector we expect delays…
  • Peter will merge it later today after having a bit of a look
  • Internal error if you call delay for more than a certain amount of time and you’re on the main thread?

UTC1126 -

  • AP_Periph with only uarts
  • Doesn’t link in DMA code if you’re not linking SPI

UTC1127 -

  • SageTech driver
  • Base conversion is weird
    • Lose the generic nature of it
      • Just do the octal conversions
  • Avoid using brand names in serial protocols

UTC1146 -

  • Use singleton to get airspeed sensor rather than asking AHRS for it
  • Approved by tridge
  • Tom will merge when he’s happy

UTC1150 -

  • From last week, rename GND to BARO
  • BRD_OPTIONS bit to allow you to set parameters when you really want to be able to
  • Right at the beginning put the subsystem name in Description for parameters
  • MO will look at QNH
  • 10:59 AM] Peter Hall: fairly sure MP QNH is actually QFE

UTC1149 -

  • Includes the baro renames
  • Rebase has broken things…
  • Parameters broken by bad rebase
  • Multicopter compares tangential to rate of thrust to airspeed to get wind drift estimate
  • Use wind drift estimate with speed to work out correction for barometer
  • Using wind drift allows calculation of energy to return to home for mission optimisation
  • Two components of drag modelled
    • Normal drag (drag area * dynamic pressure)
      • Scaled with speed squared
    • Momentum drag (rotors produce lift)
      • Scales with speed
    • Two parameters
      • One based on area of copter
        • Frontal area
      • Second is measured drag at a specific speed
    • We print some estimates of what the parameters should be set to
      • SITL model needs to match real Copter
      • Tested on small quad
        • Within 1m/s of wind drift
    • Wind estimate goes over mavlink
    • VFR_HUD.airspeed becomes airspeed estimate
      • Only when this feature is enabled
  • Momentum coefficient and ballistic coefficient
    • Could be DRAG_
  • Sponsor of this work wants more precise height control
  • High speed on some multicopters causes low-pressure zones so the vehicle thinks it is too high
  • Once tuned, these coefficients allow for no change in height for forward speed
    • Position error coefficient
    • Ratio of static to dynamic pressures
  • Will be usable by Planes
    • Internal baro that gets sucked down in pressure or an internal suffering from rammed-air can both be corrected
  • Pusher-prop will give you a reasonable representation
    • Tractors won’t work with thrust scaling yet
  • Need a wind-based autotest for this
    • Needs to get correct estimate and direction
  • Can be merged mid-week without
  • Thanks to Watt’s Communication for sponsoring this very cool work

UTC0010 -

  • Fix guide mode spoolup and takeoff
  • Randy has put comments on this and he’ll discuss with Bill off-line

UTC0012 -

  • Kris found this problem
    • We may not push servo outputs with an undefined position
    • Servos might go thwack and put a hole in a wing
  • Init safety only after first loop
  • Merged!

UTC0014 -

  • ST note saying we shouldn’t let unused pins on the chip float
    • Pull them down
    • So they are less susceptible to electrostatic damage
    • We were defaulting to floating
    • External pull-ups means we don’t want to go all-pulldown
  • Phillip K hsa checked all of the mRo boards and this will be set on those
  • A manufacturer will need to check their boards for pullup/pulldown conflicts, create an exception list and then enable this option
  • Active pull-down
  • Push/pull and actively setting it zero
    • Drive-down not a weak pull-down
  • Need to poke manufacturers to check their boards
    • Look at current draw before and afterwards
    • Look at schematics for enable LEDs and the like
    • Undefined pins bad
    • Turning this on would turn LEDs off if they weren’t defined correctly
  • Actively used pins in the hwdef won’t be affected

UTC0021 -

  • No accel limiting when reaching waypoints was why we weren’t pivoting
    • Was fixed, caused other bugs
    • Reverted that and fixed it in another way
  • Reverse in acro mode and then into auto mode would cause mission to be done in reverse
    • Fixed
  • Bug in throttle nudging code where
    • No way of driving between wp speed and max speed
    • Get_pilot_desired_speed reused to fix
    • Anything non-zero may affect the speed
    • Takes the maximum of pilot input and the wp speed

UTC0029 -

  • Moving logging structures from Logger into NavEKF3
  • merged

UTC0030 -

  • Recent change impacts Plane a lot
  • Compass-less Plane becomes difficult to arm
  • Maybe we should honour COMPASS_USE and COMPASS_ENABLE in the sources stuff
  • Compass object specifies whether the EKF3 should use it?
    • Randy: Which sensor is used should be configuration in the EKF
  • COMPASS_USE affects lots of subsystems…
    • Users would have to change a lot of parameters….
  • No parameters in barometer library….
  • Airspeed does have airspeed_use
    • Airspeed_use 0 is typical for first flights
  • Randy doesn’t like the COMPASS_USE parameters etc
    • Source parameters into DCM?
    • Treat USE as an enable parameter
      • Trigger an error if you specify a source that doesn’t exist
      • You must set the source to None
  • A whole bunch of fixed wing pilots find they can’t fly because EK3_SRC_YAW is not-None
    • DCM would also have to get compass-use parameters?
  • Tridge wants and exception where we check the USE flag for compass
    • Treat a EK3_SRC_YAW of compass as None if compass is disabled
  • Randy: if you specify compass-for-yaw and you don’t have one then you’ve got a misconfiguration
  • Compass and airspeed are difficult to test on the ground pre-flight
  • VO is more modern…
    • TYPE parameter for enabling things
    • EKF decides whether to use it or not
  • Airspeed is used in lots and lots of places
    • Plane uses it all over the place
  • Kind of like rangefinder use….
    • E.g. turning off rangefinder for terrain following and waypoint navigation and EKF use
  • DCM and EKF3 are diverging in a compass-less Plane
  • We keep re-fusing the same heading again and again
  • People are looking at the actual issue of this PR

UTC0048 -

  • Glitch protection

UTC0053 -

  • Really ought to allow 0%
  • Merged this documentation fix

UTC0055 -

  • Makes sense
  • Servo max/min don’t do anything here…
    • Scales against them
  • Good change
  • Peter will rebase it

UTC0057 -

  • Decarotor support
  • Merged!

UTC0059 -

  • Merged!
  • Logging fix

UTC0100 -

  • Do we merge the paper-over
  • Tridge thinks a bit of a bug-hunt would be better than merging this

UTC0102 -

  • Merged
  • Prettier enums

UTC0105 -


  • CubeBlack users might get annoyed because the second lane is often unhappy

  • A bunch of people might start to get warnings in flight where they didn’t traditionally get them

  • Need an option bit for this?

    • Support nightmare….
  • Need to turn this off if we’re sending mav1

  • Need to create MAV_OPTIONS parameter

    • Rmackay9: GCS_OPTIONS or MAV_OPTIONS
  • We could create a new message

  • Partner had no visibility that their backup lanes were unhappy

    • High-reliability vehicles need it
  • Off by default

UTC0115 -

  • Random rudder movements would cause messages to GCS which is bad
  • Tridge prefers Peter’s branch so Peter will PR and move that forward

UTC0122 -

  • Lockup in scripting
    • If semaphore is held by scripting and we try to take it in parameter when queue is full
    • Disarmed lockup on vehicle if SD card goes out to lunch, potentially
  • Needs to be discussed with MdB

UTC0126 -

  • Consistent fence strings
  • Merged!

UTC0127 -

  • Bindings for location offset_bearing
  • Merged!

UTC0127 - Plane update

  • Tilt rotor push with Kris
  • Big tasks for 4.1

UTC0127 - Copter update

  • 4.1 progress
    • S-curves
      • Leonard has some work to do with terrain following
        • End up a long way from target altitude
        • S-curve output gets way ahead of vehicle
        • S-curves need to be “slowed down”
      • Peter will be reviewing
    • Switch to EKF3
      • Only a few tests failing….

UTC0029 - Rover update

  • No update…

UTC0030 - Community server with discord

  • Should we turn it into a community server?
    • If we start getting too much spam?
    • Might allow us to go multi-admin
    • Entry agreements into Community Server might be a thing?
      • Validated email address only at this stage…
  • Leave it up to tridge and Tom, but you might have to validate your email address…

UTC0035 - Close

1 Like