Dev Call May 28, 2018 2300 UTC

Development Team
1

Issues & Pull requests









GSOC

  • Funding Proposals

Plane

  • Release Candidate Testing

Copter

  • Release Candidate Testing

Rover

  • Release Candidate Testing
2

Attendee count (max): 19

UTC2300 - making RC overrides common between vehicles

  • Use a parameter for timeout?
  • Copter says it is 1 second
    • But apparently it doesn’t work that way ATM
    • Fire up SITL
      • Put Plane into cruise
      • Put into hard-right-roll
      • If you stop giving input it will continue this roll
      • Zeroing the inputs still works
  • Timeout-per-channel
    • Not good
      • Array is verbose if you want to pass that
    • Time_ms argument to set-override?

UTC2312 - saving mavlink stream-rates to permanent storage

  • Stop saving them based on streamrates
  • We have parameters which already do this
  • Randy is OK with it
  • OSDs?
    • Could set the parameter
  • Vehicle on ground
    • Preflight reboot
    • Resets all streamrates
  • Battling streamrates
    • Parameter getting rewritten all the time
  • Tridge has concerns about this behaviour change
    • Do the GCS behave appropriately?
  • Companion computer on the Plane
    • Cares about camera streamrate
    • After reboot would have to check rates
      • Refetch parameters etc etc
        • Fetching by name is nasty, nasty
  • A parameter to specify the behaviour?
  • Tridge would like it persistent on all vehicles!
    • MdB would really rather it not!
      • MAVProxy’s change-streamrate behaviour has bitten him before
    • Amilcar doesn’t like persistent
    • Randy doesn’t care if it persists
    • Randy took it out because of scheduling misses
      • This is something that could be turned off
  • Peter will create a PR to canonicalise one way or the other
  • This one can go in

UTC2328 - vfr-hud height above ground

  • https://github.com/ArduPilot/ardupilot/pull/8434
  • Spec says MSL
    • Copter sends height-above-home
  • Global-position-int has height-above-home
  • Px4-firmware use MSL
  • No GPS means you have to use height-above-home
  • OSDs?
    • AP OSD expecting MSL
    • Night-ghost MinimOS isn’t clear
      • Comment says one thing, code says something else
  • Plane’s airspeed behaviour is odd
    • GCS can show you’re flying at 14m/s when you actually have no clue
    • When disarmed it’s useful you’re getting airspeed output
    • Not healthy means output is frozen
    • Need to be able to test airspeed on ground
    • Unhealthy should read what?
      • SYS_STATUS has bits for this?
        • MP doesn’t handle these bits very well
        • MAVProxy’s array-of-sensors display works well…
      • Enabled and not healthy should be 0? -1?
        • Sending the estimate is bad in that you can’t know if that number is coming from the estimate (without looking at SYS_STATUS)
    • A new AIRSPEED message?
      • Value from sensor and estimate
      • An instance message
    • MdB thinks “just send estimate”
      • Tridge isn’t opposed, as MAVProxy tells him straight away that the sensor is bad
        • MP is a real problem here, however
  • Can rebase this and get it in
    • Peter will get a couple of PRs in for the function changes

UTC2337 - common home stuff

  • https://github.com/ArduPilot/ardupilot/pull/8427
  • Tridge is happy to kill the statustexts
  • Home icon is now present on MAVProxy
  • We never retrieve home from storage
    • Tridge would like to leave it there for the time being
  • non-GPS-navigation users would like a permanent origin location
    • Change mission0 to store origin
  • Can go in once statustexts are removed
  • Some future PR to make storage of origin in mission0 consistent

UTC2350 - moving code into AP_AHRS

  • This one can be killed for the time being as a lot of the benefits are in #8427

