Dev Call Nov 25 2019 2300 UTC

Development Team
1

Issues & Pull Requests

  • Compass Scaling issue
  • I2C issue

Plane

Copter

Rover

1 Like
2

Attendee count (max): 24

Pre-Agenda:

  • Discussions on discourse consistency

UTC1105 - Compass ordering

  • Sid’s done some significant work which we have to discuss later….

UTC1107 - Welcome to Henry and Matt to the devteam

  • Vote was held over the last week

UTC1108 - https://github.com/ArduPilot/ardupilot/pull/12886

  • Bad fix for whatever problem
  • But master is currently broken

[10:10 AM] (Channel) JW: i just tuned in and looked yes

[10:10 AM] (Channel) JW: i’ve been OOO the past two weeks

  • [10:12 AM] (Channel) JW: tomorrow
  • Jacob and co will look at this so we don’t need to merge it

UTC1113 - https://github.com/ArduPilot/ardupilot/pull/12882

  • MERGED!
  • Simulated safety switch

UTC1114 - https://github.com/ArduPilot/ardupilot/pull/12881

  • Dead code removal
  • merged

UTC1115 - https://github.com/ArduPilot/ardupilot/pull/12880

  • Merged!
  • Another enum-class change, this time in servo library

UTC1116 - https://github.com/ArduPilot/ardupilot/pull/12879

  • Move the pragma thing into the .cpp
  • Should be flight-tested
  • Tridge would like to review before merge
  • We should testing DCM fallback in autotest
    • Behavioural?
    • Lower gate value parameters
    • Really long GPS delay
    • Fusing GPS flag
  • MdB: We have talked about how EKF_STATUS_REPORT needs an extension to say what lane it is actually using, and similiarly saying “LANE_DCM” would be valid I think…

UTC1123 - https://github.com/ArduPilot/ardupilot/pull/12877

  • When we have a critical failure MissionPlanner doesn’t say anything
    • Tridge opened a mission planner issue for the SYS_STATUS bits
  • This will have MissionPlanner show something
    • Thus we are getting bug reports back from core dev team members only
  • [10:35 AM] To Weekly devcall: We should be making internal errors as scary as possible IMO.
  • [10:35 AM] (Channel) db: status text “your copter is behaving so badly we, the developers would like to see the log”
  • [10:36 AM] To Weekly devcall: @db that sounds good, actually.
  • Use name of enumeration and put in a 30s interval message with its name
  • MissionPlanner’s statustext limit is a significant problem
  • Peter to redo as a more elaborate patch using the maximum of the vehicle’s status and the base class status
  • Randy can help testing in Mission Planner

UTC1136 - https://github.com/ArduPilot/ardupilot/pull/12869

  • Behaviour change for existing frame types 0 and 1
    • Won’t impact any users, probably
  • Need to ensure continuous function across angle changes
    • Rate change so shouldn’t be too bad
  • Don’t want an oscillation
  • Needs a comment on using roll for pitch and vice-versa
  • Makes things consistent with Copter documentation
    • Leaves behind a couple of special cases, ‘though
      • The two classes are still useful
        • No yaw torque + class would be what you’d choose to fly a plus frame tailsitter with
      • This will give you two options for the same phrase
  • Parameter conversion?
  • Tridge: change in behaviour is probably OK in this case so long as we put it in the release notes
  • Henry will put a section in the wiki for “Plane > 4.0” for this feature behaviour change
  • Mark will eliminate the discontinuity in rate limit
  • Mark to eliminate logging code to be killed or cleaned up significantly
  • Debug code was originally in for dynamic gain scaling
    • Rather unreliable as it turns out
    • Pierre L’s logs showed that it wasn’t really required anyway

