Dev Call July 9, 2018 2300 UTC

Development Team
2

Attendee count (max): 24

UTC2300 - visca protocol

  • Tridge hasn’t looked at it
  • FF may have looked
  • MdB hasn’t looked at the details
  • Serial-connected camera
  • RC control for zoom
  • AP can control zoom
  • Protocol can do pan/tilt/zoom/exposure
  • Camera protocol stuff in mavlink is a bit crufty
  • Author is still working on it
    • Has said he wants to work on a few more things
      • In the next few days
  • Should we review what’s there?
  • Is this in the correct place in the code?
    • Should it be a backend for ap_camera
    • Or is this a mount thing?
  • Little niggles like taking up flash space when not necessary
  • Taking up a top-level k_param
  • [9:08 AM] (Channel) MdB: I’d like to see mount and camera fold together at some point…
  • [9:08 AM] (Channel) LV: yes - this is very usual on pro level cameras
    • Craig agrees
  • Pass mount commands to both camera and mount
  • No frontend/backend in camera at the moment
    • Just for triggering
    • [9:09 AM] (Channel) MdB: Camera is nasty
    • [9:09 AM] (Channel) MdB: Someone should rewrite it :smiley:
    • Backend for AP_Mount would be much easier
    • [9:10 AM] (Channel) MdB: I’m fine with moving camera stuff into mount long term
    • [9:10 AM] (Channel) MdB: Does not bother me!
    • Where does he hang parameters?
    • CAM_VSC_* parameters?
      • Like we did for battery
    • Probably wouldn’t need the control channel
  • Should definitely go into mount so it is generally available to all vehicles
  • Integrate with existing mount parameters
    • Backend-specific parameters are now a thing
      • E.g. battery
  • [9:13 AM] To Weekly devcall: Can we retrofit it?
  • [9:13 AM] To Weekly devcall: (the pattern i.e.e)
  • [9:13 AM] (Channel) MdB: https://github.com/ArduPilot/ardupilot/pull/8816 <- rngfnd retrofit
    • Doesn’t have conversion code
    • Should work otherwise
    • Rangefinder_params.cpp
    • Made it more like attery so you can have 9 top-level rangefinders
      • MdB will be looking at this one

UTC2314 - https://github.com/ArduPilot/ardupilot/pull/8685

  • Random camera cleanups
  • Adds reboot-required on some parameters
  • Removed code run at 1kHz that should only be run at startup
  • Removed some initialisation stuff
  • Removed some confusing methods
  • Should remove analog-pin-to-digital-pin method entirely
    • Archaic
      • Labelling error from Arduino days
    • Doesn’t exist on hal-chibios
  • Camera can be a bit of a hole for getting nasty PRs
    • This was supposed to be a small one
  • Two feedback events on the very first trigger
    • Still to be fixed
  • Once CI passes we should merge this
  • Camera feedback still to be done for ChibiOS
  • Removing analaog-pin-to-digital-pin might make Linux camera feedback work
    • [9:20 AM] (Channel) MdB: I really like deleting code from HAL :stuck_out_tongue:
  • [9:21 AM] (Channel) MdB: And you only get it on the first camera event. It messes up my tagging stats all the time :smiley:
    *

UTC2319 - https://github.com/ArduPilot/ardupilot/pull/8789

  • Pending discussion with Don
  • Protocol is fragile

UTC2321 - https://github.com/ArduPilot/ardupilot/pull/8766

  • One more pass between tridge, Peter and Tom before it goes in
    • Currently worse off if we don’t progress
      • Tom anticipates doing it
  • Only significant work in Plane is the landing gear PR
  • [9:22 AM] (Channel) MdB: throttle_allows_nudging should move IMO…
  • [9:23 AM] To Weekly devcall: @@MdB probably - but does it NEED to be done as part of the original PR? :slight_smile:
  • [9:23 AM] (Channel) RM: yup
  • [9:23 AM] (Channel) MdB: I agree with that, I just wanted to know where it was going
  • Overhead on virtual method calls is heavy
    • We’re close on flash space
  • We could claim back a chunk of space if we move stuff into AP_ROMFS
    • [9:25 AM] To Weekly devcall: I suggest just letting v2 die rather than working on that, tridge
  • RM: we shouldn’t put this off
  • [9:25 AM] (Channel) MdB: I’d like to carefully review it at somepoint. (bit scared of unintentonal changes)
  • Maybe after 3.9.0
    • 3.9.1 etc will be a bugfixes-only branch
  • 4.0 should be discussed - what can we break?
    • Drop HAL_PX4!

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

  • Assigned to Randy last week

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

  • JC is happy with the suggested approach
  • Logfiles would be clear
  • Need a volunteer to implement it
    • Proposed solution to be detailed on the PR
    • Expected-id
  • Should we ask JC to do it?
    • Not great for to volunteer people when they’re not on the call
    • He liked the proposed solution but not a “let me jump on that straight away” way
  • Should be a relatively simple change

UTC2332 - GSoC update

  • Arnav’s
    • having issues with underlying software up and down the pipeline
    • Has an interface in APWeb for the camera configuraiton
  • Ayush is making good progress
  • Sephir a little behind on the software-stack-side of things
    • Needs to update blog post this week

UTC2335 - thread_create API

  • Will hopefully mean less things on IO thread
  • Should work on all the HALs
  • Don’t create too many threads
    • Stack space
  • Takes a relative priorority
    • E.g. one-more-than-IO
    • To cope with different priority systems on different HALs
  • Stack space
    • Differs based on HAL
    • Some HALs can show stack space
    • ChibiOS has a compile-time option
    • Will usually crash if you run out of stack
    • HAL-ChibiOS has helper function to show amount of stack
      • Canary-bytes
      • Fills with known bytes
      • High-water-mark
      • When you ask for a stack of 512 you get an extra 128 for interrupts
      • Scripting would like to know stack usage
        • Stack pointer minus stack base
      • Maybe free-stack instead?
    • We’re way too generous with our stack allocations
      • Because consequences are dire
    • Maybe a log message for stack usage?
    • Amount of stack space, thread number, max used

