Dev Call March 9, 2020

Development Team
2

Attendee count (max): 23

UTC1102 - pre-agenda

  • parameter reset bug likely found and fixed
  • Floating CS line during bootloader may be confusing RAMTRON to the point it is resetting
  • Timezone change - well done on turning up at the right time if you did!

UTC1103 - more parameter reset issues

  • One user could reproduce reliably, this was key to finding and fixing the issue
  • Tridge removed all ability to write to the FRAM and the FRAM was still reset
  • Bootloader doesn’t initialise the chip-select pin
    • A test bootloader which does pin CS high seems to fix the issue for the user
  • Anybody suffering from this problem should update their bootloader
    • More robustness fixes will probably be included
    • Bootloader updates are a bit of a pain
      • And there’s a chance the board will be bricked until DFU mode is entered
      • No easy way to get to DFU pin on Cube carrier boards
  • Tridge needs to split out just the updated bootloader patch and ask the user to test it
  • Firmware update would leave you in the bootloader for quite some time so would increase likelihood of parameter erase
  • User needs to back and forth a bit to ensure his setup can still reproduce when put in a bad state
  • NuttX bootloader didn’t initialise the CS pins either
  • Noise on SPI bus causing corruption?!
    • Complicated pattern of bits required?
    • Only first part of FRAM gets corrupted
    • Writes left enabled on reset?
      • Maybe disable after every write?
  • Maybe other sensors could get into a bad state based on noise on SPI bus?
  • Other pins pin high or low?
    • I2c should have hardware pullups already
    • Uart lines - less obvious and much less likely to generate correct bits to stuff things up
  • MP’s firmware upgrade procedure -> augment
    • Console printfs really confuses MissionPlanner’s mavlink parser
  • Hardware pullups on SPI?
    • Tridge doesn’t think there are any
    • PK says mRo boards don’t
    • Maybe something to do in the future

UTC1112 - https://github.com/ArduPilot/ardupilot/pull/13603

  • Randy flight tested it
  • Paul’s still poking at it
  • Tridge talked with Paul about it
    • Requested logging changes
    • Log_Write being used
      • And using radians
  • Commit history needs some help
  • Paul’s thinking he’ll port it back to EKF2 soonish
  • Not ready for merging ATM
  • Reminder: put compass back into correct orientation before flying code not incorporating these changes.

UTC1127 - https://github.com/ArduPilot/ardupilot/pull/12887

  • AP_Scripting add button binding

  • A few small changes to make

UTC1130 - https://github.com/ArduPilot/ardupilot/pull/13658

  • Profileds
  • Data and clock on same pin
  • Set servooutput to profiledclock
    • Specify data pin as you would normally
    • Finds clock pins in same group
  • Rcoutput banner still work?
    • Peter_Hall: RCOut: PWM:1-8 ProfiLED:9-12 NeoP:13-14
  • merged!

UTC1132 - https://github.com/ArduPilot/ardupilot/pull/13208

  • Add mission rewind
  • Do-set the rewind distance
  • https://github.com/ArduPilot/mavlink/pull/130
  • Mavlink changes merged
  • Will need to fix the git hash in master
  • Can be merged once the mavlink commit is corrected
  • Update_exit_position doesn’t check return of ahrs-get-position

UTC1140 - https://github.com/ArduPilot/ardupilot/pull/13762

  • Merged!

UTC1143 - https://github.com/ArduPilot/ardupilot/pull/13743

  • Merged
  • AP_HAL_Linux issues

UTC1145 - https://github.com/ArduPilot/ardupilot/pull/13737

  • Would want to get a comment from MO on this one
  • Our XML is terrible
  • The JSON one is pretty nice
  • Need MO’s comment on this one
  • How and why is this expected to be used?

UTC1148 - https://github.com/ArduPilot/ardupilot/pull/13729

  • Merged
  • If it has to be done again we should do it more generally

UTC1150 - https://github.com/ArduPilot/ardupilot/issues/13728

  • Peter to do a patch

UTC1154 - https://github.com/ArduPilot/ardupilot/pull/13727

  • Peter will be doing tests against QGC to find why the bit isn’t being set

UTC1154 - https://github.com/ArduPilot/ardupilot/pull/13718

  • Writing out first word could be hazardous
  • Not worth the risk for the convenience

UTC1159 - https://github.com/ArduPilot/ardupilot/pull/13661

  • Merged!

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

  • Holding off on structural changes for a few weeks until 4.0 is settled
  • Stabilising for 4.1
  • Make an issue? Project? Tag?
  • Have to be careful not to merge too much stuff if we’re not merging this one as it will conflict with everything
  • [11:06 AM] (Channel) RM: Here is the issue to capture delayed PRs: https://github.com/ArduPilot/ardupilot/issues/13773

