Dev Call June 25, 2018 2300 UTC

Development Team
#1

Conference

Issues & Pull Requests













GSOC

Copter

  • Update

Plane

  • Update

Rover

  • Update
#2

Attendee count (max): 24

UTC2300 - conference update

  • Congrats to Randy and Tom for an award
  • And Jani for an appointment
    • Vice President of china uav group
      • Huge well-funded UAV group
      • Funders of conference
  • Photos https://photos.app.goo.gl/w23i4szmwEws4jj36
  • Conference went really well
  • Mostly local Chinese manufacturers
  • Thanks to Hex for the beautiful both!
  • Million quadplanes there
  • Lots of military stuff there
    • “Uncomfortable amount”
    • Over 30%
    • Big UAVs
    • Large quadplanes and mulitcopters
  • Should get at least 3 or 4 new partners
  • Treated very well
  • One day of speeches
  • Some similar to Canberra speeches
  • Tom did a great git one one
  • Some great individuals came around and chatted
  • Robsense guys
    • Showed videos of their swarming stuff
      • Impressive
      • 50 drones or so
  • SkyViper swarming!
    • 10 or 20
    • On gitter?
    • Randy Mackay
    • @rmackay9 09:40 I met three developers at the recent Shenzhen conference who had done a drone swarm with a bunch of skyrocket drones. I’ve misplaced your business card so please ping me!
  • Videos need to be edited
    • Tom’s phone has a 15-minute limit on videos…
  • All talks in English except one speaker
    • And translators for both directions English <-> Chinese
      • Translators asked about a few vocabulary words
  • Engaging more with the Chinese developer community would be a good thing to do
    • Language barrier makes it a little difficult
      • English-text-driven
    • Need a couple of Chinese-speaking-developers who can act as some sort of gateway?
    • Things like universities
    • Next conference in October will have a lot more developers
      • This was a bit more like Interdrone
      • Next conference will be more developer-heavy
      • Might be more of a developer-culture-connection there
    • Should we have a Chinese-language section on our forums with moderators to bring things across?
  • Great-firewall didn’t block everything
    • Everyone’s got VPNs
  • WeChat integration is amazing!
    • Everyone uses it!
    • Pervasive
    • Us hopping onto WeChat wouldn’t help because of language barrier?
      • Machine translation is embedded!
        • Philip: it does work!
        • Randy: used it for a while after previous trip
          • Someone else would translate it for him
    • Privacy issues with WeChat?
      • “No worse than Skype?”
    • Probably works on every platform you could think of
  • Tridge: China is a huge group of people
    • More people coding AP in China than the rest of the world simply based on numbers?
    • [9:15 AM] (Channel) JW: http://rovmaker.cn/
    • [9:15 AM] (Channel) JW:
  • Hex has people engaging with these developers full-time
    • Creating an ArduPilot training school
      • As in physically building a training school
        • See this in October conference!
    • Fluent English speakers from Hex in the booth every day!
  • MQ - zig-zag mode
  • Hex conference
    • Food will be awesome!
    • Booked out entire hotel
  • TP: https://photos.app.goo.gl/w23i4szmwEws4jj36
  • [9:53 AM] (Channel) TP: Huge dump of pictures from ShenZhen 2018

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

  • Correct edge case on arming
  • If primary compass is unhealthy we would assume you weren’t trying to use compasses at all
    • Instance vs non-instance call
    • Looks good to tridge
    • FF has concerns about the learning behaviour
      • Existing behaviour
    • Compass-learning means we don’t use the compass initially until we’ve flown for a while
      • Need to fly around a little before you can switch to a position-requiring mode
  • Merged!

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

  • I2c bus mask
  • Luis’ fault
  • Lucas provided feedback on the API which needs considering
  • Behaviour unchanged for existing i2c buses
    • E.g. Cube has 2 i2c buses, one of them notionally internal
      • Compasses they both look external
      • Didn’t want to change ordering of compass
        • Made a more complex change to preserve ordering
          • To avoid recalibration
        • Automatically reorder based on compass IDs?
          • Shift offsets around based
    • You could have lots of i2c buses, particularly on Linux boards
  • Startup on Linux and bus-ordering guarantees?