UTC2340 - compressed ROMFS

  • We now have gzip compression for ROMFS
  • io firmware, fonts that sort of thing
  • very easy to add things to romfs
  • saved a bunch of sapce
  • a few K of code
  • already saved space
  • selectable fonts at runtime in OSD
  • use the compression elsewhere?
  • terrain data?
  • logs
  • compress into dataflash?
  • 20kB to get live compression
  • on fmuv5 maybe
  • 40% drop when compressing logfiles
  • Get entire terrain database onto SD?
    • A chunk of work
  • Dron.ee use lz4
    • Good on ghz class
  • Tinf because it’s low-overhead
    • Not fast

UTC2350 - build for the Cube Black

  • Same as fmuv3 but different IDs for Hex
  • Community will need to know which one to use
  • MP will need to handle it
  • Tridge is planning on doing a ph4-mini and maybe cuav5 and pixhawk 4
  • PixHawk1 build?
    • Fmuv3 isn’t evocative
    • Low-cost
    • Fmuv2?
      • Fmuv3 until it doesn’t fit?
  • Remove fmuv3 build?
  • pixhawk1-2M
    • Or pixhawk1-1M
  • Pixhawk1 and pixhawk1-2M
  • Error message they get needs to guide them in the right direction
  • Having features blink in and out is a problem
  • Just buy another one?!
    • [9:57 AM] (Channel) MdB: Ha, people are using APM2.x
  • Ensure only new features don’t make it in
  • Fail if USB is plugged in on a 1MB board instead?
  • At some stage we will need to stop supporting the 1MB boards
    • Like the old AVR boards
    • Version number never goes up
  • It will happen with F7 at some stage anyway
  • 1MB F405 boards on ChibiOS too
    • No iomcu so a chunk of space available there
    • Uploading IO firmware from GCS would also save a chunk of flash space
      • Flash IO firmware from GCS
  • Releases based on board name rather than architecture name
  • Defaulting flow control to off for some boards
  • Should all be faster
  • PixRacer build?
  • Canonical board name
    • E.g. hkpilot32 would use the PixHawk firmware
  • Cuav5 and PixHawk4 have differences between them
  • Different boards have different sensor sets
  • mRo 2.1?
    • Ask them what they want
  • Hard to come up with naming rules
  • Any stable releases?

UTC0007 - Plane beta2 is out

  • Lots of enhancements have gone into 3.9
  • Thanks to all contributors!
    • Nate for flight-testing
  • Final due out in next few days

UTC0010 - Randy Rover

  • Lane-based-speed-control beta still needs more testing
  • Want to rework navigation controller
    • Leonard!
    • Want them tight
    • Wp-overshoot parameter should be obeyed
  • Attitude controller rewritten
  • Drone-follow for Rover
  • Decent telemetry connection between Rovers
  • Use tridge’s esp8266 firmware!
    • Need a reset-to-defaults capability
      • It does come up in AP mode if it can’t do client mode

UTC0011 - Copter and Randy

  • Safety-switch stuff needed to go in
    • Delaying 3.6 testing
    • 3.5.6rc1 needs testing for safety-switch stuff
      • Another day or so
    • Tridge prepared release
  • Hw safety switch was not supposed to be guaranteed in-flight
  • Future hw switches will safe to trust in flight
  • 3.6 testing is going reasonably well
    • Randy’s found more time to put into support
    • Telemetry bugs
    • Relay bugs
    • Throttle-failsafe bug
  • Outstanding issues
    • Fnoop has found problems with the Wing board
    • Copter-3.6.0-rc3/-rc4 is available for beta testing
    • RC inputs consumed after failsafe triggered?
      • Not a debouncing thing
    • Once throttle channel goes low it should not be processing other channels
    • Race condition where the channels don’t go into and out of failsafe
    • Need to make sure behaviour hasn’t changed since 3.5
    • Spectrum can be split across multiple frames
    • Frsky on sbus signalling to PixHawk
    • Rob: When exiting failsafe we get a dirty exit
      • As many as 6 frames
      • Rob will get a log to tridge
      • Frsky+xbus on x6 or x8 there is no option for no-pulses and nothing for throttle-change-only
        • Only all-channels-go-low
        • Tridge uses x6/x8 and he can do no-pulses with S.Bus
        • Check opentx on transmitter
        • Figment of logging?
        • Receiver firmware version
    • Simple mode not working?
    • Rc5 in 48 hours with fixes

UTC0033 - volunteers for SPI liaison required

  • FF’s one-year-tenure is over
  • Email will go to mailing list
  • Craig is interested in doing it

UTC0034 - Hamish

  • New contract with diux
    • Common autopilot work / documentation
      • Mavlink stuff mostly

UTC0036 - 5 believer aircraft for dev team

  • Proposal for contribution of the month
  • Enough devs have put their hands up
  • 5 aircraft, 6 places to send them
    • How to resolve
    • MdB: skip contribution of the month
    • Jaime: skip it
    • Nate: already have many of them, don’t really need one
    • RM: let funding committee decide
    • Reference frame for each vehicle type
    • Can’t fly this one just anywhere
      • It’s large
      • $200 OR the airframe?
    • Manufacturer wasn’t fussed either way
  • Having partners contribute goodies is great