Dev Call May 10, 2021

Issues & Pull requests





1 Like

Attendee count (max): 20

UTC2300 - UAVCAN discussions

  • Discussions, discussions everywhere
  • DSO015 dead?
  • Private forum for formulating the next standard?!
    • Perhaps not a good idea
  • PX4 teams wants to move forward
  • DSO-015 was a group effort (not including ArduPilot) that was to become the message set within uavcan v1
    • The only regulated message set
    • Message set was judged not fit for purpose by ArduPilot
      • Tooling around v1 encourages this sort of protocol
      • Manual analysis is time-consuming and difficult
  • CANDevices repo in ArduPilot organisation?
    • Sane message set
    • Tridge thinks this is still a good idea but is currently still trying not to fork any sort of standard and work within v1
      • We really want a standard that can work for our partners
        • Things that will work across platforms
          • But DSO015 was not fit for purpose and the proposed process may not create anything better
  • Again, closed forum for generating a new standard sounds like a bad idea to tridge
    • Topic has been closed off?!
    • Is ArduPilot being “managed” rather than the actual problems being addressed?
  • Thanks to James for keeping his eye on this and nudging tridge to look at this

UTC2311 -

  • Documenting ice start channel

UTC2311 -

  • Function names for tradheli and tricopter
  • Naming, naming naming….
  • Henry wants tail servos documented
  • Tail servo b?!
    • Bill will add some corrections
  • Documentation for Heli specifically
    • @Values{Heli}
  • Will need a MissionPlanner change to pull in different metadata for Heli vs Copter
    • Also MAVProxy
  • Name alignment could be problematic for non-tradheli helicopter types
  • @ValuesCont{…}?

UTC2326 -

  • We don’t ignore fences for Rover
  • Barometric drift causing a fence breach?
  • Put a #ifdef in?
  • Rover in a mountainous area and driving off cliff?!
  • We’ll force the parameter value

UTC2335 -

  • Fence indicator in OSDs
  • Merged

UTC2336 -

  • K_soft_armed_out
    • High pwm/low pwm for armed or not armed
  • Is armed state special enough to warrant this?
  • This will drag SRC_Channels into everything
    • Small platform issues?
  • Should this be done in update_aux_servo_function?
  • Should this be a LUA script?
  • Prearm checks for when script dies
  • Notes left

UTC2346 -

  • There’s a later branch which extends these takeoff changes
    • Takeoff waypoint designates yaw for takeoff
      • During takeoff the trajectory is line segment between start place and takeoff waypoint
        • Measuring at start of roll is problematic
  • This has been well-tested
    • Need to work on getting it in
    • There’s the other narrow-runway takeoff PR

UTC2352 -

  • Stop using constants, derive from mavlink typemasks
  • merged!

UTC2353 -

  • Cleanup of position controller for consistency
  • Fixes lots of little annoyances
  • Little bugs have been mitigated
  • All vehicles are in a consistent usage of position controller
    • Initialisations cover use cases
    • Dynamic SCurve input shaping algorithms for alt_hold etc
    • Things just weren’t initialised correctly
  • Leonard really wants this in for 4.1
  • Precision landing test isn’t taking into account the roll/pitch of the aircraft
  • Touches a lot of vehicles!
  • More consistent across vehicles now
  • Twitch hunting needs to be done
  • This is a signficiant change and something we’d like to keep around for the next 5 to 10 years
  • Quadplane, collision avoidance etc affected

UTC0008 -

  • Double-precision EKFs
  • Not to be merged yet
  • Justification for considering this?
    • There are projects that do require this
  • Not going in for 4.1
  • Some sensors coming in that are an order of magnitude better accuracy so need better data carrying in ArduPilot
  • Flown on F765 OK
    • Divergence so not quite ready yet
  • This will be an option
  • Stack limits go up
    • Had to rearrange memory on F7

UTC0012 -

  • Just a query about the range

UTC0016 -

  • Issue to track progress on getting this into the ArduPilot code
  • Feel free to chat with tridge if you’d like to help with the integration and testing of htis code

UTC0016 -

  • Spamming messages to console
  • Disarmed on ground forced reset
  • If variances are getting out of whack
  • Revisit the bandaid to see if we can avoid the reset?
    • Maybe bandaid is worse than the disease?

UTC0021 -

  • Can be merged once commit message has been fixed

UTC0023 -

  • Merged

UTC0024 -

  • More flash space for such a niche check
  • Will close

UTC0026 -

  • Follow-on patch for previously discussed position controller patch

UTC0027 -

  • VTX power documentation
  • Merged

UTC0029 - Plane update

  • Landing stuff for quadplane to be addressed
  • Paul’s here to discuss stuff now
    • Takeoff improvements
  • Heading PR for 4.1?
    • Maybe…
  • There’s a bugfix in takeoff PR for groundsteering integrator zeroing
    • Integrator fighting pilot also fixed
    • But we have pilot-vs-integrator all over the place in Plane
  • Pitch-angle-tunable is a new feature, other things are modifications of existing behaviour
  • We’ve had another PR which added the lat/long stuff
    • We don’t want to duplicate effort
  • Paul thinks 15536 should go in
    • Centidegrees need to not go in, ‘though

UTC0035 -

  • Timeout for GPS yaw not working
  • External baro plotted in Silicone not a good idea
    • Pressure changed in baro as the thing heated up
    • Vertical speed
    • Interpreted Vertical acceleration
      • Which got fed into yaw!
  • CAN Baros
    • Remember the proliferation of compasses?
    • That’s happening with baros now
    • Piles of baros
      • Often crap data
      • Baros in GPSs for example
        • Tridge was having trouble with one of these
          • Venturi effect
        • Paul’s seen the same thing
        • MAVProxy can tell you which baro it is actually using
        • Baro_primary can be used for fixing things
        • Most of the time the flight controller’s baro will be better than these external ones…
        • Need to work out a plan
          • Same for baro as for compass?
        • Or do we default the ordering to anything other than CAN first?
          • Paul’s always seen CAN baros as worse
        • May break existing setups
          • Need to make change before 4.1
          • Multicopters with baros above the rotor disk
            • On tail boom?
        • Current landings are kind of bad
          • Different defaults for different vehicles?

UTC0047 -

  • Copter update
  • No beta2 just yet
  • D-shot in master is the big query
  • Something wrong with CRSF on Kakute
    • Probably fixed in master?
  • Out-of-date parameter files?
  • “Bad GPS position” appears if you’re only using optical flow in SITL
  • Faster filters aren’t necessarily better
    • Particularly alt_hold oscillation
  • Parameter defaults don’t match
  • We need to explain reasoning on the Copter tuning instructions
    • Explain the why not just the what
    • Tridge did this on Plane
    • Leonard: “But generally Plane users aren’t as intelligent as Copter users”
  • Yaw imbalance thing
    • For helis especially

UTC0055 - Rover update

  • Parameter values not saved for F9?
    • Set the save-parameters thing, turn the setting of parameters off and the EKF whinges about configuration needing to be done
    • uBlox auto-config is very, very complex now
      • Four different config APIs
  • GPS-for-yaw was incorrect - missing a parameter setting
  • Pre-arm-internal-errors for main loop stuck
    • MSP issue?
  • Copter and Rover beta2 tomorrow, hopefully

UTC0103 - Copter 4.0.4-rc2 used very little trust and went up to 3m height instead of the desired 10m height

  • Probably not a DevCall thing at this point

UTC0106 - GSoC update

  • Final look at applicants
  • Two more days before we need to finalise
  • Decisions coming soon
  • We’re happy in that we got the number of slots that we requested

UTC0109 - close

1 Like