Dev Call May 11, 2020

Issues & Pull Requests




1 Like

Attendee count (23):

UTC1100 -

  • log download problems

  • Several bugs in log download

  • Peter is actively looking at it

UTC1108 -

  • Doesn’t look right to tridge
  • Need to do the assignment from the nullptr
  • Need more information

UTC1109 -

  • Obey always-use-ekf when determining whether attitudes are consistent
  • Copter will not check to see if DCM is consistent with the EKF
  • Not a huge number of logs
  • In Randy’s review one of the EKF lanes has always been correct
  • DCM is sometimes incorrect
  • We want to keep catching the EKF lanes not being consistent
  • Downside is that people who only have one EKF lane (one IMU) won’t have attitude checks at all
  • Two EKF lanes should be sufficient checks if EKFs are happy
  • But might want the DCM check on single IMU boards
  • DCM going wrong?
    • Another underlying problem
    • E.g. compass interference from motors
    • User flies around for a bit, comes back and DCM is off by 68 degrees
    • Whereas EKF is happy
  • Shouldn’t we do the roll and pitch checks?
  • If EKF lanes agree then don’t check DCM necessarily
  • This will be backported to 4.0 series
  • False positives are really not good
    • People will disable their arming checks leading ot decrease in safety
  • Do we have logs where their system seems to be generally OK?
    • Yes
  • EKF2 Yaw Inconsistent
  • EKF learning massive offsets in flight?
  • EKF innovations low
  • Could just ignore yaw
    • But if someone has a really bad compass or yaw…
  • EKF is less likely to diverge on yaw than DCM, but it is possible for DCM to be better than EKF
    • Really bad compasses anything can happen
      • DCM is simpler
  • New check in 4.0
  • If they’ve done a flight then….
    • If EKF has ever done 3D mag fusion
    • EKF does DCM stuff on ground
      • Only starts to do fancy stuff in the air
        • Can only diverge past that point
  • Simple fix would be to add extra check for 2 EKF lanes and not do DCM checks
  • Gyro bias differences?
    • DCM would show up problems in this case

UTC1118 -

  • Auto-generated AP_Scripting binaries
  • No MdB
  • Build bindings using waf
  • Automatically updated when bindings are changed
  • Rather more complicated than expected
    • Needs to get includes and what not
  • Need to be familiar with waf and Python to hack on this
  • [9:22 AM] (Channel) buzz_mobile: will look, but sounds good…
  • C-generator is still present
  • This just gets rid of the Makefile
  • -Werror didn’t pass on CI because of some warnings which came up
  • Would be nice to have the generator in Python
  • Results will no longer be checked in
  • Tiny difference in includes
  • Makefile has been deleted
  • README file will be updated
    • And Wiki
  • Makefile could be left in with a warning in it?

UTC1124 -

  • Should be tested under Valgrind
  • Can be merged after Valgrind is done and Randy has a number
  • [9:38 AM] (Channel) NathanGilbert: Is there a time at the end of the meeting where we can bring up something that doesn’t have the DevCallTopic tag?
  • [9:39 AM] (Channel) LuisVale: @NathanGilbert Yes and the end after the agenda topics

UTC1139 -

  • Can’t mix CAN rangefinder / normal rangefinder
  • Friend class fiddled frontend drivers and num_instances
  • Fighting rangefinders…
  • Added semaphore
  • Nasty and easy to reproduce
  • Tested with one CAN and one i2c rangefinder
  • Only happens if you are using a CAN rangefinder
  • Race condition….

UTC1141 -

  • Zigzag auto feature
    • Designed for spraying
  • Semi-autonomous mode
  • Removes requirement to push stick forward to move to next lane
  • More parameters!
  • Will advance forward parameter-defined number of metres
  • Completely autonomous after you set the A and B points
  • [9:48 AM] (Channel) LuisVale: I really do not understand why Zig Zag is not deprecated from the main code to be done as a script, now that scripting is available.

That was discussed the first time we spoke about zigzag and at the time Randy did say it was appropriate for scripting

  • We couldn’t consider having this as a script until after scripts are parameters
  • [9:51 AM] (Channel) PH: you could have them on knobs
  • [9:51 AM] To Weekly devcall: distance-to-advance could be on an RC channel
  • Note a widely used mode
    • Two companies in Japan using it
    • Slower parameter download?
  • Enable parameter?
    • No
    • Could be added if a group was used
    • Like flowhold?
    • Under zigzag parameter?
      • Will make it easier to move things when this is done as a script