UTC2357 - force minimum groundspeed

  • Plane options parameter to change behaviour?
    • Force max airspeed work
  • Fly-forward assumption can have issues
    • Does maths break down at zero-airspeed?
      • Need to check with Paul
  • TECS_OPTIONS
    • TECS isn’t what does minimum groundspeed
      • But probably should
  • Boats should have a through-water speed estimate
  • Have an enforced-maximum-airspeed parameter
  • We don’t limit Gs in turns
    • We probably should
    • Most people won’t know what’s reasonable for their vehicle
  • Tridge wants to test this PR himself
    • Push up windspeed and make sure it works in a reasonable fashion
  • Great to see someone looking at this
  • Static ms should actually be in the class (possibly in a sub-structure)

UTC0004 - arming switch race condition

  • Corner case
  • Seems good to FF
  • Tridge has alternate approach
    • New enum value
      • Safety-transition
    • Not necessarily better
  • Tridge doesn’t mind covering this
  • Narrow race
  • Checking IO healthy when arming?!
    • Only a problem when IO is present
  • Maybe better to be able to tell when IO is healthy
  • There’s a pending PR which goes into the sensor-failure loop if IO not of appropriate CRC
    • There’s a parameter to turn that off
      • IO_ENABLE value
    • Might pull this out as a separate path
  • Is-io-healthy is a really good idea
    • Particularly on quadplanes
    • Tridge will add a note on one of his PRs

UTC0011 - https://github.com/ArduPilot/ardupilot/pull/8092

  • Do we really want this behaviour?
  • Trying to put a delay in writing the camera packet into the dataflash log
    • 20ms resolution?
  • Should probably be done post-flight
  • MdB: Camera won’t be that good anyway
    • Cameras have a huge jitter
  • Better-precision geotagging
  • Trying to fake feedback without having feedback
  • Sometimes it’s worth putting stuff in to make support requests go away
  • Grab later GPS position and attitude information to associate with image
  • Wants 120ms delay
    • Less that one GPS frame
    • We could do some extrapolation ourselves in the code
    • Would give a better result than what’s here
  • Assuming 50Hz loops is bad
  • Millisecond value if it is going to be anything at all
  • CanberraUAV software already interpolates values to give a better position
    • So does MdB’s software
  • Centiseconds are not a great unit
    • Already present in code
  • Parameter name isn’t great; it doesn’t delay, it’s more of an offset
  • So… do we want to do this live rather than in post-processing?
    • Push to get this to a level to be merged?
      • Can’t go in in current form

UTC0019 - CANBUS message corruption resolved

  • CANBUS sniffers on Linux were showing corruption that wasn’t there
  • But there was still corruption!
  • Fixes are all merged
  • Servo limiting hooked in servo channels rather than in HAL, which is nice
  • SCHED_LOOPRATE @800Hz in Copter still works
  • Can be reasonably confident CANBUS ESCs and servos will work
  • Can update servos at a lower rate
    • Defaults to 50Hz
    • Servo messages take up a lot of bus bandwidth
  • Tridge would like to get some CANBUS servos so he can test this himself
    • HITEC claim to have them
      • Tom is following up with them
      • Jeff will also chase them
    • Funding request should be made?

UTC0026 - Units stuff with Amilcar

  • Proposal to make units common across all areas where we use them
  • We have validate in parameter parsing code
  • We have units in dataflash logs
  • We have units in mavlink messages
  • Three different places
  • Move validation into a single class?
  • Information about units
  • Information about long descriptive text
  • Class would generate a header file for the dataflash library
  • Would be available for param parser
  • Would change XML on the fly so pymavlink could use same unit definitions
  • GCS could also hook into this
  • AP build process would need to call functions from pymavlink to generate header
  • Any behavioural change in DataFlash?
    • Should be none
  • Will make units consistent across all places in code
    • Ideally no functional changes
      • Except where units are inconsistent
        • Then they’ll become consistent
  • A commit into pymavlink to add a unit into the dataflash logs?!
  • Would give somewhere for other autopilots to share unit information
  • Do this as compile-time warnings instead?
    • Would reduce friction
  • There would be a lot of units present
  • Arguments for having units only allowed in logs rather than in parameters?
    • E.g. Moving to metres in parameters
    • But radians in logs
  • Needs to be non-fatal
    • (Channel) MdB: The point was to reduce list locations, thats increasing the complications now…
  • This one’s going to be put aside for now
    • Maybe pick it up later on
  • Amilcar’s is working on deprecation tags in the mavlink XML
    • 2-year limit on deprecated messages
    • Need to be careful on who gets to mark things as deprecated where one autopilot is happily using a message and others are not
      • Could get hairy