UTC2331 - https://github.com/ArduPilot/ardupilot/pull/8699

UTC2334 - https://github.com/ArduPilot/ardupilot/pull/8698

  • AP_RangeFinder
  • Enable parameter?
    • Lots of parameters even if you don’t have rangefinders
  • This would hide 38 parameters from the GCS
  • Tridge thinks it is reasonable
  • Parameter CRCs instead of enable parameters?
    • Enable parameters are hard to cope with on the GCS
      • Don’t know which are enable parameters
      • Hard to do UI based on it
    • Take CRC of all non-volatile parameters, package with parameter download
      • Allows GCS to cache
      • CRC itself is a virtual parameter
    • GCS do a param-request-list
      • Vehicle sends fake hash-crc parameter which has the CRC in it
      • Then it start streaming parameter in normal way
      • Then GCS can see hash, check the hash for a hit
        • If it doesn’t match, just continue
        • If it does match, the GCS sends the parameter back with the same value and the vehicle should stop streaming
    • How do you blacklist a parameter?
    • Are gyro offsets sent?
      • We calibrate gyros at boot
      • So we could stop streaming but volunteer the volatile parameters
    • Waypoint count?
    • GND_TEMP?
      • Used for correcting barometer in-flight
    • [9:43 AM] To Weekly devcall: One interesting problem - when we volunteer a parameter we use 65535 as its parameter number
    • [9:44 AM] To Weekly devcall: We only use a sequence number when doing the streaming. So we’d kind of need to “filter” the stream rather than halting it, I think.
    • Parameter download over radio is brutal
      • This can make it faster!
      • Increasing parameter rate would help
    • Enable parameters give QGC fits
      • Fixed-wing to quadplane is OK
      • But the battery stuff is tough
    • Download-range method instead?
      • “Give me the following 20 to 30 parameters”
      • Still may have that initial 15 seconds, which Don doesn’t like
    • JW: I’ve played with the crc32 on stm32 before
    • [9:49 AM] (Channel) JacobWalser: hardware crc32
    • Maybe we should volunteer parameters when an enable parameter is enabled
    • Should we send all parameters and leave it to the GCS?
    • Maybe we should tell the GCS about changes to the parameter structure
      • E.g. there’s new parameters in this range
    • MdB: it’s 17 per batt monitor, about to be 3 monitors soon ™
    • 17 params per battery monitor
    • If you enable a battery monitor in QGC then you have to wait for the parameters to arrive before Don can show the user interface
    • Hash of a group of parameters
    • Enable parameter advantages
      • Bandwidth
    • Vehicle setup parameters often have UI built around them
    • [9:56 AM] To Weekly devcall: I wonder how much faster we could make parameter download if we were to compress things. parameter strings are all 7-bit-clean and are very repetitive!
    • [9:57 AM] (Channel) MdB: Peter: more win to just stream faster first :slight_smile:
    • [9:57 AM] To Weekly devcall: @Michael 900MHz radios still suck :slight_smile:
    • TP: I’ve always HAAAAAAATED the _ENABLE hiding. Always.
    • Split enable parameter into two
      • Major-subsystem flag
      • Minor-subsystem flag
      • GCS can choose behaviour?
        • Parameter has no-bits-set or other bit set
        • Changes what gets sent
        • Extra command to set level
        • UI elements will refresh immediately on QGC
    • Mavlink2 on USB?
      • [10:00 AM] (Channel) TP: would LOOOOOOOOVE better Java support on MAVLink2
      • [10:00 AM] (Channel) MdB: tom… lol
      • [10:00 AM] (Channel) TP: MAVKink v2 is pretty much only supported in C
  • Rangefinder PR will be held open pending the other one

