Dev Call Apr 30, 2018 2300 UTC

Issues and PR Management

Add esc_telemetry*:


Fence on Pre-Arm

Update build logs script Tools-Update build_docs script

[Nuttx] Don’t bail to debug shell if no SD card present:

Add Sensor-Rate logging to BatchSampler:

Replace global static send_param_value_all with gcs(). method

Analog input pin logging and MAVLink transmission

PyMavlink- Java generator hard-codes sysid and compid

Set Time PR from Peter Barker:

Message with wheels’ cumulative distances added

Avoidance Msg

Program Update
Mavlink Management:

Partners Program:
XPonential - shared ArduPilot booth. Contact details whilst there?

Google Summer of Code Announcement

Motto announcement:

Technical Update:

  • Infrastructure and CI - add F4Light to autotest?
  • Companion Computing-Status and Release plan with features
  • Hardware - reference build (plane) question in DAPO
  • All Vehicles - ChibiOS update - Streamline/simplify method to help users test it
  • Copter - Release Candidate -Test Matrix ?
  • Plane - Release Candidate -Test Matrix ?
  • Rover/Boat - Release Candidate -Test Matrix ?
  • TradHeli - Release Candidate -Test Matrix ?
  • Sub - Feature Plan
  • Tracker - Status - Feature Plan
  • GCS status

With the invaluable cooperation of @peterbarker for the call notes

ArduPilot Dev Call 2018-05-01

Agenda: Dev Call Apr 30, 2018 2300 UTC

Attendee count (max): 16

UTC2300 - ESC telemetry

  • Shape of mavlink telemetry packets is under question
  • Debating whether we have one message covering 12 ESCs or one message per ESC
  • Tridge went the middle ground - three messages covering four each
    • Do we do lumps of four like this?
    • Someone has a 16-motor vehicle?
  • Hoping for MdB’s feedback on this (and there’s some on the PR)
    • Temperature ranges are problematic
      • ESC temps you only real care about overheating, so unsigned seems reasonable
      • HW usually has a valid temperature range, which means signed might be good
      • 127 maximum is too low
    • More resolution on current seems like a good idea
    • 650 amps per ESC is the current limit
      • [9:08 AM] (Channel) RM: tesla super charger provides 340amps…
    • NathanEick: I’ve hear of regenerative breaking – do we allow “negative amps”
    • One message per ESC - overhead too large?
  • Instance-field requires lots of GCS changes
  • [9:11 AM] To Weekly devcall: @tridge what happened to the concept of a “count” field and abusing mavlink2’s zero-trimming?
    • API for sending message gets very ugly
      • 92 arguments!
  • 9:12 AM] (Channel) buzz_phone: id like to see milliamps, if possible, as thats how everyone reads the capacity of their batteries. ie 2000mAh etc
  • [9:13 AM] (Channel) JW: people usually do not specify the instantaneous current draw of their vehicle in milliamps though
  • [9:13 AM] (Channel) buzz_phone: …depends if you are using a glider or not…
  • [9:13 AM] (Channel) NE: I respectfully disagree with miliamps because it’s a ton of extra zeros that I think are useless. Batteries are moving more toward Ah IMO. New batts are 2.0 Ah.
  • [9:14 AM] To Weekly devcall: buzz: tat would make it easier for people working at the mavlink level - but we should be improving things at the presentation layer…
  • [9:14 AM] (Channel) NE: I personally like native units for easy math, but that’s me. haha
  • UTC2314 - no-fly-zones
  • Very new issue
  • Reuse geofence code for no-fly-zone?
    • “Stay out” zone
    • Would mean choosing one or the other as it currently stands

UTC2317 -

  • fencing prearm
  • Randy will look at that

UTC2319 -

  • Fencing prearm
  • Will we get use out of them?
  • Jacob will get utility out of them
  • Tridge doesn’t like the burden it puts on developers for limited gain for few people
  • Used to run these on autotest
  • If we had an enthusiastic developer who wanted to go through everything and mark it up then we might auto-generate this stuff on autotest etc
    • But this is an ongoing thing

