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


  • AC3.4.2 update including review of highest priority issues:
  • Issues we’re are seeing with AC3.4.2:
  • EKF lane switch causes serious throttle bump.
  1. LeddarOne still a problem?
    3.4.2 rc 2 and 3.5 Sensor Update - issue with 2 copters with rangefinder
    the read during send is weird
  2. drifty IRlock:
    Problmes trying precision Landing with IR-Lock
  3. px4flow not working on pixracer
  4. GPS driver losing contact with Ublox?
    Loss of GPS leading to EKF 2 Errors - AC3.4 rc 6
    GPS configuration RC7
  5. tricopter mushy yaw: AC3.4-rc1 - Tricopter Test Flight - a couple problems noted


  • Fixes for RPI-based boards after sensors rework, but raspilot still seeing mainloop overruns


  • fast sensor sampling,
  • faster log download,
  1. storage in flash on stm32


  • GPS

latest LeddarOne PR:

Thank you to Peter barker for very detailed notes on the meeting.

Randy - Copter update

  • 3.4.2 has some issues
  • EKF lane switching is a pain
  • Horizontal part taken care of, but not vertical; so on lane switch the vehicle can rapidly change altitude
  • Paul is going to look at this problem
  • Paul has PR’d something to reduce lane-switching frequency
  • EK2_IMU_MASK=1 would stop lane switching altogether, possible work-around, but you no longer have ArduPilot choosing best IMU
  • Question as to why we didn’t pick this up in Beta-testing
  • while throttle glitches were present, they were nothing like what Randy saw in yesterday’s log
  • Enough beta-testers involved in release?
  • Randy wonders whether this lane-changing is worth it
  • Tridge points out that sensor failure is a thing, and this feature can save your vehicle
  • Z-accel can actually invert due to vibes
  • Magnetometer is used for 3D attitude (used to just be yaw)
  • Perhaps fast-IMU sampling will make lane-switching not so much of an issue
  • Lanes are also known as “cores”
  • They are time-staggered (don’t run in the same main-loop iteration)
  • If a core glitches it looks at other core to see if it is glitching; if the other isn’t it does a switch. But the other core might not have seen the sensor data and might then glitch itself!
  • Why not a weighted average of the output from each core?
  • Because the outputs from an EKF are self-consistent, but a weighted average might not be self-consistent
  • Possibly as the weightings changed you would wander around
  • LedarOne still has issues - one major piece of silliness (PR made to fix)
  • Seeing odd jumps between two altitudes
  • IRLock is drifty
  • Comes down to 1m OK, but then wanders off laterally 5m for some people
  • Works very well for some people
  • Mr Challenger is looking at this as he can
  • PX4Flow not working on PixRacer
  • Tridge thinks it can just be compiled in and it will work
  • Randy will set up a racer for tridge to work on
  • GPS driver losing contact with uBlox
  • Michael is looking at the problem
  • Relatively minor issue
  • Baud-rate selection issue
  • PR will be going in shortly
  • Tricopter report - “mushy” yaw
  • Changes were made in 3.4, so something might have broken
  • Tridge points out the simulator might be able to reproduce
  • New code vs old code
  • Play with servo-lag in simulator

Smooth flying

  • After Randy does a few other things he would like to work out how to make EKF “smoother”; users have said the two-stage complementary filter feels a lot “smoother” than the EKF-estimators
  • There’s a branch that allows A/B testing (ability to switch between estimators quickly)
  • But can’t test back to the 3.2 code
  • Paul points out that this s a tuning issue, tuning for one thing means you’ll be giving something else up
  • What does “smoothness” mean? Smoothness in response to control inputs?
  • No, more in angle-change smoothness

Linux Update

  • Handled by tridge today!
  • RasPilot SPI issues
  • Latencies, tridge is trying to pin it down
  • SPI Works well on Disco (and probably Bebop)
  • Segmentation faults - ArduPilot is out-and-out dying sometimes
  • Sensor rotations
  • DSO rotation fix went in
  • Julien is working on rationalising the rotation list
  • Good idea, but a lot of boards to test!