UTC0046 - GSoC update

  • Jaime’s students are going pretty well!
  • Funding requests were approved
    • What’s the next step?
      • Tridge just sent the money to Ebin and then he’ll request reimbursements
        • Tridge just finds this a convenient way of doing things
      • They could buy the parts and submit a reimbursement request
        • If they need the money before purchasing they’ll have to wait for the money to get transferred from SPI
          • Could be a few weeks
        • Or get another AP member to cover it
  • Ebin is making great progress on the balance bot
    • Concentrating on getting physics simulation of balance bot working well
    • Lots of excited users on the forums for this one!
  • Video pipeline stuff is moving along to choose a good bitrate for the link you are transmitting video over
  • Dmitri and CAN SITL
    • UAVCAN simulation in SITL!
    • Many messages are already being sent!
    • Commits are being cleaned up ready for PRs
    • Simulated sensors ATM
      • Sending data as a UAVCAN frame
    • Using SITL with real sensors would be really, really nice
      • Babel is coming
      • Option to connect to real CAN devices from SITL would be awesome
        • Not currently on roadmap
          • Would like to add it in
          • Gdb to step through drivers etc etc
  • One of our students had to drop out because of a visa problem
    • He may still work on some of the stuff on his own time
      • Can’t be an official GSoC student
  • Blog posts would be good from our students!
    • one-page-status

UTC0059 - Plane release testing

  • Not a lot of activity
  • Main feedback is “where’s the new feature?”
  • Use Button library rather than hal.cpio?
    • Originally for humans
    • Reported to ground station…
    • Debouncing….
    • Scope creep to move this to AP_Button?

UTC0105 - another RC for Copter due out this week

  • Rebase will be done for this RC
    • Important CANBUS fixes need to go in

UTC0107 - build more boards on autotest?

  • Could probably build 4 or 5 more than we currently do
  • Fmuv3 + parameters for Cube

UTC0105 - RC for Rover 3.3.1

  • Ran into issues on accel/decel
  • Will go straight to 3.4 because of number of changes
  • Beta Rover 3.4 in next week

UTC0109 - new parameter for choosing default tunings for Copter

  • Little quadracers don’t autotune well
    • Need different starting point
      • Mostly filter rates
    • Can’t change defaults because it will break existing functionality
  • New enumeration for basic class of machine
  • FRAME_SIZE
    • E.g. 250-class-hovers-at-20%
  • Not a great name
    • FRAME_TUNING?
    • Suggestions welcome!
      • Default PIDs
      • Default filter rates
    • 5 core parameters affected
    • 5 more would be nice
  • Tridge’s Copus frame flies really well after autotuned with correct starting point
  • Why not default parameter sets?
    • They get out of date
  • Maybe FRAME_DYNAMICS
  • AUTOTUNE_DYN
  • FRAME_TUNECLASS
  • Apj file also allows you to set defaults
    • Will explode the number of apj files
  • https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/quadplane.cpp#L379
  • Different sets of tables for different heli sizes
  • [11:19 AM] To Weekly devcall:
  • https://github.com/ardupilot/ardupilot/blob/master/libraries/AC_AttitudeControl/AC_AttitudeControl.cpp#L5
  • New .cpp file which the vehicle maintainers can look after
  • Not for autotune - these are default parameter values
    • [11:23 AM] (Channel) Michael_duBreuil: +1 to the whole idea. I only got my racer going because I could talk to leonard…
  • FRAME_TUNE_DFLT
3

This would be a huge win, I’ve lost count of number of people I’ve seen give up with Arducopter on small (<= 350) size copters because the defaults are so far out for them to make them unflyable, never mind autotune. And GCS by default limits you to put really small PID values in so you have to manually override, which a lot of people aren’t comfortable with.
This would be a great UX improvement.

1 Like