Dev Call Aug 17 2020

Issues & Pull Requests





1 Like

Attendee count (max): 19

UTC1100 - Welcome new people!

  • Ryan (Rhino) and James O (Joshanne)
  • Both ArduPilot devs and interested in seeing what happens at these calls!

UTC1101 -

  • Able to access REPL over a serial link
  • Type LUA code in and have it executed directly
  • No MdB
  • Very response as opposed to over-mavlink
  • Need a MAVProxy thing for REPL-over-mavlink
  • Need to get MdB’s approval
  • Can be merged after MdB says it is OK

UTC1104 -

  • Perhaps we do this properly and get told how many extensions are actually present?
  • Given pointer to mavlink_message_t and an offset into the structure, indicate whether this value as filled in
  • Does mavlink_message_t already have the wire length?
    • Decoded structure doesn’t have that information
    • Add booleans into structure?
  • Least intrusive is probably a boolean function takin the mavlink_message_t

UTC1117 -

  • Can be merged after the indenting fail is fixed
  • Move the cast into where the default define is used

UTC1120 -

  • Generally PRs need more description in them
  • Use fail radius + twice the loiter radius?
  • More work required

UTC1135 -

  • we ‘d lose all warning to the user that mode change had failed
  • Should make sure other mode change efforts similarly fail

UTC1141 -

  • Recent changes have made DSM too lenient so it is detected when it shouldn’t
  • The specification is absolute garbage
    • Doesn’t work on genuine gear, let along knockoff gear
  • Adds RC protocols options so you can specify which protocols you want to be able to decode
  • Vast numbers of ways we get RC input
  • Will need a lot of testing, and volunteers would be really good

UTC1147 -

  • Minimum PWM to honour on the start channel
  • RC option switch won’t allow bands of allowable PWM values
  • RC channel min?
    • Existing setups people may not be able to stop the motor
    • Key safety feature would be disabled
    • Using new parameter makes it opt-in
  • In the particular case there was no RC failsafe
    • Ppm doesn’t have any way to transmit it except via throttle channel
    • Rfd900x firmware is really difficult to get working correctly in case of RC loss, and very hard to test
    • Failsafe throttle value was below 1000 so the throttle level dropped
    • Throttle failsafe was also disabled
    • There’s already a throttle-failsafe==2 option
    • Spektrum transmitter
      • Rfd900x ppm pass-through
        • Spektrum -> spektrum receiver --ppm–> rfd900x -> rfd900x --ppm–> autopilot
      • Issue with all kinds of input from pilot
        • roll/pitch/yaw all mixed up?
        • If in auto and no stick-mixing, not a problem
        • throttle-failsafe==2 help here
    • Could have a new RC channel option instead of a new parameter
    • One of the three positions has to be a band
    • at&r
      • Record current PWM as the failsafe values
      • No equivalent for reading the values
      • Can’t specify explicitly
      • To test it you have to depower the ground radio so you can’t see the values
    • These radios are out and being widely used
      • Deal with the reality of a bad piece of hardware
        • Firmware
      • This is still probably the best of what’s out there
      • There are firmware fixes that work
      • 3.x firmwares have half the bandwidth of the 2.x releases
        • Manufacturer is aware
        • 2 or 3 Mbit changes halve the available bandwidth on low bandwidth
          • Manufacturer doesn’t want to fix it
      • Tridge is considering offering a patch against the 2.x firmwares
      • Rfd900x firmware needs a lot of work to be of quality sufficient for the applications it is now being applied to
    • Really, really difficult to test
      • Engine has to be running
      • … so using USB to test is problematic
      • RCOU logging doesn’t log last two channels
  • Randy’s not going to block this as Copter doesn’t use ICE
    • But does object to the way the situation is being handled
  • How long do we have to carry this “fix”?
  • Tridge is taking responsibility for this change

UTC0005 -

  • Motors library from LUA
  • Works and is tested
  • Set-output-norm does honour the channel reversal
    • Comments have been corrected
    • Same approach for Copter will be a little problematic
  • Perhaps we ought to fix get_output_norm
    • Want to get this merged before end of GSoC period
    • Rename old one and create a fixed one
    • Don’t want to ensconce poor semantics
  • Not using output_scaled; at function level as opposed to the others which are servo-level
  • Will merge it after a bit… Hopeful MdB will review

UTC0013 -

  • Important safety fixes
  • Enthusiastic partner willing to test stuff
  • Randy will look at

UTC0016 -

  • Fixed loiter-to-alt with terrain target
  • Peter will look at it and merge it if he doesn’t spot anything wrong
  • Use same altitude for condition
  • Terrain is tricky
    • On each loop you have to track to go over a mountain

UTC0020 -

  • Disable commands for unimplemented functions
  • Apm_config.h going away?
  • Make it easy for users to disable?
  • -Wundef really ought to work for us - why is it not working?
  • Make one build with -Werror
    • One of the stm32 boards
  • Probably won’t pass when rebase
    • Peter will rebase it and see what happens in CI

UTC0029 -

  • Is this going to break Solo?
  • Is there anything out there looking the command-ack?
  • If nobody uses the message then nobody sees the ack
  • Does this improve life for any user?
  • MissionPlanner needs to change to using the mavlink command
  • This won’t get merged. It should be removed when we stop handling set_mode
  • QGC also uses SET_MODE
  • The ack makes it into the tlog which makes it rather useful

UTC0042 - redux on the adsb avoidance code

  • Sam and Tom will take this and run with it

UTC0051 - Plane update


  • Release delayed

  • More compass issues, confirmed by Sid

    • Compass ordering used wrong variable
    • Reordering on boot wasn’t working
    • Variable wasn’t initialised
    • Reboot is currently required to change ordering and stop using a compass as primary
    • This was a fairly fundamental rewrite of the compass ordering
    • You have to make sure an autotest fails when the functionality is broken
    • No autotests for the compass priority stuff
  • What’s the expectation with the reordering?

    • Where is the behaviour declared? Need to document the device ids
    • After you do the reboot after doing the reordering then the compass IDs should align with the compass priority IDs
    • Graphing the three compass can be very confusing
      • Graphing didn’t align with the compass dev ids
  • Second mag popped up

    • If primary compass dies
    • The EKF does not switch to a backup compass
      • Huge shock to both tridge and Randy and Peter
    • Test for switching compass is around the test it uses to switch
    • Never runs test if compass is unhealthy
    • Really, really bad for Copters
    • GSF may save you on master
    • Will still switch based on bad innovations
    • Compass_use to zero didn’t force the thing to change
      • EKF just stopped fusing compasses entirely, probably wrong
  • PR options for killing compasses….

  • All a bit sad at the moment

  • Tridge has been very tempted to remove the compass changes from the stable releases

    • We don’t have the ability to test the code properly
    • Randy thinks it might be too late to go back….
    • Need a test plan
    • What are we going to test, what’s the expected behaviour?
    • The people doing the previous testing might not have understood the intended behaviour
    • Need to make sure the offsets and diagonals shift
    • Save before reordering, look at param diff afterwards
  • Autotest would be good…

  • Probably another beta for Plane once this gets sorted

UTC0059 - Copter update

UTC0118 - GSoC

  • Heaps of good stuff on object avoidance and walking robots
  • PH is working on documentation for the new stuff
  • Matlab serial connection….
    • Test new driver to get matlab to do pretend sensor
  • Thien’s 435i camera has gone well
    • Documentation coming!
    • A partner has confirmed that a 435i has worked for them for BendyRuler avoidance
  • EKF stuff isn’t mergeable yet
    • Meetings to be had

UTC0121 - close

1 Like