Sensor Rewrite

  • InvenSense black-box investigations - just how do they work?

  • Tridge has worked this out with a suggestion from Leonard

    • 950Hz tone allowed tridge to work out their internal processing


  • Beat frequency at 50Hz (delta of 1kHz and 950Hz) shows that sampling is happening at 1kHz


  • This new code also shows a beat up higher, meaning we really are sampling at 4kHz

  • Filters have eliminated the lower beats

  • Shows the high-rate sampling is really going to help avoid problems caused by 500Hz-1kHz vibration

  • MPU6000 bug fixed this-morning

  • SPI bus is VERY busy on stm32

  • 24 samples every 2.5ms

  • Linux boards use i2c, so don’t have the same issue (i2c is asynchronous for the CPU)

  • Tridge is looking at using DMA for SPI on stm32

  • Setup cost is high

  • Hundreds of bytes/transfer (for FIFO transfers) might make it worthwhile

  • We already use DMA for SD card, UARTs, but not for SPI transfers

  • New filtering strategy for high-rate sampling

  • (insert link from agenda here)

  • There’s been a shift of where we do SPI transfers on stm32

  • Used to be IO thread

  • In thread-per-bus this is done separately

  • No DMA on stm32 we don’t have multiple cores

  • Main thread would get interrupted by IO/thread-per-bus thread, then you would see 800us spike in routine you wouldn’t see most times (e.g. in mavlink routine)

  • Now we do an explicit (possible) 800us transfer as part of the main loop

  • Ensures we are always working with the latest data, too!

  • Less timing jitter

  • Way fewer timing overruns

  • Single-blind of fast-sensor sampling, comment from pilot was “chalk and cheese”

  • Factor of 20 reduction in low-frequency aliasing

  • But not on PixHawk one ATM (slow sensors)

  • MPU6000 does do 8kHz gyros, but should we use that fact?

  • Paul says probably, especially if there’s a blade passage frequency or motor fundamental at relevant frequencies

  • All about beats at the control frequencies

  • FIFO!

  • There are hardware bugs in the FIFO

  • Anything more than 30 samples and you get corrupted (even though it should hold 50 or 60…)

  • Julien had a workaround; he would flush the FIFO when it got too full!

  • The reset as it was could cause corruption (race condition if it was adding a sample when you were resetting)

  • Gyros would get interpreted as accels and vice-versa!

  • Would use temperature as a pseudo-canary…

  • We now use a three-step process to reset the FIFO

  • Set to use FIFO, but no data to be entered

  • Reset FIFO

  • Enable gyros, accels and temperature into FIFO

  • Fast sensors with LSM sensors

  • Tridge talking with ST about hardware bug in lsm303d

  • Progress with ST engineers, they’re trying to reproduce

  • Probably going to be more weird register settings….

  • Luis: How long ‘til we don’t need PX4Firmware tree?

  • Switchable for the sensors (defaults to in-tree)

  • px4io layer

  • ADC


  • Aim is to make it fly better, not to remove PX4Firmware

  • And to share drivers with Linux

  • CANBUS is probably a good next target

  • Px4io is a mess and would be really good to fix up

  • CANBUS F3-based boards!


  • Where should he send these dev boards for people to work on?

  • Tridge is planning on shifting Zubax GPS to new CANBUS framework

  • Question as to whether the protocol is a problem, or the current software

  • Tridge thinks it is the current software, and thinks Pavel has done a good job on the specs

  • Hal.can!

  • Software needs simplifying

  • Best PC CANBUS thing to get:

  • Contact Ben, he has a lot

  • USBtin was recommended, but there’s apparently something better

  • USBbabel nobody has tried (was recommended for remote CAN stuff)

  • Tridge has been doing SRXL dev remotely, and thinks doing the same for CAN should be as straight-forward using this device

  • Philip says unreliable compared to Ben’s