UTC0001 - https://github.com/ArduPilot/ardupilot/pull/13742

  • RPM API to be scripting friendly
  • Adds vibration
  • Provides sample script for quadplane failsafe where you lose the forward engine
  • It will take a predefined set of actions
    • Including gliding home
    • Will trigger qland if too low or at home
    • Autonomous failsafe for quadplanes
  • ROMFS scripts are coming for this sort of thing
  • Robustness in scripting?
    • Exception handling for scripting in scripting?
    • Are they available?
      • Yes
      • Pcalls
      • Running out of memory and taking too much time
    • A lot of APIs return none which gets nul-punned push can cause exceptions if used in scripting
    • [11:05 AM] (Channel) db: I’ve had plenty of issues with large lua scripts running out of ram
    • [11:05 AM] (Channel) db: … it would be nice to have a lua call to tell me how much system ram is available.
  • Losing your failsafe scripts are bad
  • Put at top of script on-any-fault return a retry of some description
    • Opt-in
  • Return protected-of-update?
  • Do a robust-call-checking mode for lua
  • Can possibly do a command-line lint for lua scripts
    • Need to generate a file telling the linter what new functions are and what’s been removed

UTC0012 - https://github.com/ArduPilot/ardupilot/pull/13431

  • 4.0.5 released:
  • 4.0 would have a larger set of changes
  • Parameter reset issue will be included, of course
  • Some filtering parameters will be coming in on the PIDs

UTC0016 - https://github.com/ArduPilot/ardupilot/issues/12547

  • Tfminiplus glitches on i2c
    • No problem on serial
    • Asking for a distance causes it to glitch
      • 100Hz is bad
      • 33Hz stops glitching
    • Discussion on going
  • Dual compasses order changing
    • CAN comes up in different order
    • Would be fixed with Sid’s changes
    • Tridge has an order-by-node-number patch around somewhere
      • No, that was Swoop’s airspeed sorting
  • Compass-cal should fail because node ids do not match
  • Not recommended to use dual CAN compasses on Copter right now
  • Done from QGC is kakutef7 board is missing from manifest
  • JW: kakuteF7 and kakuteF7 AIO are the same firmware
    • Current sensor won’t work if you don’t have the AIO
    • Apj board id could be wrong?
      • Coming in as skyviper?
        • How?
  • QGC using board-id is correctly?
    • Tridge will talk with Don on the matter
  • Pass-through issues
    • Peter can reproduce but hasn’t chased it down yet
  • 13th channel on sbus popping up?
    • RFD900 ppm pass-through
    • Somewhere along the line the channels get shifted
    • “Fairly often”
      • Once every 30 minutes to an hour
  • [11:33 AM] To Weekly devcall: @Randy it’s not regular according to uptime or something?
  • [11:33 AM] (Channel) JW: I’ve seen this! We’ve decided the clock in the rfd900x is bad but maybe we came to the wrong conclusion.
    • They’ve grounded until they can try the S.BUS firmware
  • Not a txmod
    • Ppm out on radio to radio
  • Bug in rfd900x firmware for ppm?
    • Extra-wide pulse would shift channels
  • In the cold the channel values can drift?!
    • Seen 20 microseconds
    • Clocking on the little micro
      • So maybe two issues?
    • Ppm is unclean
  • [11:37 AM] (Channel) davidbuzz: rfd900’s have temperature compensation that recalculates periodically.
  • Need to make rfdesign aware of potential issue in ppm generation
  • [11:38 AM] (Channel) RM: AP issue: https://github.com/ArduPilot/ardupilot/issues/13709
  • Randy is on Seppo’s case now
  • Josh will attach another log to the issue
    • If this is truly a second case of the same issue a general warning may be called for as this is used on big heavy vehicles
  • Could be capture or generation
  • Buzz can chase up with rfdesign
  • Should support srxl as well as s.bus or ppm
  • More sanity checks in parser?
    • If we add some then we may stop talking to some receivers
    • We didn’t end up putting in the ignore-parity rc option
  • Quadcopter fly away
    • Vibration failsafe activated
      • Wasn’t the cause of the partial fly-away
    • Matek405 board
      • Vibes are high but not that high
    • Paul thought EKF did the right thing
    • Struggling with sensors?
    • Vertical GPS velocity and z accel?
    • Usually use dual IMU to do aliasing detection
    • Average z acceleration deviates a long way from gravity when he starts to get into trouble
      • High-freq vibes?
    • Vibration failsafe should consider a throttle limit based on baro altitude?
  • When climbing z-accel goes to average zero - that’s almost certainly aliasing or clipping
    • Most likely aliasing
  • Could this be board-specific in our code?
    • Tridge can’t think of anything special
  • Light boards can see this more
    • Regular pixhawk on this frame showed very little vibration
  • Consider tire weights on top of flight controller
    • Increases mass, changes resonant frequency of flight controller
    • Need it well below the sampling frequency
  • Need to get alternate firmware for the internal-error-400 issue

UTC0049 - No Rover updates

UTC0100 - Close

1 Like