Issues & Pull Requests
- Battery Failsafe Parameters in percentage (rather than mAh)
- .h vs .cpp housekeeping
*3.9.8 Plane release update
Issues & Pull Requests
*3.9.8 Plane release update
Attendee count (max): 16
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
It does have user hooks in it
Will leave the one in there for Copter but remove the rest
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
Really need more diagnostic details after a watchdog reset
Gets scheduler task running
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
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
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
We could log number of SPI and i2c operations too
Expect_delay_ms rather than expect_delay
MdB has left some comments
UTC2310 - sailboat into a class
Parameters are also moved
Enough sailboats to warrant doing conversion code?
May not want this after all as it seems to look like a hardware fault
With tridge’s PR we get diagnostics regardless
Fixes out-of-time for Tracker
Fixes board-config-error for Sub
Add heli rotor speed
Randy did a thorough review
Back into Chris/Bill’s court
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
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?
[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
Single parameter which says what the battery uncertainty is?
How to you create two threshold failsafes based on this uncertainty?
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
Then why are they using different battery sizes?
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
Shouldn’t the user interface ask which battery they are using?
Moving this discussion onto github
UTC0000 - .h vs .cpp housekeeping
Discussion happened elsewhere
Split between header files and .cpp files
Typically we have one header / one .cpp file
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)
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
Heartbeat interval handled by vehicle
Take out special cases and allow users to
Vehicle maintainers are happy
UTC0023 - GSoC update
Can we announce?
We’ve started to work with the student
Rajat’s working on AirSim
Peter’s blog post was great
UTC0028 - Plane updates
Tridge wants to push towards a major release
Copter and Rover
No 3.5.1 for Rover yet
Randy’s been looking at getting the OBC code into master
Tom’s also been working on getting the proximity library more accurate and in earth frame
Convex shape issues and small fence issues
One user asked for the matex405std for stable
Bootloader and hwdef
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