UTC0005 - https://github.com/ArduPilot/ardupilot/pull/8695

  • Randy was generally ok with it
  • Changed some behaviors like usb led dimming
  • Changed some of copter ekf handling
  • People do connect companion computers via usb, so they are not getting all protections we should offer
  • Randy absent for approval now, we believe peter, merged

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

  • Tridge has gotten a little obsessed with GPS time over the last week
  • Hooked up PPS pin
  • Patch which allows use of logic analyzer to look at timings
  • Synthetic PPS
    • Lags real one by about 60ms
  • Needs flight-testing
    • Timing jitter just plummets a lot
    • Nate?
    • [10:09 AM] (Channel) Naterater.mobile: YES
    • Amilcar also had a great test setup for this
    • May need to change EKF’s expected-lag
      • To ~60ms
      • Ask GPS what lag is
        • Ekf2 does
  • Forward propagation of timing data into EKF can go in after this one
    • eliminating another 10ms
  • Most GPS you can’t get the pps signal out
    • Usually shielded
    • Press-button-for-safety switch could have pulses on it?!
  • [10:14 AM] (Channel) TomPittenger: hey @MdB, please take a look at this https://photos.app.goo.gl/9GRk4h4AdP34vkRMA

GPS L1/L2 module, about $350 today, hoping to be $250 next year

  • Here2 should have PPS

UTC0016 - sub remove forward/lateral

UTC0020 - https://github.com/ArduPilot/ardupilot/pull/6842

  • Ppoirer would be a good person to test this PR
  • And Grant
  • Rover would still need to be done
  • merged!

UTC0025 - moving reboot up

  • Scope traces show it appears to be working as expected. Tested with Hal Nuttx.
  • Jacob can test within the next day
  • Can be merged after that

UTC0029 - https://github.com/ArduPilot/ardupilot/issues/8670

  • See also Discuss forum post where RTL caused bad behaviour

    • No log but there is video
    • RTL was probably triggered and turn happened to close to the ground
    • Should we be climbing before any turn after an RTL is triggered

  • Knowing where the ground is can be problematic

  • Demanding a climb can also be a problem if you are dead-stick

    • Timeout required in this case?
    • Pulling up if you don’t have power is likely to induce a stall
      • Battery failsafe says don’t pull up
      • Gcs might mean pull up

  • Any parameter would be obvious in hindsight

    • RTL_TURN_MIN_HEIGHT
      • Certain number of metres above home before turning in RTL
      • Differences between takeoff and landing altitudes…

  • Plane below takeoff height in this case

    • Stabilize -> RTL

  • 10:33 AM] (Channel) MdB: Also for a lot of use cases you must turn in RTL for a lot of situations

  • [10:33 AM] (Channel) MdB: Climbing first is untenable for field clearance reasons…

  • [10:33 AM] (Channel) MdB: It’s a fallback outside of the mode page (gets to be failsafes)

    • Indefinitely climbing is a no-no in most circumstances
      • So a timeout and/or distance timeout
      • Consider geofences too

  • Terrain data would give a rough estimate of height

    • We have code to limit roll close to ground

  • Command take-off mode before doing the RTL?

  • Higher than point you entered RTL?

    • Limit bank angle based on height you entered RTL?
      • Wingtip-dragging-prevention
      • All autonomous modes where you are trying to climb?
        • Or maybe just RTL as MdB has use cases which would be problematic for all modes

  • [10:39 AM] (Channel) MdB: Has to simply give up on the limit if the vehicle is reasonably close to the target alt…

  • [10:40 AM] (Channel) LV: for a corner case, without data, are we changing behaviour ?

  • [10:40 AM] (Channel) Naterater.mobile: But if you’re on a legal altitude ceiling, that may be bad.

    • [10:41 AM] (Channel) LV: that has been in use for years

  • [10:41 AM] (Channel) Naterater.mobile: There’s data in the discuss forum post linked in the comments.

