Attendee count (max): 21
Discussion of gps-less Plane
Ekf display stuff
10:07am - Randy and 3.5 release
3.5.4 - https://github.com/ArduPilot/ardupilot/projects/4
Needs help from Peter on dataflash stuff
Francisco is helping out on lightware stuff
Nsh console support needs to be hunted down and added
FF: Copter 3.5 branch in PX4NuttX created by Lucas
Tridge: why not just use master?
Just to not change stuff when not needed for a point release
Tridge: PX4Pro support?
Randy: adding support for this would be a good thing to do
Will use master
FF: My only issue with adding PX4-v4pro is that we’ll need to backport more commits from master and it takes time to track them down
PX4Firmware and NuttX will need to be updated
Substantial patches but very well done
Doesn’t impact other boards
AP_Compass and AP_InertialSensor have switch statements which will need to be augmented
Add to enumeration as well
Lots of cherry-picking
Maybe, but hasn’t been tried
More similar to PixRacer than PX4 Pro
Stm32-errata flash-storage fix is everywhere anyway
Which is why Lucas is interested / created the 3.5 branch
There are issues with CAN GPS
Worked on Copter 3.5
dual-CANBUS-GPS is almost certainly broken
Needs tracking down
CANBUS in 3.5 is the old canbus code
Would need to move to new code to get all the fixes
Don’t want to fix old code!
Floating point exception in SITL
Suppressed on real boards
Need to get 3.6 moving
Lots and lots of merge conflicts
And people are asking for features in 3.5 which are in 3.6
E.g. px4pro support
Same with plane 3.9
MdB: SBF GPS is much much better in master then any released version
[10:23 AM] (Channel) MdB: but backporting means I haven’t tagged it for a backport
[10:23 AM] (Channel) tridge: michael: if the SBF changes are separable e
10:23am - Rover
Pivot turns in auto mode
Guided mode fix from Pierre
Will lose reverse mission item for pivot vehicles
10:25am - tridge and Plane
3.8.3 beta3 and beta4 went out in the last week
Bunch of people tsting it
Changes in tailsitter code to do with transitions
New transition strategy
Control is proportional to hover throttle so we now take that into account vs hover-throttle
Really good feedback on transitions now
Significant change in quadplane transitions
Rtl to qrt
Used rtl radius
Someone set it way too small
Vehicle tried to stop too fast
Vehcile flew way too far
So instead of using this parameter
Use new parameter which sets deceleration rate
Takes into account groundspeed vs airspeed
Transitions earlier or later
Dual-airspeed support will not be in this release
But support will be going into master
Along with a new airspeed driver
No zero-offset required on startup!
No covering the pitot tube required!
May be more susceptible to moisture or rain
Should be using airspeed innovations etc etc
Massive i2c noise affecting airspeed sensor == crash in one instance
Issue created, https://github.com/ArduPilot/ardupilot/issues/7188
Present on 4525
MdB and tridge found mechansims to reduce impact via double-reading the sensor
Can’t use this on the 5525
Get zero always
More susceptible sensor we have and can cause a crash
PR has suggested a filtering strategy
Not sure if this will be a 3.8.3 thing
Not implemented yet
Shouldn’t be extra lag
Backend sets flag, frontend does filtering
Has advantage that the logged value would be unfiltered
Tridge hasn’t flown the sdp yet
Been using it to test the 5525
With a split-tube
1kHz sampling with auto-averaging
Suspicion about compensation settings
The mass-flow-to-differential maths may be suspect
High-alt, low-alt, is it accurate?
Sensoron may not have gotten the maths right, we’re not sure
Sensitive to moisture?
Partial-covering of hole will dramatically affect air-flow
As opposed to a simple pressure-sensor
Also may drag water onto the sensor itself?
Will it cope with this?!
Need someone to experiment with a misting spray and a fan
JW(apache405): i have stuff for doing that test
Shouldn’t the manufacturer be able to do this?!
Would be great to do this with the t-piece and the dual-airspeed patch
No direct contact with sensoron ATM - drotek were working with a contact in there
There’s another pitot tube design which can dump the moisture out
Much larger tube
Waterproof Gautex membranes but also allows airflow
Should be easy to test
Sensoron supplied a whole bunch of equations to convert from mass-flow-to-diff-press but we don’t know how sensitive the equations are to shape and length of tube so only being tested on one tube from drotek
Tridge looked at contributions from various parts of the equations
.02% term removed!
Based on expected airspeed range
Are the changes linear to the diameter?
Then could be captured using the airspeed ratio and learn using autocal
If non-linear we’d need some sort of calibration
Older parts are EOL so some replacement is needed
SDP might be it
Maybe in a month time there might be an answer
The dual-setup might not be valid for both a mass-flow and a diff-press sensor due to the pressure drop due to flow-through!
Tridge has been testing for plausible numbers
Named-float should be removed - MdB
People shouldn’t start relying on it - tridge
Need an airspeed2 message
Not mavlink2 extenstions for various reasons
Instance-id-containing-messages have problem that graphing programs suffer
Even MAVProxy’s condition doesn’t work well
10:52am - amilcar and low-altitude fence
Fence and proximity
Low-alt fence that uses and alt from baro, gps, mavelmind etc
Nothing that resembles a rangefinder
Second feature would be to have a proximity which would use the rangefinders (360 and otherwise)
Would use the proximity margin to keep the vehicle clear of obstacles
Problem is which margin to use?
And also which features to use
If you disable proximity you would not use rangefinder
[10:57 AM] (Channel) FF: Proximity and fence are different. Fence is supposed to be an altitude related to the earth, proximity is related to distance to the vehicle
So Avoidance is supposed to stop vehicle hitting things
Data should come from proximity and fence
Both fence and proximity have a margin, ‘though?!
Seems OK to Randy
Fence is a virtual area however it is defined
Low-vehicle altitude fence is the goal
Repulsion model in avoidance
It struggles determining how to balance fence and proximity ATM
FF: Fence based on terrain
Terrain-following would affect fence?
No, fence is alt-above-home
There might have been a momentary mistake that it was above-terrain, since fixed to be above-home
Amilcar is thinking of above-terrain vs above-home
Could this be done via a parameter
Low-altitude-relative vs low-altitude-absolute
Maybe this shouldn’t be part of the fence?
Ground in fence
Ground in rangefinder
Ground in terrain
The real ground!
Maybe a third thing into Avoidance library?
Want to do stuff with just Lidar or with srtm data too?
Fence was really just meant to keep you in
Shouldn’t everything come from the EKF?
Should use it too for low-alt-fence
Randy will look
11:15am - APSync
Lots of cool development in companion-computer-land
Equal billing required for different solutions
Different solutions for different roles?
E.g. Maverick has Ros
Video streaming in Maverick?
[11:35 AM] (Channel) Buzz: I had a little go at tring to run https://plot.dron.ee/ as an offline webpage, and failed.
11:34am - ISBH and ISBD
ISBH and ISBD support is in Mission Planner and does work
Timeline of FFT in dron.ee!
Hopefully we can get source release and collaborate
11:39am - GPLv3
User must be able to upgrade their device
E.g. heart monitor in hospital is NOT covered
See “User Product” definition
Many cases of this
Also E.g. code in ROM
Watered-down in committee
If unclear then it is a consumer device
Can’t use “primary use case”!
Must be “only signficant use case” to be exempt!
Installation information including keys etc etc
Just consumer products vs not-consumer-products
Commercial aircraft where regulatory agency wants a particular version and can’t be modified by end user?
Nothing different software vs hardware modifications to an aircraft - locking down software vs hardware!
Use-case for ROM
JC’s CAN-based bootloader
License is being used by an excuse by some uits in a Big Company so discussion on this point is very useful!
Automotive Linux will be a useful thing to look at for this
11:56am - stale pull request
Tridge will fix the commit message and merge it in in
Tridge wll go back and make sure of this one
12:01am - https://github.com/ArduPilot/ardupilot/pull/7104
General agreement to rename to ap_upload
Tridge points out that he worked with Mike Smith on this script
12:08am - GPL requires consumer to be notified of their rights
Washing machine example!
12:09am - https://github.com/ArduPilot/ardupilot/issues/3064
Rudder unlocking heading in cruise
It’s supposed to do that!
Will change it so you can use yaw or roll to change heading in cruise
12:11am - six battery support in ArduPilot
Parameter for number of batteries
Vary number of parameters based on another parameter
Hiding would work
Extensions needed to mavlink to support addition/removal?
Generating we currently can’t do
Limits we need to worry about and those we don’t.
MdB consolidated is not sufficient
Problem is the parameters aren’t
12:20 - extensive discussion on dataflash log naming
Mavlink and sd card are two different subjects!
Any change in naming on the SD card has to be optional
12:39 - Conference in Canberra
17th and 18th
Suggestion is people stay at Diplomat
Don Gagne should be invited down!