UTC1154 -

  • Move to single axis filter?
  • Would be nice to move both Copter and Plane to single-axis
  • We won’t hold it up on single-axis
  • Will create an issue so we don’t forget it

UTC1156 -

  • Waiting on MdB still
  • MdB wants to see final version
  • Merged!
  • Example to be added to wiki
  • OOP in LUA scripts is a thing
  • Misc.txt?!
    • Added accidentally
  • Mission scripting!

UTC1159 -

  • Add support for dataflash logging
  • MdB hasn’t looked at this recently
  • Needs to be rebased and tested
  • Want to do whole parameter tables too
    • Need to know what the LUA syntax should be
    • Index into tables with strings and stuff
    • Table of tables
      • parameter subtrees?

UTC0003 -

  • Mavlink2 signing procedure
  • Already have a doc for mavproxy, should be linked
  • Need some screenshots from MissionPlanner
  • Henry will look at

UTC0005 - Plane and systems update

  • Randy and tridge have been working towards new 4.0.4 and 4.0.6 Plane/Copter
  • Lots and lots of new features
  • .f.port and Hott
  • New compass ordering stuff
  • [10:05 AM] (Channel) RM: PR’s included are listed in the “4.0.4-rc1” column:
  • HAL_ChibiOS has been resynced except for dsp
    • So no fft stuff
  • Vast amount of stuff came in
    • Boards!
      • mRo Nexus, x7 and x7-pro, Matek, ….
  • This is going to need some serious testing before the beta is announced
    • MASSIVE change
  • Why not 4.1?
    • Full rebase on master for that
    • No new attitude control / position control changes / ek2/ek3 changes / gsf / fft
  • Tridge is confident on the HAL ChibiOS changes
  • Board-alt-config stuff is coming across
    • So hwdef processing stuff
    • Cascading effects
  • Release notes still have to be done
  • Doesn’t pass autotest
  • Heap of stuff changed
    • E.g. compass stuff / ordering
    • Can’t build revo bootloader…
  • Autotest is going to need to be fixed on the stable branches
  • Stack-checking code has come across
  • Vast amounts of checks are going to need to be done
  • Fly with CAN setup etc etc
  • Compass calibration stuff, use rangefinders, ….
  • EK3_MAG_CAL parameter
  • Probably no new 4.0 release for Rover

UTC0015 -

  • Copter issues….

UTC0017 - GSoC update

  • PH
    • Flying a json-connected Copter using matlab
      • High innovations will be sorted
    • PR in next week with bare-bones example
    • RealFlight/Gazebo etc
      • This adds Matlab
    • Octave?
      • Might just work
      • Needs udp or tcp transport
    • SIM_JSON?
      • Examples of using it with Octave / Scipy would be great
      • Mathematica?!
    • [10:20 AM] (Channel) MK: Will work really well with SYSID on a real airframe to easily build a representation of a specific vehicle
  • Thien is blogging his plans
  • Rishabh
    • Improvements to obstacle avoidance
    • Working with Randy

UTC0022 - emergency stop for Rover

  • Nathan has independently added an AP_EmergencyStop library
  • Should he create a pull request for this?
  • There was a chat on the partner’s call
  • Why up to 10 estops?!
    • Now down to 8
    • Estop on GCS
    • One on the machine
  • high/low pins == not enough pins?
  • Servo9_function to be estop1
  • Servo10_function estop2
  • Then use for polarity
  • Read as GPIOs
  • Turn aux pins into estop
  • Safety-switch is already available on CAN
  • GCS failsafe can do a lot of things…
    • An option to estop?
  • Action?
    • Force safety switch on?
  • Have discarded the PWM high/low thing
    • Will use two servo functions, one active-high, the other active-low
  • Button stuff?
    • Not hooked into any of the logic
    • Notification to ground station
  • Good solution for CAN?
  • PR will be created by Nathan
  • Servo input functions will only be available on aux channels for the time being
  • Eliminate other parameters e.g. RSSI / fuel meter?
  • Button options?
  • Capture pins….
    • Fmuv5 standard has 10 or 12 PWM
      • But also 4 capture pins
        • Inputs that aren’t outputs
    • Extra GPIO parameters for these?
  • Attach RC options to buttons would be nice
    • Latching / toggling
  • Option-blah-gone-high method on RC_Channel
  • One pull-up, one pull-down for reliability in RC Channel?
  • Way too edgecasey?
    • Button library could handle the high/low channels thing
  • Button thing is first step

UTC0057 - close