UTC0040 - GSoC Balance Bot ready-to-merge

  • Assigned to Randy

UTC0042 - GSoC funding request

  • To funding committee

UTC0043 - Copter update

  • Not much to update people on since last week
  • 3.6 our door soon
  • Rc3 out soon
    • Critical fixes from tridge
    • Rebase?
    • Or cherry-pick in?
    • Might rebase then remove problematic patches

UTC0045 - Rover update

  • Rc1 is still out there
  • Lane-based controller slowing down for corners etc
  • Doesn’t slow down as much in some situations
    • Old code would make it slow down more in some situations
    • Problem for very slow vehicles
  • Has been working with Leonard on ideas for future cornering algorithms

UTC0047 - Plane update

  • Plane will be rebased for the beta

UTC0047 - build system changes

  • Trying to make build system a lot faster
  • Dependency stuff has changed so if you see something odd please report it!
  • [10:50 AM] (Channel) tridge: http://firmware.ardupilot.org/Copter/latest/sparky2/
  • Our own bootloader is ready
    • Bootloaders built and in our tree under Tools
      • https://github.com/ArduPilot/ardupilot/tree/master/Tools/bootloaders
      • .hex-with-bl
        • Betaflight / inav / cleanflight tools can flash with their own tools using DFU
          • Much more accessible for betaflight etc users!
          • Try AP by clicking on existing tool and saying “load”
          • With-bl initially (will wipe parameters not-in-fram)
          • Without-bl usually (won’t wipe parameters)
    • Uart-loading on multiple uarts
    • Change baud-rate as part of upload supported
  • PR for Wiki about how to create a bootloader using hwdef.dat
  • Updating bootloader can be problematic for users who can’t use dfu
  • CAN?
    • Size constraints, but working on it
    • Handy for upgrading peripherals
  • Old bootloader was a pain for F7
    • [10:53 AM] (Channel) Naterater.mobile: Can we now make ESC firmwares? Lol
    • [10:53 AM] (Channel) JacobWalser: I’m working on some Nate
    • [10:53 AM] To Weekly devcall: @Jacob: for stm32?
    • [10:54 AM] (Channel) Naterater.mobile: I’m waiting for bi-directional BLHELI support through BL_heli (not just PWM)
    • [10:54 AM] (Channel) Naterater.mobile: *Patiently waiting
    • [10:55 AM] (Channel) JacobWalser: It should be there, we use it in all our vehicles
    • [10:55 AM] (Channel) JacobWalser: not sure what you are asking for
    • [10:55 AM] (Channel) JacobWalser: @peter yes stm32
    • [10:56 AM] (Channel) Naterater.mobile: https://github.com/ArduPilot/ardupilot/issues/8579
    • [10:56 AM] To Weekly devcall: @Jacob So a replacement for the closed-source?
    • [10:56 AM] (Channel) JacobWalser: yes sir
    • [10:56 AM] To Weekly devcall: Sweet. Do you have a workflow for developing it?
    • [10:57 AM] (Channel) JacobWalser: Yes, I’ve got some hardware hacked wired up and ready to go
    • [10:57 AM] To Weekly devcall: Nice!
    • [10:58 AM] (Channel) JacobWalser: https://photos.app.goo.gl/etERkEoBFDQdvWDg8
  • SD-card-based-updated in the future
    • USB would probably be more convenient anyway
  • Fmuv2 v3 and are all done, too
    • V4 soon
  • Mavlink command for updating bootloader?
    • [11:04 AM] (Channel) FF: +1 for a MAVLink command!
    • Hard to recover a PixHawk2 - really need a JTAG adaptor
  • Tridge has been working with David Sidrane on board IDs

UTC0107 - marketing committee vote

Sky Viper v2450 GPS Target Clearance $53 -also on Amazon