Dev Call Apr 16, 2018 2300 UTC

Issues & Pull requests




MAVLink

CHibiOS

  • Progress
  • Call for testers

AUVSI Attendees

GSOC

Update

Plane

  • plane 3.8.5beta3

Copter

  • Copter-3.5.6 beta testing should go out this week to include the safety switch change
  • Copter-3.6 beta testing will start once the above is done

Rover

Attendee count (max): 23

UTC2301 - https://github.com/ArduPilot/ardupilot/pull/8135

  • Mark parameters as always save them
  • Fixes problem where we ensure RC channels have been set before taking off, but we don’t set values if they’re the same
  • Is this the correct way to do things?
    • Mission planner has been modified to always set
  • Change defaults to 0 to force values be modified?
    • Would break people’s setups if they have arming checks disabled
  • Weekly devcall: Another option is to just remove the check, given the servo/rc split
    • If transmitter min throttle was 1200 and you had 1100 then you’d be giving throttle
      • But other arming checks should catch it
    • Reversals wrong would cause issues
  • Too many parameters?
    • Things get nasty if we run out of space
    • PH1 and Cube are stored in 16kB RAMTRON device
      • Subset uses for parameters, most used for mission
      • Several kilobytes only
      • ~350 can be changed
  • Channel) MdB: Rob: It’s this check for min/max rc yaw/roll/pitch/throttle are set
  • [9:14 AM] (Channel) MdB: But if you had the same RC values as default the check never passes
  • [9:14 AM] (Channel) MdB: and its annoying
  • [9:14 AM] To Weekly devcall: I put this must-be-set check in before we had the rc input/servo split.
  • [9:14 AM] To Weekly devcall: (IIRC)
  • [9:14 AM] To Weekly devcall: It bites people because we avoid setting parameters if you’re trying to set them to their current value.
  • [9:15 AM] To Weekly devcall: (both in MP and AP itself).
  • [9:15 AM] (Channel) MdB: This also affects sub for the record…
  • [9:15 AM] To Weekly devcall: MP has been patched against it. We’re debating removing the checks entirely
  • Change default limits?
  • Another check to ensure the min/max are in correct orders
    • For servo outputs and inputs
  • (Channel) JacobWalser: we don’t have any rc calibration procedure
  • [9:18 AM] (Channel) MdB: I wish switches checked range instead of hard coded :frowning:
  • [9:18 AM] (Channel) MdB: but I didn’t want to check that now…
  • [9:18 AM] (Channel) JW: for the record I don’t think the calibration belongs on the autopilot at all in the age of digital radios…
  • [9:18 AM] (Channel) JW: It shouldn’t be the autopilot’s job to calibrate a transmitter
  • [9:18 AM] (Channel) MdB: Jacob: The check we are talking about affects sub, do you have any issue with removing the check?
  • [9:19 AM] (Channel) MdB: This check for the record: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Arming/AP_Arming.cpp#L607
  • Do we use the input range directly for the outputs?
    • Hangover from the past
  • NE: The reason to get rid of the arming check is so that users don’t disable all arming checks to get around the single issue
  • [9:22 AM] (Channel) JW: To answer the question: I do not mind getting rid of this check
  • RL: Confirmed, Interlock on Heli looks for 10 > Min
  • Could change things such that arming check instead waits for all channels to be within deadband of trim values except throttle
    • Even throttle on unsprung transmitters
  • NE: Add a warning that the input is beyond range. Being within range just gives you reduced input.
  • RC calibration is used on Copter to determine whether we output to the motors
    • Removing the check might let servos move after frame is selected
  • Split rc3-min and rc3-max entirely from servo3-min and servo3-max on Copter
    • Mot-pwm-min and mot-pwm-max
      • Can’t just change the defaults
  • Repacking parameters?
    • Doing stuff atomically makes this difficult
  • RL: Michael, what exactly is the root problem here? I missed it.
  • [9:34 AM] Muted.
  • [9:35 AM] (Channel) MdB: Rob: My transmitter by default has min 1100 max 1900 which meant the check failed even though I did calibration
  • [9:35 AM] Unmuted.
  • [9:35 AM] Muted.
  • [9:35 AM] (Channel) JW: if your rc calibration lands on the default values, they aren’t committed to non volatile memory and then are not flagged as saved, and you fail the ‘rc calibrated’ check
  • [9:35 AM] (Channel) LV: @Robert, the problem is that we got a plane guy going for a racing quad :slight_smile:
  • [9:35 AM] (Channel) MdB: Changing TX is ofc easy, but its not an obvious reason why it failed, and when I looked it up on the internet I just found piles of confused users
  • [9:35 AM] (Channel) MdB: So I decided it was a real problem and brought it up :smiley:
  • [9:35 AM] (Channel) JW: The bit about using RC3 seems like the confusing bit to me
  • We should be enforcing ESC calibration rather than this stuff!
  • Change things:
    • Arming check will be on mot-pwm-min and mot-pwm-max
    • Put Michael’s new flag on mot-pwm-min and mot-pwm-max
    • Most escs have 1000-2000
      • So we should use those as defaults
    • This way we’re checking the ESC range
    • We’ll have the correct arming failure!
  • So:
    • Mot-pwm-min-max will be copied from rc3minmax
    • If they’re in storage
    • One-off-check at startup rather than in polling
    • Remove checks for rc calibration
    • Don’t apply this PR at this time
    • Remove storage check retain the range check!
    • MdB: Jacob: Forget my force save patch, automatically set the MOT_PWM min/max to the RC3 values if RC3 had been set before, then remove the configuration bit of the rc_checks.
  • (Basically force all vehicles to have configured MOT_PWM_MIN/MOT_PWM_MAX period and not use the RC3 range)
  • New process required for calibrating escs to set mot-pwm-min and mot-pwm-max
  • DJI ESCs have fixed range
  • Calibration will need to write values
  • Quadplane has two lots of min/max
  • This is not absolutely urgent
    • But we’ll want to chase this as running out of parameter space will be dire
  • [9:49 AM] (Channel) MdB: relevant discuss issues of others hitting this same thing: [SOLVED] PreArm: RC Roll not configured Ac3.5 rc roll not configured
  • Using flash for parameters?
    • Force-upgrading bootloaders…
    • ST-link if it fails?
      • Not exactly user-friendly
    • Boot0 and ST-Link are not generally exposed on ArduPilot boards
    • Could use a two-stage bootloader process

