Dev Call July 22 2019 2300 UTC

Development Team
2

Attendee count (max): 19

UTC2304 - GSoC student updates

  • Matt - autorotation
    • Autonomous Autorotation - GSoC Project Blog
    • Last week close-to-real-=life testing of autorotation controller in glide and entry phases
      • A few issues getting the RPM sensor working correctly
    • Test heli is very small
      • Glide phase drops like a stone
      • Everything-or-nothing feel to it
      • Started to add an incremental power loss function to avoid loss of aircraft during testing
        • Unsure if this will go into the final version
        • Hooked in at the AP_Motors level
        • Additional case in the heli RSC
        • Curtails PWM relatively directly
          • Need to be careful not to annoy the ESC
      • Should still be a useful test vehicle
      • Chris can test on a larger vehicle
      • Testing with some power input - is this valid?
    • Favourable flying conditions in short supply in Wales
  • Pete (via Matt as Pete couldn’t make the call)
  • Akshath
    • A few issues to go through before the param editor is ready
  • Rajat
    • Accepted the AirSim PR - it is in master
    • Corresponding PR is still pending in AirSim repository
    • Documentation is coming
    • Scanning LIDAR support soon!
    • Downloadable environments are platform-specific
      • More work on Windows vs Linux

UTC2322 - https://github.com/ArduPilot/ardupilot/pull/11857

  • Can’t be tested under SITL ATM
    • Extend to three IMUs so we can test it
  • Can be merged once confirmed it has been tested
  • Peter will put on a cube after the call

UTC2328 - https://github.com/ArduPilot/ardupilot/pull/11843

  • Add EDN format
  • Always run emitters
  • Merged!

UTC2329 - https://github.com/ArduPilot/ardupilot/pull/11830

  • Needs testing on the pass-through
    • Blheli

UTC2336 - https://github.com/ArduPilot/ardupilot/pull/11829

  • Timing is critical for blheli
  • Can’t actually spend too much time parsing this as that’s our current role

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

  • Not perfect but better
  • Merged!

UTC2339 - https://github.com/ArduPilot/ardupilot/issues/11732

  • Randy is going to look at this
  • Devcall removed

UTC2339 - https://github.com/ArduPilot/ardupilot/issues/11519

  • Randy is going to look at this
  • Devcall removed

UTC2340 - https://github.com/ArduPilot/ardupilot/pull/11673

  • PID updates to include additional filters
  • AC_PID
    • Used to have ATC_RAT_ROLL (rate to run roll filter)
    • Sometimes it’s a filter on error some a filter on the d-term
    • Sometimes we had a separate filter e.g. filtering feed-forward
    • Three different filters which apply to different things
    • E.g. FLT_D for D-term
    • FLT_T (filter target)
  • Affects all vehicles
  • Last step before merging is making sure we haven’t broken anything
  • RealFlight testing for quadplanes would be good
    • Has been flown for Heli in RealFlight
      • Param upgrade worked
  • Testing from (e.g.) Mark would be good for tailsitters
    • Doesn’t currently have a flyable tailsitter
    • but can test in SITL
  • Parameter upgrade testing
  • Real vehicle testing?
    • Has it been flown on a quadplane?
      • Not yet
  • Filter in AC_PID used to be used for different things - d term or error term
    • Autotune couldn’t be generalised
    • Also made them inapplicable to things like singlecopters
  • We have good filtering on gyros
  • We still get a lot of noise via the EKF into the controllers
    • Also RC input as a 50Hz step
    • Target low-pass-filter allows us to smooth that out
  • Should be benign on quadplanes as they’re just running the quadcopter controllers
  • Last thing is that you can set things to zero to get current behaviour
  • Some interesting history on AC_PID vis-a-vis Helis and what the PIDs were applied to
  • Will allow filter on d-term on yaw (as opposed to error)
  • Other sources of noise?
    • Dt?
    • https://github.com/ArduPilot/ardupilot/issues/10562
    • There are three sorts of dt which are relevant
      • Delta-angle dt
        • From AP_InertialSensor
      • Aspirational loop time (sched-loop-rate)
      • Actual loop time
        • get_last_loop_time_s
    • Really after the delta-t of the samples
      • Can we propagate the sample time?
    • We can do a short-dt
      • Update to angle coming from one IMU sample
        • 1000th of a second
      • Could be 4 IMU samples another time
      • Can vary by a factor of 3
    • Dt we’re currently using is unclear
    • Could model the timing jitter as a noise source and fixed with filtering
      • Fast filter rates are problematic with that
        • Locking gyro reads to PID loops would fix this
        • E.g. every second sample we take from primary gyro we run the PID loops
  • http://ardupilot.org/copter/docs/tuning-process-instructions.html
    • New documentation for tuning multicopters
  • All aircraft should consider adding a target filter
  • RC input shaping is weird
    • Particular for slow/precise movements

UTC0008 - https://github.com/ArduPilot/ardupilot/pull/11470

  • Probably OK
  • Tridge wants to think about it more

UTC0011 - https://github.com/ArduPilot/ardupilot/pull/10970

  • Can’t do chains yet
  • Can do OreoLed-style colouring
  • Currently instantiates the OreoLED driver to get access to stuff
  • Reworks the d-shot code quite substantially
    • Will need to look at it at a logic-analyser level
    • This must be done
  • More testing and a bit of rework required

UTC0018 - smart battery hold-up

  • https://github.com/mavlink/mavlink/pull/1072
  • Maybe a PR to make this non-WIP?
  • … and another against ArduPilot to bring it in
  • PR against ArduPilot should be done first
    • Often discovers, “oh my, that’s silly” things
  • Another enum for smart battery
  • Smart-battery-info less often than smart-battery-status

UTC0025 - EKF origin unification

  • Need to get back to this!
  • Sea-level vs current height issues?

UTC0028 - Copter updates and Rover

UTC0034 - Cube and target temperature

  • Two different IO firmwares based on pin polarities
  • Newer Cubes have different polarity on pin
  • Autodetection didn’t work so well
  • Apparently a temperature fuse in most recent Cubes
  • There are non-Hex boards out there with heaters
    • So autodetection is a doubly bad idea there
  • [10:38 AM] (Channel) davidbuzz: read temp, pull pin a random direction, wait X seconds, read temp again, see if it’s gone up or down.

UTC0035 - Harmonic notch filters

  • Use feedback from e.g. RPM sensors to set frequency
  • Leonard has tested and it is working well
  • But needs help looking at the implementation
1 Like