Dev Call Aug 26, 2019 2300 UTC

Development Team
2

Attendee count (max): 26

UTC2304 - GSoC update

  • MAVProxy
    • Added several small PRS
    • Really useful stuff
    • Working on showing arbitrary expressions in the console
    • Nice blog post acting as final report
  • AirSim
    • Really nice report
    • PRs for AirSim and ArduPilot have been merged
    • Next stable build of AirSim will have ArduPilot support by default
      • With nice urban environment
    • Huge step forward, nice bit of work
    • Needs some testing under Windows, particularly with object avoidance and the like
  • Great work from both devs on MAVProxy and AirSim
    • Both planning on a little work after the period
  • Matt and autorotation
  • Pete Hall
    • Path planning stuff is working now
    • Tacking on geofence is in
      • Tested on the water
        • Video coming
    • Blog post coming
    • Lidar on sailboats to not bump into things
      • Visual stuff?
  • pp: --UPDATE — Thien has completed GCSoC on T265 last week , 3 wikis have been created and all PR have been merged. The experiment are still going on both indoor and outdoor

UTC2314 - https://github.com/ArduPilot/ardupilot/issues/11642

  • Solos locking up in flight

  • Interrupt storm theory seemed to be supported by evidence

  • Added storm prevention into ChibiOS

    • Limits number of interrupts to 6 per byte
    • Resets peripheral completely
      • Tried on Solo, instantly failed
      • Unacknowledged interrupt (BTF)
      • write/read on smbus peripheral
        • After it sends register address and waiting for ack we get constant interrupts
        • Continues until we get the ack
          • 130acks/4 for byte transfer
          • If the smart battery never acknowledges then the CPU spends time on interrupt stuff and can fall out of sky
          • Interrupt happens when going from dma write to dma read
            • Will not switch to read until ack is received for the initial byte

  • Storm prevention is mitigation

  • Acknowledging interrupt is fix

  • Could notionally happen on any i2c device

  • http://www.chibios.com/forum/viewtopic.php?f=35&t=5198&p=36118#p36118

  • Why not before?

    • Probably timing
    • Previously we didn’t have watchdog support so we put it down to power failure
    • With watchdog we can definitively say it was a CPU lockup
    • So it may have been happening before but we couldn’t attribute it to a software failure

  • No instances for 6 weeks

    • Rare bug to start with
    • Still not completely satisfactory
    • Could be changes to battery monitoring stuff?
    • Triggers particularly on 10-byte transfer
    • When we first turn on the battery it happens a lot
    • During flight fewer flights because ack was fast
    • Under some circumstances the device could be slow to respond
    • Shouldn’t fall out of the sky due to unresponsive device
    • Pattern of IO we’re doing with the battery monitor
    • Before watchdog it may have recovered?
      • 2 second glitch?
      • Fixed motor outputs

  • Speculation was correct

    • Can’t be absolutely certain as we couldn’t reproduce the lockup reliably

  • Timeouts don’t help in this case

    • 20ms timeout for the transfers
    • When the timeout goes off the calling thread becomes runnable
      • Doesn’t run because the i2c interrupt is always active

  • Do we port to stable?

    • Wait for testing reports back from master

  • Matt still looking at gimbal issue

    • With help from JC

  • Similar generic interrupt storm prevention for CAN and SPI probably coming

    • I2c is more susceptible to bus noise

UTC2320 - https://github.com/ArduPilot/ardupilot/issues/12140

  • Jaaaky’s been quite active!
  • Xplane….
    • No lockstep scheduling on xplane
    • Xplane defaults to type 10
    • Maybe trying to make it robust for type 2?
    • This may break fast sampling
      • Wrong timestamp for samples

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

  • Merged
  • Code isn’t “dead”

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

  • Adds something on stack…
  • Two messages?
    • One means harder to misinterpret logs
  • Merged!

UTC2332 - https://github.com/ArduPilot/ardupilot/pull/12110

  • Catch reboot time on receive
  • New message uptime
    • Confusing
    • Tridge would prefer “receiver rebooted” if we can manage it
      • Or just log the msss?
  • Would be nice to move it up for other backends to use
  • Statustext is valuable when you don’t get binary logfiles
  • Change to only print when reboot detected
  • Reboot detection method?
    • We have to redetect the unit
    • Msss is probably the best way to do it
  • Doesn’t quite achieve what it’s aiming to do
    • MdB will raise message rate to make detection reliable

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

  • Merged
  • PRIu stuff tridge doesn’t like
    • String concat stuff makes it harder to read
    • It is more correct
    • Add a static assert for unsigned length?
  • MdB hasn’t seen it before
    • Does like the look of it
  • Tridge commented and merged

UTC2342 - https://github.com/ArduPilot/ardupilot/pull/12098

  • No functional change
  • More of a discussion to be had on the logic here
  • Merged

UTC2344 - https://github.com/ArduPilot/ardupilot/pull/12089

  • Implementation on what we discussed last week
  • “A” vs “an”
    • Chose not to argue for 30m on the devcall
  • Merged!

UTC2345 - https://github.com/ArduPilot/ardupilot/pull/12069

  • RSC stuff into a library
  • Cleaning up motorsheli
  • Found some small logic issues between setpoint and passthrough
    • Would maintain RSC within old regime
  • Going to % rather than PWM
  • Made descriptions more understandable
  • Randy like the %
  • RL would like to do RPM or % control on RSC
    • With Chris’s governor implementation you do use RPM
    • Open-loop it doesn’t really matter
    • ESCs typically use a %
  • Chris would like to do runup based on RPM sensor
  • Feedback to pilot in % and RPM would be nice
    • Rather than PWM
    • So a pilot calculating required RPM based on air pressure etc has a simpler configuration
  • Tridge isn’t happy with the parameter conversion
    • Playing with indexes in parent tables means you can play around with indexes in subgroup much more easily