UTC0000 - https://github.com/ArduPilot/ardupilot/pull/8135

  • Only read in bus threads
    • Means you need to delay for that to run
  • Need to check boot-in-less-than-half-second thing, then this can go in

UTC0003 - https://github.com/ArduPilot/ardupilot/pull/7720

  • MdB thinks this is probably safe
  • A better way would be to not send the GCS text
  • Without the statustexts we can sit there spinning allocating/deallocating
  • ROS users use the HIL GPS message
  • Merged!
  • MdB will look at doing better

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

  • Safety switch change
  • Change default behaviour
    • Safety button doesn’t do anything if you’re armed
    • Can change it back to old behaviour with parameter
  • Couple of safety incidents
    • Only affected planes so far
    • Theory is moisture has triggered switch
      • Theory is a rather long shot…
      • [10:11 AM] To Weekly devcall: We should try a literal soak test on one of those switches
  • Need a release to get this out there
    • RM: I’ll do a Copter-3.5.6 beta release today or tomorrow
  • Why on a sub?
    • Historical reasons
  • Tridge wants a copy of the tlog from expntly from 7985

UTC0015 - ChibiOS

  • Please start testing ChibiOS as a matter of course
    • We build these under autotest now
    • PixRacers, fmuv3 and fmuv4 etc
    • RandyMackay: i plan to make a video on how to upload chibiOS firmware when we start Copter-3.6 beta testing
    • [10:18 AM] (Channel) JW: How does one go about testing a chibios build?
    • [10:18 AM] (Channel) JW: how to build?
      * Use fmuv3 and fmuv4 rather than px4-v3 and px4-v4 configure targets
  • Sensors run at same rates
    UTC0021 - https://github.com/mavlink/mavlink/issues/888
  • Happy for Amilcar to do stuff
  • MdB is curious
  • Not sure where this will end up long-term
  • Amilcar has commit rights on mavlink/mavlink but not their pymavlink repo
  • Amilcar is hopeful that things will work
  • Already some intractable problems
    • E.g. not listening to the disable-signing-timestamp
    • E.g. java patches
  • Main outcomes MdB would like to see
    • No WIP patches into mavlink/mavlink
    • Things that are common need to be agreed upon and put into common
  • [10:28 AM] To Weekly devcall: thanks @Amilcar and @MdB

