Dev Call May 13 2019 2300 UTC

Development Team
1

Issues & Pull Requests









  • Battery Failsafe Parameters in percentage (rather than mAh)
  • .h vs .cpp housekeeping

GSOC

*Announcements

Plane
*3.9.8 Plane release update

Copter

Tracker

Release Update

2

Attendee count (max): 16

UTC2302 - https://github.com/ArduPilot/ardupilot/pull/11338

  • These have been around since before we had live parameters

  • Just more clutter

  • This is the easiest way for people to find features which can be turned off

  • Randy believes people use this to work out which features can be turned off

    • Randy would prefer to keep this for Copter

  • It does have user hooks in it

  • Will leave the one in there for Copter but remove the rest

UTC2307 - https://github.com/ArduPilot/ardupilot/pull/11311

  • Persistent data structures

  • Significant expansion over existing watchdog support

  • Tridge would really like more review over this

  • Additional logging which tells us before and after watchdog reset what’s going on

    • What main thread is doing and why it is not responding

    • One report of a Solo resetting in flight

      • Did appear to have some sort of hardware issue

        • Baro did not come up after reset

    • Really need more diagnostic details after a watchdog reset

    • Gets scheduler task running

    • Semaphores held

    • Gets rid of ap common semaphore and moves into ap hal semaphores.h

      • Needs hal structure for logging it needs

      • Expect_delay macro now nests

  • Large but important patch

  • Related: https://github.com/ArduPilot/ardupilot/issues/11296

    • Removes watchdog reset from Solo

    • Understandable reaction from Matt

    • Even losing a Baro we should recover

    • We now have telemetry logs!

  • With these patches we get logs even with the watchdog inactive

    • So the vehicle will crash with motors running but we will get detailed diagnostics

  • Really needs another reviewer

  • From the log we can say the main loop stopped running

    • But the baro does indicate it may have been triggered by a hardware failure

      • No excuse, we need to find where we are stopping

  • We could log number of SPI and i2c operations too

    • And more things

  • Expect_delay_ms rather than expect_delay

  • MdB has left some comments

UTC2310 - sailboat into a class

UTC2322 - https://github.com/ArduPilot/ardupilot/issues/11296

  • May not want this after all as it seems to look like a hardware fault

  • With tridge’s PR we get diagnostics regardless

  • Devcalltopic removed

UTC2325 - https://github.com/ArduPilot/ardupilot/pull/11258

  • out-of-time refactoring

  • Fixes out-of-time for Tracker

  • Fixes board-config-error for Sub

UTC2325 - https://github.com/ArduPilot/ardupilot/pull/11200

  • No Tom

UTC2328 - https://github.com/ArduPilot/ardupilot/pull/10402

  • Tradheli ap_motors

  • Add heli rotor speed

  • No Chris

UTC2328 - https://github.com/ArduPilot/ardupilot/pull/10409

  • Randy did a thorough review

  • Back into Chris/Bill’s court

UTC2330 - https://github.com/ArduPilot/ardupilot/pull/9716

  • Tidy up only

  • Any time we were calling start there were

UTC2332 - Battery Failsafe Parameters in percentage (rather than mAh)

  • David S would like to discuss before making enhancement request

  • Move battery failsafes from mAh to percentages

  • Good for different capacities

  • Using mAh means you are specifying how much energy to get home

  • Why percentages?

    • Could make it backwards compatible by setting the mAh parameter to zero and using the percentage parameter otherwise

  • 4 or 5 hour flights?

    • Then you swap to a half-sized-battery

    • Then your percentage specifies a much, much smaller amount of energy

  • Can this be done entirely GCS-side?

    • David doesn’t think this works?

  • [9:41 AM] (Channel) MG: No, in Cross country soaring you don’t return home. You land somewhere else.

  • Third parameter which specifies which you use?

  • Everyone apparently works on 20% battery left

  • This proposal would add 36 parameters

    • Because we have 10 battery monitors

    • Rover users want them

  • People forgetting to change the mAh can cause significant issues

  • RM: Estimating energy to get home would help everybody get home

  • Root cause: users are not configuring correctly for battery size when swapping

  • [9:45 AM] (Channel) ML: It is a lot more complicated than it sounds. Because every vehicle operates differently so there is no one size fits all solution. More and more and more parameters. And also, the leash makes it virtually impossible to accurately calculate travel time.

  • The 20% is uncertainty for tridge, not a true amount remaining

  • A % uncertainty as well as a % remaining?

  • @David: which is which for you - remaining vs uncertainty?

    • The whole 20% is probably uncertainty

      • Copters don’t get that far away…

  • Single parameter which says what the battery uncertainty is?

    • Failsafe at 0 capacity but some uncertainty percentage

  • How to you create two threshold failsafes based on this uncertainty?

    • E.g. rtl vs land for warn/critical

  • Smart batteries are an edge case…

  • 32 more parameters - bad?

    • [9:56 AM] (Channel) MdB: User setup/confusion/support/download time of params. (mostly the former ones for me)

    • We’re currently out to over 1000 parameters for quadplane

    • Tridge is still thinking about a faster parameter transfer protocol

  • CE thinks this is a standard operating procedures problem not a technical issue

    • Non-aviation end users don’t think this way

      • System design needs to take this into account

    • Then why are they using different battery sizes?

  • Proposal #n:

    • Critical and failsafe percentage

    • Global, affects all batteries

    • If they’re zero then you use the battery mAh

    • BATT_CRT_PCT and BAT_FS_PCT

  • If the user changes battery capacity they should change parameters

    • Users don’t

    • Shouldn’t the user interface ask which battery they are using?

      • Every GCS would have to do that and they won’t

  • Moving this discussion onto github

    • Enhancement request

UTC0000 - .h vs .cpp housekeeping

  • Discussion happened elsewhere

  • Split between header files and .cpp files

  • Typically we have one header / one .cpp file

    • Not the case in GCS!

  • C++ doesn’t let us split a declaration

  • Some classes get too large to put in a cpp file

    • Splitting into multiple cpps can improve clarity (tridge)

      • GCS possibly not best example of that

  • Functions for a class split across multiple directories

  • AP_Arming and AP_Arming within vehicle class

  • Implementation in header vs cpp?

  • Peter is planning on fixing the Logger file one

UTC0015 - https://github.com/ArduPilot/ardupilot/pull/11200

  • Heartbeat interval handled by vehicle

  • Take out special cases and allow users to

  • Vehicle maintainers are happy

UTC0019 - https://github.com/ArduPilot/ardupilot/pull/10409

  • Maybe library_ rather than just _ on method names?

UTC0023 - GSoC update

  • Can we announce?

    • It’s all announced

  • We’ve started to work with the student

  • Rajat’s working on AirSim

    • Got a reply from AirSim today, which is great

  • Peter’s blog post was great

UTC0028 - Plane updates

  • 3.9.8 release

  • Tridge wants to push towards a major release

  • Qautotune!

    • Stop teasing the community!

UTC0029 - https://github.com/ArduPilot/ardupilot/issues/10350

UTC0031 - https://github.com/ArduPilot/ardupilot/issues/9498

  • One user asked for the matex405std for stable

    • Bootloader and hwdef

      • Bootloader may already have been done

  • Watchdog smarts are in stable release bootloaders

  • Copter 3.6.9 should be out this week

    • Minus the watchdog stuff

    • Probably just 3.6.9rc2

UTC0035 - tracker update

  • Do a second beta?

  • Or just a release?

  • Peter will grab Randy to do a second beta sometime this week to get the battery stuff in

UTC0037 - close