UTC2324 - NuttX and absent-FD

  • Only way under PX4 HAL to get a NuttX shell
  • ChibiOS always boots
  • Tridge is leaning towards having NuttX always boot
  • [9:25 AM] To Weekly devcall: @tridge if we care we could have a flag-file on the SD card!
  • [9:25 AM] To Weekly devcall: touch /media/pbarker/SDCARD/give-me-nuttx
  • Always open log files on boot?
    • Too many small log files
  • Jacob will progress this

UTC2330 - batch-sampling at sensor-rate logging

  • Ffts at much higher frequencies
    • Up to 4kHz on gyros
  • Merged!

UTC2336 - send-parameter-value-all PR

  • Merged

UTC2339 - analogue pin logging and mavlink transmission

  • AP_ADC
  • Tridge has code!
  • Tridge is concerned about how many mavlink packets we’re adding
  • Minimum 1Hz rate
  • A parameter with a number of bits indicating whether to stream a message
  • Weekly devcall: SR0_MSG_MASK
  • [9:46 AM] (Channel) NE: Those are super unclear btw
  • [9:46 AM] (Channel) NE: SR0, SR1, SR2 documentation is VERY lacking
  • [9:46 AM] To Weekly devcall: streams need to die :slight_smile:
  • [9:48 AM] (Channel) NE: Low-latency AHRS telemetry would be GREAT.
  • [9:48 AM] Unmuted.
  • [9:48 AM] To Weekly devcall: @Nathan yep
  • [9:48 AM] To Weekly devcall: millisecond resolution :wink:
  • Support for built-in OSDs is coming
  • Default streamrates have to take into account write-only devices like OSDs

UTC2351 - set-time PR


  • System time - not ready to merge

  • Time stuff is hard

  • Patch may be seeing scope creep

    • Simple patch - don’t account for crystal being off
    • First time source wins
    • This is what original patch did
  • Now we are slewing time on autopilot to match gcs time coming in

    • This is significant, one second in 10000
    • Necessary for ros non-gps positioning
  • We are tiering time sources coming in

  • Gps beats rtc beats gcs, this is not sufficient

  • We need master clock

  • Multi-gps situation is covered

  • Are we coordinating with mavros maintainers?

    • One has commented on pr so they are aware
  • Similar timesync work going in px4 right now intended to go into mavros. Coordinate?

  • This patch is not mavros specific, it just allows synchronizing to an external time source

  • We may need to support a different message or something to support whatever api they come up with

  • No problem to just feed that in

  • Randy: this part needs to go in it’s ardupilot work and we need it

UTC 0004 -

  • 16 seems a little overkill
  • Wheel distance is a strange name
  • Randy will look at it

UTC0007 - avoidance message and mavlink

UTC0020 - AUVSI update?

  • OB will be there tomorrow or the day after
  • Nobody on call to give us an update

UTC0021 - GSoC announcements

  • Good engagement from several students!
  • A few students do need to step forward and engage
  • Some students were on call, now they have left
  • [10:23 AM] (Channel) pp: Congratulations, GSoC 2018 Ardupilot Students!
  • Some requests for hardware are coming in
    • Funding committee wants to see proposals! Now!
    • ~$800 - includes a TX2
    • [10:25 AM] (Channel) : does he need a tx2??
      • RPi?
      • Is it worth it?
      • Everybody uses TX1/TX2 in the video world
      • [10:29 AM] (Channel): unless he is doing some computer vision work or crazy number of cameras I don’t think he needs it. What he does on a rpi should apply to tx2 others have the hardware to verify. v4l2 and gstreamer do not care
      • Point of contention on whether tx2 is necessary
      • Equal to all?
      • Pool of hardware?
        • Get hardware back at end?
      • Funding committee will look at this
  • Randy will get him the hardware and then fight with funding committee

UTC0034 - motto announcement

  • Versatile, Trusted, Open
  • Good thing from marketing committee!
  • Elections coming for revitalised marketing committee