UTC2347 - https://github.com/ArduPilot/ardupilot/pull/12042

  • Retract mount when critical altitude reached
  • Should be altitude-above-terrain
  • Should be the same as landing gear

UTC2358 - RSC control redux

  • Leonard couldn’t weigh in due to technical issue
  • Multi uses normalised values by default
    • So using a percentage would be inconsistent with multi
      • Carrying around centi-degrees is a PITA
    • Trying to use -1 to 1 and 0 to 1
  • Leonard very much not in favour of percentages
    • MdB also prefers 0-1
    • AT: I prefer percentages for user visible parameters
    • MdB: UI can scale things to percentages though, but from an actual param/control I think 0-1 is a lot better
    • Better than PWM!
  • Using percentages may not be a good thing
    • SI units
  • Randy: Multicopters don’t use percentages. Rover and Plane often do
    • Consistency across vehicles would be good
  • Tridge: we also use percent/second in Plane
    • Slew rates
    • MdB: I want 0-1 in plane :smiley:
    • Percentage in science
    • 46 params use percentages
    • Slew rates
      • Stop and use time-to-complete in milliseconds
      • [10:07 AM] To Weekly devcall: @MdB - how would you do slew rates using 0-1 rather than %?
      • [10:07 AM] (Channel) Michael_duBreuil: time
      • [10:07 AM] (Channel) Michael_duBreuil: because slew rates are a problem as stands
      • [10:07 AM] (Channel) Michael_duBreuil: (partly due to the internal type we picked)
      • Copter uses Hz for very small time constants
        • Milliseconds for typical slew rates
    • We use uint8_t for space reasons
      • Rather than floats
    • Int slew rates are bad (MdB)
      • Changed mechanical things on an aircraft to get around things
        • Not good
    • Minimum slew rate
      • 1 microsecond/loop
      • So on a quadplane you can’t do less than 300 microseconds/second
      • Quantization issues
      • Need to change backend to use float PWMs
        • Tridge did try this but abandoned it after a day
  • Mixers in multirotors the convention used is -1 to 1 etc
  • Leonard thinks the parameter space is worth it
  • We only store parameters that are changed
  • 16kB is the smallest we have in terms of on-board eeprom
    • Split between parameters and missions
  • We should log the amount of parameter space into PM
  • MdB: how many are we actually talking about as well?
  • [10:15 AM] (Channel) buzz: is it time we started supporting parameters on SDCard?
  • [10:13 AM] (Channel) PH: don’t think we have any ratios or percentages in sailboats anyway
  • Problem: we have a difference in conventions across our vehicles
    • We should fix this but it is going to be very hard to do
    • Split Copter out from multi?!
  • [10:16 AM] (Channel) db: So we have an entirely supported SD infrastructure for logging, but we’re not willing to use it for reading a parameter file?
  • [10:17 AM] (Channel) MdB: buzz: logging writes, if you don’t write the file then sure no big deal make a new one
  • [10:17 AM] (Channel) MdB: Can’t load params? Now your vehicle is totally off
  • [10:17 AM] (Channel) db: yes, I’m aware SD card’s fail, but perhaps that’s a compromise that we could live with if there’s appropriate pre-arm checks etc in place.
  • RSC are all setpoints
    • So user-facing
  • 1376 4-byte floats
    • We never recover space
  • [10:19 AM] (Channel) RandyMackay: Here’s an issue created re logging eeprom size consumed
  • Rarely set parameters don’t cost much at all
  • [10:20 AM] (Channel) MdB: there is an issue already about throwing errors if we can’t log to eeprom because it’s full
  • [10:20 AM] (Channel) MdB: In many ways that’s a more critical issue :slight_smile:

UTC0018 - Rover and Copter

UTC0021 - https://github.com/ArduPilot/ardupilot/pull/11936

  • AP_Filesystem API
    • MdB will merge after he’s finished testing it
      • … and he’s currently patching other things

UTC0022 - https://github.com/ArduPilot/ardupilot/issues/11398

  • Receive buffer size change made the gimbal work nicely!

UTC0022 - https://github.com/ArduPilot/ardupilot/pull/11339

  • Noted that it was looking good but that it hadn’t been merged
  • Needs to be rebased
    • Tridge will try

UTC0024 - https://github.com/ArduPilot/ardupilot/pull/10020

  • Add peripheral firmware
  • Again pinging MdB
    • [10:27 AM] (Channel) MdB: yeah that’s me again
    • [10:27 AM] (Channel) MdB: I know
    • [10:27 AM] (Channel) MdB: I’m hearing
    • [10:27 AM] (Channel) MdB: and backlogged
  • Ifdef checks may break like the example code
    • Fragility
  • Merged, but MdB reserves the right to complain about this later when stuff breaks
    • [10:30 AM] (Channel) MdB: Old man hat for me I guess? :smiley:
    • [10:30 AM] (Channel) db: … future mdb says "I told u so’.
    • [10:30 AM] To Weekly devcall: We need to get MdB a lawn.

UTC0030 - https://github.com/ArduPilot/ardupilot/pull/9525

  • We don’t have a driver for this
  • Tridge is adding a note
  • If we get a driver in that needs this we can look at merging this
  • But at the moment this is an important protection for existing drivers where you can definitely expect data at >2Hz
  • Particularly important on SPI
  • tridge will add a note

UTC0033 - reverting https://github.com/ArduPilot/ardupilot/pull/12131

UTC0037 - Plane update with tridge

  • 3.9.10 went out yesterday
  • IOMCU UART handling fix
  • As previously discussed…
  • “That sounded odd” was worth chasing up
  • This would look like an unexpected motor failure

UTC0041 - close

1 Like