DEV call 05 Dec 2016 3pm PST = 03 Dec 2016 2300 UTC


  • AC3.4.3 release update
  • object avoidance
  • Enroute sponsored “sync” project which aims to improve our companion computer “infrastructure”.


  • support for brushed motors
  • plans to support dshot protocol


  • What Missions Items we actually support
  • RTK Stuff


Pull Requests
We are down to 80! A big thank you to all involved

Rover Update

C cast vs C++ cast (

ArduPilot Dev Call 2016-12-06

10:00am: Randy - Copter update
running a bit behind on support
proximity / slam / sf0c
tx1 initially
dataflash logs streaming to companion computer
sync to cloud
simple configurator
create AP / connect to AP
Someone has written a mavlink <-> MQTT bridge
vs rtps?
enRoute’s end-of-year demos worked well

10:26am: tridge sensor update
Brushed motor support added to master
Only on stm32 ATM
Flies well on little tiny drone (120g)
Small patches to Rover required to support brushed motors
Tridge has started to look at what it would take to implement
Blheli and kiss support this protocol
Not a pulse-based protocol (pulse-based protocols are one-way and suffer precision issues at small timing windows)
D-shot is a serial, packet-based protocol similar to S.BUS and the like
Very high clock rate
e.g. 100-1200kHz
Will need DMA-to-a-pin for these sorts of rates
Construct packets as bits-in-a-buffer
Attah DMA channel to a timer
Tell timer to go
It consumes bits from that buffer, pushing packets out wire at specified data rate
May have problems with number of DMA channels available
Two-way communication may allow RPM, current monitoring
And possibly updating the firmware

11:00am: rover update with Grant
One bug found and fixed
One of Grant’s customers is now advertising “Powered by ArduPilot”
Stadium lighting
One bug to find and fix for release
Khancyr has patch for brushed-motor patch

11:07: MdB - Mission item support
Our storage of mission items is awful
Leads to inconsistencies in interface
Probably want to move to variable-length packets
Michael points out that he’s really more worried about information about exactly how we interpret current messages
Randy points out that Copter does this reasonably well, and that Plane should have an equivalent page

11:07: MdB - GPS fixes
Various fixes going into master soon

11:18: Tom - casting
Question as to what our default should be
General agreement that if a dev prefers the C++ casting then they should be allowed
Devs will have to get used to the C+±stle

11:18: Tom - issues list
Different alts used ekf-origin vs home
Added to 3.8 milestone
Landing stuff should be factored into landing library
Landing flight stages in particular
Frsky multiple-port support
Need a sanity check
Unable to disarm with EKF issues
Probably sensor errors causing attempted motor throttle output which stops it disarming
Airspeed sensor
Tridge thinks there might be an electrical problem with the board
Good when you’re not touching it
If you put it down then the increased airspeed decays over some time
Tridge thinks the software can probably be merged as-is
OLED Driver
Question as to how to handle it - via notify or via telemetry?
Tridge is concerned about i2c bus bandwidth
Could share a bus with critical flight data sensors
50Hz * 24 transfers = more than 1000 transfers/second @ 100kilobaud
Only changes are sent which should reduce rate
But even 24 transfers could take 50 or 60ms
Spreading the update over several timer loops would be preferable
Example merged
Just need to make sure it doesn’t break existing IRLock SITL functionality

12:14: Call for things from the floor
Reminder that there’s a partner’s call tomorrow
2 hours earlier than last time
Randy is up at 6am
Michael’s created an issue for the plane mixer failing

12:16: Call closed

1 Like