UTC0028 - AUVSI in Denver

  • Jaime and Tom will be manning
  • Need some on-screen content from somewhere
  • Booth design is finalised and off to print
  • Hex. mRobotics and Jeff
  • [10:30 AM] (Channel) Michael_duBreuil: Other people attending with booths: Rob and myself
  • Youtube partner’s video playlist would be a really good idea!
  • Jeff’s working on allowing us to use the AUVSI logo
  • Early-registration for next year will be done
  • Need to worry about interdrone next
    • Tables and chairs this time…
    • Jeff is short on time but can show up
    • There’s a Skype chat for this

UTC0034 - GSoC

  • Interviews are underway
  • Meet again after this meeting to do selections
    • We have n slots - do we have sufficient mentors?
      • Please contact Jaime
      • Will also bug people directly for specific projects anyway
    • Looking forward to good ROS integration improvements
      • Do we build and ArduPilot ROS bridge or continue using MAVROS?
        UTC0044 - Randy and Copter
  • Copter 3.5.6 beta coming for safety switch changes
    • Maybe tomorrow
    • Probably a regular week of testing
  • 3.6 beta testing after that
    • Request for other bits and pieces to go in
      • Including tradheli and attitude controller filtering
    • Will start 3.6 testing without those
    • Wants set-time PR for 3.6

UTC0046 - Randy and Rover

  • 3.3 beta coming soon
    • Again, set-time PR

UTC0047 - set-time PR

  • FF’s already had a look at it
  • Move to under BRD_
  • Putting PPS-pin into the RTC parameter space
  • (Channel) JacobWalser: I think a gcs application (ex residing on a companion computer) should have some reasonable level of certainty of the right time before sending the message
  • [10:56 AM] (Channel) Michael_duBreuil: But its unreliable
  • [10:56 AM] (Channel) Michael_duBreuil: (It’s only better over long periods)
  • Knock-off-board’s crystals can be very ,very bad
  • 100-200ppm is reliably a crap crystal number
    • Not being temperature-compensated can also cause drift
  • Good crystals?
    • Cost-gradient…
    • 10 or 20 ppm

UTC0100- tridge and Plane

  • Tridge is writing the release announcement for next 3.8 release
  • Tridge would like to do 3.9 off master soon
    • Dual release, px4 or ChibiOS

UTC0100 - EKF3 as a default setting?

  • Already the default for tailsitters
  • Ditching an EKF on the px4-v2 for space reasons?

UTC0103 - Lidar as primary height source problem

  • Only while landing (Plane)
  • We don’t support any other use
  • Range issue on most lidars traditionally
  • 70m to 100m very few lidars are reliable at that range
    • Lighting-condition-dependant
  • Copter does allow it

20180417 - ArduSub release out this week

  • Tridge requests testing on Sub for ChibiOS
  • MdB wants battery testing on Sub
    • Not part of it

What the problem with MAVROS ? We got 100% compatiblity …