DEV call 28 Nov 2016 3pm PST = 28 Nov 2016 2300 UTC


  • 3.4 update
  • AP_Proximity object avoidance
  • non GPS navigation


  • 3.1 Beta / release


  • library/AP_Landing is now merged
  • mission item DO_LAND_CFG



  • auto-disarm-check

10:02am: Jani - servers slow

Servers themselves OK
Possibly move back to the AWS instance for

10:03: Randy - Copter update

Planning a 3.4.3 beta-testing release RSN
EKF lane switching fixes
Vertical Position changes on lane switch
Switching too often
Ledar One fixes
Still have drifty IRLock
JC is busy ATM, so Randy will probably need to look hard at it
6-metre slides when craft descends to 1m
PX4Flow on Pixracer should be fixed on master
uBlox driver losing contact with GPS
Tricopter mushy-yaw problem
Randy is working on:
Object avoidance
Safe Wall-following
Use 8 points and a mini-fence rather than a single point (which would project a long way along a wall)
Problem with lack of hysteresis on offset from object causes unpleasant jerkiness in vehicle
Points are currently in body-frame, not earth frame, changing this might help
PR asks whether we’re aiming at SLAM or collision avoidance
AT suggests we can do more than just the collision avoidance we’re currently doing e.g. avoiding a moving target
Time window for data
40-50 points or so
40k RAM free at the moment (after stacks!)
Doesn’t work in manual modes (poshold/althold/rtl/auto)
People probably want it for some of these
Does it back up? It should, Randy will test
Companion Computers
Automatically connect to WiFi or create hotspot
Store dataflash log files on TX1
Video stuff (LdM + others)
non-GPS navigation
AKA “Indoor loiter”
Some really good flights in last few days
Including outside the beacons
Accurate to ~10cm
Some nextgen boards coming for this
CrazyFly guys producing hardware they’re selling
Bit more expensive than poszyx
Smaller hardware
Poszyx allows a fourth beacon to be located by another three
Underground navigation?
Currently only doing xy, not z
Assuming all beacons in a plane
Multipathing can be a problem with poszyx

10:35am: Grant Rover update

New beta released
3.1.0 will be going out real-soon now
Crash detection PR not going in this time around

10:36am: Tom Plane update

Abstracted out landing code into a library
New parameter LAND_TYPE, enumeration
Will get more e.g. parachute, helical, deepstall
Bz suggests (much later) net landings
PR suggests arrestor wires….
Plan to calculate glideslope etc etc in real-time, make landing easier and more straight-forward
Want more people doing automatic landings
Plan New mission item DO_LAND_CONFIG
Would describe how you want to land
Not defined yet….
E.g. into wind, come in at this angle, ….
Instead of simply dictating points
PR/discussion point coming on this one
Would choose from the enumeration, and supply parameters to it
PB suggests multiple mavlink messages
Bz suggests more mission item types
Tridge wants wind compensation on landing
Landing too slowly in high wind
Should increase target airspeed for landing by about half the windspeed (dot-product with landing approach vector)
This is basically to have control authority in the face of gusts
Should use a steeper slope in higher winds
Also descend later
We have a 3D wind estimator
And also a 2D….
Currently we throw away the Z component
Its unreliable
Wouldn’t save aircraft; gusts don’t get integrated fast enough
Preflare might also help in high-wind landings
Concept of having a go-around dummy run to gather data for more precise landings
Craig mentions MdB would like to know what mission items we support vs what’s in the specs

11:04: PR on CAN issues
CANBUS1 on PixHawk - reports it might not be working
it wasn’t; now fixed
CANBUS2 is working
PR doesn’t have zubax so can’t test
Details still coming in
Might also be on PixRacer
If people see the reports, ask people to use CANBUS2 for the time being update to a more recent firmware
With dual busses, usually run a primary and secondary busses
Flight-critical stuff on one bus (e.g. ESCs)
Non-flight-critical on another e.g. flow sensors

11:14: PR on other hardware news

PixHawk2 flipping on takeoff
Looks like user error; AHRS orientation is probably wrong…
RTK is coming
Looks good in MP!
SF40c improvements are coming
The manufacturer is extremely happy to work with the community!
Going to open-source the software
And work with PR on improving their product
FPGA code won’t be Open Source
New LIDAR coming in January
Size of matchbox
Proper surveying version
Should be cheap!
Randy wants the devices to be really smart in terms of what they send to ArduPilot
E.g. sending through a mini fence the vehicle should stay within
Some musings on FPGA programming being somewhere between programming and hardware
CE suggests thanks to be sent to James