UTC0002 - https://github.com/ArduPilot/ardupilot/pull/12864

  • https://github.com/ArduPilot/ardupilot/issues/12838
  • Compass cleanup and bugfixes
  • Vehicles having heading problems
    • EKF being annoyed rather than fly-aways
  • Calibration not getting diagonals/off-diagonals filled in
    • Red-herring
      • Probably working OK as the sphere fit is better than the ellipsoid
  • Merged
  • Hanging brace thing
    • Tridge likes having a consistent style
      • And brace on next line
    • https://github.com/ArduPilot/ardupilot/pull/12864/files#diff-3e07895a0da57267a05c962290715e46L352
    • For library maintainers we’ve traditionally allowed latitude
    • Scripting and gps and ekf all have slightly different styles
    • [11:06 AM] (Channel) db: my personal opinion is “dont care”, or alternatively, “if editing an existing file, use the same layout as the file/s you are in”
    • [11:06 AM] (Channel) MdB: buzz thats what I’ve stuck with
    • [11:06 AM] (Channel) MdB: And I’m actually okay with that
    • [11:07 AM] To Weekly devcall: @davidbuzz thus bringing this up. Several style changes were made (for the good), but the hanging-brace thing is contentious.
    • [11:07 AM] (Channel) HW: astyle --options=Tools/CodeStyle/astylerc
    • [11:07 AM] (Channel) MdB: But I periodically get larger change sets of “covert style in scripting” for example which I’ve historically just closed as noise
    • Randy likes bracket on next line
    • In general bracket on next line
      • If maintainers want to use a different style, that’s OK
    • Tridge doesn’t want a commit hook enforcing style changes
  • Merged!
  • Real underlying issue:
    • World magnetic model tables
    • EKF got greater resilience to lots of things
    • Made us dependant on actually getting milligauss from the sensor
      • Turns out one very popular sensor is off by 16.7%
        • Vendor is actively working on the problem
          • Backwards compatibility is a real problem as the calibrated offsets are all wrong
            • Make compass calibration process look at GPS lock
              • Rescale the compass calibration output
              • COMPASS_FLAGS parameter
                • Bits indicating scaling-checked (had GPS lock)
                • EKF wouldn’t do earth field unless compass library indicated offsets were corrected during calibration
                • If people upgraded to new firmware the WMM stuff would be disabled
                • Would be re-enabled if another cal was done
    • Prearms can’t really be used to catch the bad scaling because on-ground errors are > 17%
    • 17% is within Earth magnetic field’s variation
    • In-flight check would be way too much yelling
  • WMM significantly improved our compass handling
    • Yaw alignment was done with a single sample from compass
      • Used that as field intensity
        • If it was a good sample - great
          • Motor running hard? Bad earth field!
            • EKF could uncoverge
    • https://github.com/ArduPilot/ardupilot/pull/11456
      • Introduced a massive offset
      • Before == fly-away
      • After == happy flight
      • In-flight testing was done using different code on different cores
        • Log is actually same flight
    • This was very good for bad vehicles
    • Bad for good vehicles
      • As they are now dependant on compass scaling being correct
      • The can set the EKF_LIM to zero to use the old single-sample code
  • Should we whitelist compasses with correct scaling
    • Problematic given emulated compasses
  • Should we disallow compass cal without GPS lock
    • [11:28 AM] (Channel) MdB: I can’t let users end up with different results depending on lock, I need to be able to constrain the path. Could be a param to require it though
    • Only uses tables if you have GPS lock while flying
    • [11:28 AM] (Channel) MdB: We can even report MAG_CAL_FAILED_NO_POSITION if we add it as a check for the calibration
    • If radius comes out too far from WMM then you can complain to the user
    • Additional fitness on the radius
    • [11:29 AM] (Channel) MdB: Randy: I’d take the hard requirement of GPS if it makes it better
    • [11:29 AM] (Channel) MdB: I need to know users are going down the one path
    • [11:29 AM] (Channel) MdB: So if we are going to change behaviour based on how calibration went then I want to be able to force how they did the cal
    • Sid: get input from user about location
      • E.g. GCS could set-home?
    • Check all compasses have some radius?
      • Does it naturally vary?
    • We should log the radius during the calibration
  • Just use direction of vector rather than length?
    • Tilt-corrected yaw sensor compass algorithm
    • Normally uses as 3D sensor
  • Concept:
    • Use intensity from single sample, inclination/declination from tables
  • Try to get EKF to not care about intensity?
    • Polar coordinates rather than xyz in EKF
      • Rather large change
        • Realistic?
          • Not really, complete reformulation
    • Change constraints and have max-radius error
  • Log analysis first step:
    • Compare compasses against earth-magnetic-model expectations
  • Should include radius in both compass calibration messages
  • Correct intensity as part of calibration…
    • Ensure radius is correct for that part of the planet
  • Calibrating inside == bad
    • [11:41 AM] (Channel) RL: I do that all the time
    • [11:41 AM] (Channel) DB: I do compass-cal indoors and without a gps all the time.
    • [11:41 AM] (Channel) DB: … and I usually do it with a usb cable.
    • [11:42 AM] (Channel) MdB: dont do compass cal indoors, thats a genuine problem
    • [11:42 AM] (Channel) OB: lol me too! (sometimes)
    • [11:42 AM] To PB: Why argue when we can measure?
    • [11:43 AM] (Channel) MdB: yes it is. It can blow up very very badly. Depends what is around in your house
    • [11:43 AM] To PB: I have ths huge steel ibeam running underneath my office. Do you? :slight_smile:
    • Randy’s never had issues calibrating indoors
    • [11:44 AM] (Channel) OB: One wooden roof, no pb
    • [11:45 AM] (Channel) OB: (no second floor)
    • [11:45 AM] (Channel) MdB: cars near by outdoors :stuck_out_tongue:
    • [11:45 AM] (Channel) MdB: The best one I’ve seen was someone with a nametag held on with a magnet :stuck_out_tongue: they rolled the vehicle by it and the calibration was uh intresting :smiley:

[11:25 AM] (Channel) Gus7119: Tridge sorry almost out of battery so will be gone soon. The Marketing and individual diagrams are all with graphic artist

UTC0040 - https://github.com/ArduPilot/ardupilot/pull/12863

  • Point in a direction, say calibrate, done
    • Awesome for really large vehicles
  • No diagonals or off-diagonals
    • Sid is worried about corner-cases, particularly on small drones and moving in 3D
      • Motor interference would swamp this effect
  • Diagonals are maybe 5%
  • 5% of 250 milligauss is ~12
    • EKF doesn’t care about this
  • If the diagonal is 1.2
    • Then you’re at .6 or .7 innovations
      • And the EKF might start rejecting
  • Vast majority of our user base won’t care about diagonals
  • Concept
    • Do the simple cal
    • Then rotate vehicle watching bars in MissionPlanner
      • Scaled innovations
    • Above .2 would be bad
  • Will go badly wrong if you point vehicle in different direction to the direction you tell it it is pointing in
  • Randy will test this

UTC0055 - https://github.com/ArduPilot/ardupilot/pull/12859

  • Toshibacan log and consume motor temperature
  • Merged

UTC0056 - https://github.com/ArduPilot/ardupilot/pull/12855

  • Generate random vehicle size
  • Point objects velocity to zero
  • Won’t ever fly out of range
  • So they’ll accumulate
  • merged

UTC0057 - https://github.com/ArduPilot/ardupilot/pull/12799

  • Clean up init failure handling in ekf2
  • Randy deliberately failed the allocation and it worked appropriately
  • merged!

UTC0058 - https://github.com/ArduPilot/ardupilot/pull/12756

  • Plane tiltrotors allow vectored motor tilt when disarmed
  • More contentious is the 2s arming delay patch
    • Force internal ramp time instead?
  • Mark will remove the arming delay stuff
  • Mark will add a Q_OPTION to control this behaviour

UTC0105 - https://github.com/ArduPilot/ardupilot/pull/12643

  • Do this next week

UTC0107 - https://github.com/ArduPilot/ardupilot/pull/12576

  • Sanity check was added for send-to-components
  • Merged

UTC0110 - https://github.com/ArduPilot/ardupilot/pull/12158

  • LTM support
  • Should we make all semaphores recursive?
    • How many non-recursive semaphores?
    • There’s a flag to make semaphores recursive in ChibiOS now
  • merged!

UTC0114 - welcome to Henry (again) to devteam

  • Now he’s undeafened on the call

UTC0114 - tridge chasing i2c issue

  • Watchdog reset
  • Cross-couple GPS send line with i2c SDA line
    • Not a recommended setup

UTC0115 - RC4 for Rover is out there

  • Not a lot of feedback
  • Would like some more

UTC0115 - closed

1 Like