New patch to not use SRAM chip for persistent storage

  • Very expensive
  • Flash-based log-structured filesystem
  • REVO and others (including Phantoms!) boards are stm32 could run ardupilot
  • but they don’t have FRAM
  • There is flash built-into the stm32
  • 2*128kb sectors - each has to be erased all-at-the-same-time
  • takes 0.25 seconds, and the CPU stops while it is doing this….
  • So we only do this when not armed… and every few hundred flights
  • Karma port?
  • They actually probably have FRAM already….
  • Mavic? Probably an F4 or F7
  • ESCs probably the problem; CANBUS escs
  • Currently a compile-time option
  • Requires a bootloader change
  • Or you lose all your parameters….
  • 16kB is still the limit for parameters etc
  • Could be made larger


new OF sensor support

  • Pixart OF sensor PMW3900DH-TXQT
  • 900 pixels
  • Probably 30x30
  • 900 bytes of data
  • Test-flown already
  • Cheap!
  • SPI-only
  • Pin-hole-camera-style
  • Infinite range!
  • Yet to test reality
  • Randy points out at 50m your pixel is 0.5m across, so using it to control drift is unlikely…
  • Uses gyro off autopilot
  • SPI 2MHz
  • Kinda; needs its own bus
  • E.g. not with MPU6000
  • Timing issues, holds CS for long periods of time
  • Might be able to put a BARO on
  • Tridge thinks having this on a separate board with some sort of bridge would be really nice
  • E.g. to-UART
  • Randy reminisces that lenses were a real problem for him
  • Tridge points out these things don’t have lenses
  • OF for height would be really nice on Plane!
  • Apparently Dragon firmware on Disco they’ve got this working
  • Doesn’t suffer from single-point issue that Lidar does
  • PX4Firmware just couldn’t handle the PixArt sensor
  • Time to transfer is REALLY long
  • So you would stop flying the plane….
  • Not yet publically available
  • Philip is hoping a really cheap solution will be available with this
  • Along with a cheap Lidar, perhaps?
  • Really small Lidar out there (matchbox) which might combine nicely with this
  • Would be nice to get some cooking done on that sensor (so we feed it gyro, it gives us height)
  • Lots of caveats in the data sheet about not getting corrupted data (timing constraints)

PixHawk2 or new GPS?

  • Alpha team got GPSs which didn’t work
  • Fairly-straight-forward to fix by someone with SMD skills
  • Might be able to get Mark to fix them
  • People a Australia send them to Philip and he will fix them
  • Base one only (SMA connector)
  • Don’t send antennas or anything
  • Michael O has a corrected one on the way

Question about Edison interfacing

  • Movie studio interested in how ArduPilot interacts with Edison
  • Currently very little - Jaime is working on integration with Sony cameras
  • Randy thinks we need to come up with some sort of base image for Edison
  • Can put it in the same place as TX1 and RPi images
  • Storage on Edison is limited
  • Can take an SD card (would need to modify case…)
  • Edison is not a video solution (NOT the same as Solo companion computer

Solo source code release?

  • Lots of promises from people who then leave!
  • Hopefully before the end of the year!
  • SoloLink source code needs releasing
  • Gimbal source code release needed
  • Stm32 source code on transmitter


  • Fancy imagery stuff enRoute would like to work on
  • Software solution

Intel Jewel definitely worth looking at

  • Video capabilities!
  • Lots of awesome sensors
  • Philip will be doing a carrier board for this for The Cube

Rob - disabling auto-disarm in mid-air

  • Ability to turn it off completely?
  • Extra checks like an ARMING_CHECK bitmask
  • Including a sensor switch
  • Throttle check (throttle is all the way down)
  • Or it could be an enumeration
  • Both tridge and Randy think this is better
  • So this is probably the way it is going to go

More reports of heli flying really well on 3.4

  • Rob will be using it on Procyon soon
  • Heli setup screen for MissionPlanner isn’t working
  • Need to open an issue on MP

Question about frame type parameter defaults

  • E.g. Iris frame type
  • They are horribly outdated
  • (this is the real vehicle parameter defaults we have, not the simulated vehicle parameters!)
  • Iris and Bebop have been done
  • Others are bitrotting
  • Could auto-update
  • Could delete
  • No ownership of most of these files (Randy doesn’t have all the frames)

AP_Landing PR!

1 Like