11:22: tridge and SPI and driver changes

Heaps of stuff done in last week, heaps more to come
PX4Flow, IRLock, more magnetomer drivers
MPU9250 icm2068 stuff went in
Fixed bug with thread-per-bus vs thread-per sensor
Working on a PixRacer bug which is difficult to reproduce
Long iteration times because the board hsa to rest before the bug can be reproduced
Had to lower the bus speed to avoid DMA bugs
Varies board-to-board
But DMA means it doesn’t matter so much
Running most sensors at 5.3MHz
DMA isn’t entirely magic
Same memory controller? You may conflcit DMA vs stm32 fetching data
This is noticeable; CPU slows down as memory accesses go up
Doesn’t affect FP so much - just memory-intensive stuff
Can’t use the turn-off-interrupts trick to get accurate timings any more, as DMA background operations can slow you down
EKF is memory-intensive (big matrices)
Could possibly allocate stack in CCM memory
Core-coupled memory
64kB in PixHawk1/PixHawk2
Won’t be slowed down by DMA
Possibly also EKF2 data?
Trying to get scheduling misses to zero everywhere
PixRacer is good
PixHawk2 just has a huge number of sensors, so reading and processing them all makes going fast hard
3000 DMAs/second on PixHawk2
I2c is still interrupt-driven
Might need a HAL allocation layer
“Give me frequently-accessed memory”
“Give me infrequently-accessed memory”
TR1 ranger, PWM input sensor to be moved in-tree soon
New filtering strategy is in master
Possibly some high-frequency noise come through
During test-flight a motor went out
Second time on a flip
Should we try to detect motor outages?
Jetson TK1 based flight-controller
Navio2 shield hacked on top
Tridge broke their MPU9250
PixArt sensor
Really good flow sensor
Test flown on weekend
PixArt did pop into the call but missed this bit
Very promising
Still under NDA, but Open Source driver is released….
Can’t buy it ATM
Vs old mouse sensor:
Interface is very similar to the old mouse-sensor
Much smaller than the old mouse sensor
No bulky lense
Higher flow rates
Tridge is thinking of doing a side-by-side flight PX4Flow vs PixArt
Tridge is thinking of doing dual-sensor support
Sounds good all-round
Currently on SPI, which makes interfacing inconvenient
Requested a tiny bridge be made
Gyro required, probably

12:02 HAL Changes

Mostly so support sensor changes
Flash storage stuff will go in shortly
Lots of churn going on in master
Next wave will be CANBUS changes

12:04 RL on Auto-disarm check

LAND_DISARM_CHECK (or there-abouts)
Having issues with interactions with failsafes and the disarm checks
Should the failsafes (and crash checks) know about the disarm check bitmask?
Randy suggests integrating with the land detector

12:11 Rob - discussion of perceived problems with ArduPilot

“unreliable because of memory overflows”?
Possibly a historical misconception
Poor ROS integration
Randy says that when he’s trying to convince ArduPilot of its solidity he runs through all the stuff we do
Developer testing
Long Beta periods
Weeks of no unexplained crashes
Patch releases if things do go wrong
ArduPilot’s architecture (threading model) makes timing much more reliable on ArduPilot than other autopilots
DMA works well on stm32 but would be difficult in other autopilots

12:21 tridge more dirver stuff

Three high-rate DMA-enabled SPI buses now available on px4v2
SRXL support by a couple of awesome developers
Including documentation!
No, really!
Support from manufacturer was really good; they lent Hans a whole lot of gear
Tridge worked on this stuff remotely (transferred the data via tcp to Canberra)

12:23 Contribution of the month

There exists a proposal for this
Possibly a label in github
“Great Contribution”
Small blog post
Proposals committee will probably handle this for the time being

12:26 guided mode and speed

In auto WP_NAV_SPEED not picked up until you get to the first waypoint
But BB is having trouble in guided mode with the speed not being honoured
Randy thinks leash length
Tridge suggests recalculating at a 1 second interval, or just to make sure that the relevant flag is set

12:30 BB Tower release coming out soon

Name change coming

12:32 ArduSub

GPS on surface will require a bit of work

12:33 JM Edison image on PixHawk2

Lots of other stuff
Having trouble finding ways to distribute the image doesn’t seem to flash the whole image
Weird user-land problems (unable to su / sudo) after flashing to a second

12:41 TP - PR to accept a guided command within an auto mission

Much discussion for a simple PR
PR shoves in command from the side
But doesn’t fix the verify side of things; the verify still comes from the old command…
Should all be possible just using a companion computer