UTC0035 - F4Light

  • Do we CI it?
    • Probably not
  • Do we autotest it?
    • Probably
  • Build a tag?
    • Tag would have to be in the repository
      • And the relevant commit as a branch
    • Night-ghost works outside master
      • No open PRs ATM
  • Would be nice to get F4Light working with waf!
  • Tridge wants a warning-level thing in CI rather than simple errors
  • Resolution: leave things as they are

UTC0042 - companion

  • New simple companion/APSync release soon
    • Wifi client support can connect to wifi network - only real new feature
    • Tested on raspberry pi
    • Cross platform support is problematic tx2 has wierd funk
    • Will have tx2 and tx1 image
    • Will add support for pi 3B+
    • Workaround to upgrade existing image
  • Possibly start to support banana pi - reasonably big community
  • Maverick

UTC0049 - reference build for Plane

  • Nobody knows anything about this on the call

UTC0049 - ChibiOS update

  • Thanks to Randy for putting pages up!
  • USB IDs issue
    • 3DR PixHawk ID wasn’t great
    • Windows7/Windows8 require special drivers to change
    • Bootloader stays the same ATM
    • ST-micro’s vendor ID
    • String IDs have serial in them
      • And the serial number for the device
      • Different COM port for each device you plug in
      • COM port 35, 36
        • Luis: 58
    • Hex have their own vendor ID
      • Do we present a different vendor ID based on the board you’re running on?
      • Base it on a vendor ID in the bootloader?
    • Use apjtool to set the vendor and product ID
    • Windows 10 is good with cdcacm devices
      • 7 and 8 not-so-much with separate driver requirements
    • Unique IDs per board
      • Tridge likes it!
      • Some older programs might crash
  • TODO item is to set IDs in strings from apjtool
  • Pre-windows-10 users
    • Will need st-com-port-driver
    • MP should install this for Windows 7/Windows 8
  • Board ID in manifest.json?
  • String board ID instead of a board number

UTC0107 - px4v2 overflowing again

  • Or it was yesterday…
  • Rerunning things makes things work…
    • [11:07 AM] (Channel) JW: that doesn’t sound good
    • [11:07 AM] (Channel) JW: about the ci randomly failing
    • [11:08 AM] To Weekly devcall: Might be that “multibuild” thing that’s going on

UTC0109 - AUVSI!

  • Michael, Tom, Jaime and Jeff called in
  • Battery failsafe stuff!
    • Need to ping GCS maintainers to get support in!
    • Randy will work with Michael on it
    • Battery parameter pages are broken

UTC0110 - Copter and Rover update

UTC0121 - return control to user sooner on SmartRTL

  • Very late return of control
  • Reduce accuracy instead of aborting SmartRTL when out of control?
  • Invalid mission problems

UTC0123 - v53l0x

  • Tridge did initial driver
  • Some issues?
  • Tridge is happy for people to chase these issues
  • Stupidly complicated interface to hardware
    • And out-and-out errors in the sample driver
  • Want PRs!

UTC0126 - omnibus in release?

  • Cherry-pick-in the hwdef.dat
  • No risk to anything else
    • Assuming there’s no extra sensor drivers etc

UTC0127 - log files and dates ChibiOS

  • Related to the RTC stuff Peter is looking at
  • Tridge and Peter will look at it

UTC0128 - colours on ChibiOS

  • Need to check the three pin definitions
    • Mucked up early in the port process, but tridge thought he’d gotten this right

UTC0128 - position-hold for Rover coming soon

UTC0130 - Plane update

  • Flew master on quadplane on Sunday
    • Flew well
  • Beta process will now start

UTC0131 - Sub Update

  • Beta tagged today
  • Current limiting
  • Usability improvements

UTC0132 - tracker maintainer

  • Nobody has stepped up

UTC0133 -

UTC0135 -

  • Tridge and Jacob will look at

UTC0138 - Philip and HW

  • Cube Orange
    • Details to be released later
  • Cube Pink being sent to Luis

UTC0138 - end

A big thanks to all that attended the call. Hope to see you all next week.


@jaxxzer helped out a lot this week - thanks!

1 Like