Dev Call Aug 21, 2017 2300 UTC


  • Copter-3.5 update


  • update


  • new in-flight compass calibration system



Funding Committee

Attendee count (max): 25

09:05am - Contribution of the month for July
Wheel encoder support from Paul Riseborough
50% of the vote

09:06am - Vote for James and Alex to join the dev team
Welcome to both new team members!

09:07am - Randy and Copter
3.5.2 is still out there
Still seems to be going relatively smoothly
One issue has come up that needs fixing
FPE if you use spline waypoints
Probably in there since 3.4.6
Optical flow initialisation issue
Enablement problems
Guided mode yaw support
Set_attitude yaw fields are supported in master
Will be back-ported
Question about Compass type mask
Needed for the qmc compass
Maybe a beta by early next week
MdB: NED fixes for the next version
Randy: yes!
Randy will be focusing in Pierre’s Rover work and APSync in next week

09:11am - Randy and Rover
Release candidate some time this week
Wheel encoder
New throttle/steering controllers
Thinking of putting wheel encoders in control algorithms before final rover release
Ensure wheels are actually turning
Going to add a ch7 to record cruise speed/cruise throttle
Need a calibration method for the wheel encoders
Little difficult to do setup at the moment
Need to provide counts-per-revolution
Tridge: Could hit yaw stick hard and did a 360 on spot?
Would work on skid-steer
Wheel encoders have a position
Pp: how about a pattern based on GPS?
A figure-8 pattern?

09:18am - Randy and Sebastian’s SafeRTL
Blog post from Sebastian later this week
In reasonable shape
Needs review
Randy made a few cosmetic changes
Possibly we could improve the efficiency
About 4k of memory
For 200 points
Maybe save 400 or 500 bytes
Should also be able to reduce CPU impact
Does sqrts when it doesn’t need to
Not currently part of failsafes
But should be

09:22am - tridge and compass improvement
Currently testing on Copter
Not really an issue on planes due to fly-forard
In-flight compass learning technique
Avoid need for compass calibration
For new SkyViper aircraft
Comes calibrated from factory
But say something gets magnetised
Or offsets lost
Avoid check-mag-field or compass-offsets-too-large
Do not refuse to arm
Arm and fly even if offsets are crazy
Even if field strengths are crazy
But do not allow a GPS mode until offsets learnt in flight
But users not flying in GPS mode often don’t yaw much!
Just tend to go right/left
Traditional techniques required yaw-360s to learn
New technique does not require yaw
But still gets x y and z
How do we take advantage of this in new vehicle?
Set a parameter?
Command-long to start it?
Maths of technique?
Uses world magnetic model tables
Uses your location
AP_Declination is extended to provide three numbers declination/inclination and expected field strength
Declination tables have been updated
Will create a python script which will update the tables automatically
Tries to get the yaw to within 5 degrees
72 vector3fs in RAM
One for each 5 degrees of yaw error
inclination/declination/yaw and field strength give you your offsets
So work out your yaw…
Try all 72 yaws
Keep track of the implied offsets would be for each ofthe 72 points
As vehicle is flying around
See which are self-consistent
If you roll right then a whole bunch will go bad
Correct yaw is the one that implies self-consistent offsets at multiple attitudes
A little roll or a little pitch is all that’s required to eliminate the bad candidates
Requires 7 degree attitude change to be a new sample
Converges to correct offsets to within 4 or 5 seconds
But doesn’t pass thresholds for 20 to 30 seconds
Needs GPS position
Rapid hand calibration instead of flying?
Pick it up and rotate it a little bit
The lumps-of-metal issue
Also requires GPS lock
Doesn’t ever get diagonals
No soft-iron effects
What about JC’s diagonal stuff?
It works well
For diagonals/offsets
But still requires compass dance
On SkyViper diagonals and off-diagonals are set in factory
As they’re the same on each frame
So again - how do you use this in master?
Only allowed to take off in non-GPS mode
After 30 seconds it will have converged and you could go into GPS mode
Planes can already take off without a compass, so no worries there
Could use it on Rovers
Picking Rover up and rolling it around would get it
Yawing is enough
Subs might be OK
Hard to get stuff in pitch/roll
But again, yawing is OK
Should we save COMPASS_INC?
Predicted results from tables are remarkably close to what we actually see
Motor interference?
Learning interference separately on SkyViper with per-motor calibration
Will probably work reasonably well without motor calibration
Change to AP_Arming so that if compass learning is enabled then arming is OK
There’s also the known-location calibration
If you know the magnetic field in a particular position you can have a one-button thing in the factor to do accels/per-motor calibration and compass
Back to “how do we use it?”
If it fails then tell the user
But user will have to take off and fly in a non-GPS mode
Don’t allow arming in GPS mode
SkyViper auto-switches to althold instead
Incremental calibrations are coming
Take EKF offsets and save them over time
Should we create a low-priority maths thread instead of using the IO thread?
Realtime FFT task!
This compass stuff
“Compute thread”?
One step lower priority than io thread
“Maths thread”
Maybe just go with priority instead?
“Lowpri” thread
The compass learning will be the default
Still need to to accel cal
But only single-axis
No need to set the parameter
FFT and dynamic filters?
Notch filter in use on the SkyVipter
80Hz 20Hz bw 15dB attenuation filter
Remove main frame vibration
IMU switching based on vibes?
Notchfiltervector3fparam contains the parameters
So you can easily reuse the notch filter
Leonard wants 1kHz PIDs with a notch filter
Betaflight have real-time ffts and notch filters and dynamic notch filters etc
It’s a good idea
We can learn from this
Filtering RC inputs?!
Interpolating RC inputs
32ms s.bus
Tridge: it’s 12ms (150Hz)
They move the sticks faster than that
Velocity-based boosting of movements
“Derivative kick”
Smooth sticks might still move PWM by 5
Due to frame-rate
Lights up the D-term
We filter the output of the D-term
Do we filter the input?
Filter input-gyro can take out input kick

10:05am - Issues
DMA bit-banging interface
Highly critical for flight
Coming out in next month or so
Sid’s been writing these
Sid wrote some of the code in 2013
“OK DMA hardware, send this buffer out to that pin”
Megabit speeds are entirely possible
Entirely possible to bog system down with this stuff
Generic control of serial information heading out of the PixHawk
Aux PWM timer is used
Choice of some of these functions or AUX
Chews up 4 timers
Leaves you with 2 PWM channels
Lack of DMA timers
Particular timers / particular pins
Individually controllable LEDs
Default comes out with a few strobes left-nav right-nav and status
Solo with 86 LEDs on it
JP: LEDs are cool, but that looks like the start of a D-Shot implementation - which is even cooler…
This doesn’t cover input, which d-shot allows
3-wire servo cable interface
Digital output with a 4-bit crc
Could also do normal uart style communications
Feedback rpm/voltage
Firmware updates if you have feedback
Second stage is files from SD card
In PX4 Firmware layer
Adds more functionality in
Need to move this up into the ArduPilot tree
Tridge will be chatting with tridge on this
Including a GUI to make the patterns
AP_Notify will get stuff in it
JP: how different from ws2812 or blinkM?
Totally different
Not timing critical
String of 200
Each LED is 60mA
That’s 12A….
86 is too much for Solo’s power system
Mission-based setting of patterns…

10:25am - statics in functions
Tridge isn’t in favour
Stylistic thing
Static variables will die
10:30am - URUS removal
PR coming
Can always come back in when there’s code to back up its presence

10:31am - InterDrone update
Vote on ArduPilot branded merchandise
Anybody going there?
8 people are listed as going
Olivier can’t make it
Funding committee approved funds
And the current team and plan as well
Too slow to get stuff from China
Ordering from the US
A little more expensive
But save on shipping
Alex has been working on an ArduPilot promotion video
Hopefully available at InterDrone
How to display?
TV or projection?
$500 to hire
Craig will bring a 24” monitor
How to pay for things?
Reimbursements are problematic in the long term
Renting things is problematic
E.g. t-shirts
Get an account
Design a logo
Get it right
Like any other internet purchase
CC payment
How is payment reimbursed for this online purchase?
Running out of time
Having to expedite things is expensive

10:45am - funding committee
Bill was expecting proposals to be emailed to funding committee only
That’s not how things were set up
Posted to discuss
Bill has now set things up so he gets and email
Funding mailing list was to archive discussions of funding committee
Proposals are public
Discussions are private
E.g. a member would say “I want to say yes to this”
And then the others would agree/disagree
Several things have already been funded via this process
But still well behind
Jaime is starting to look through the proposals
He’ll be sending emails to the funding committee mailing list
FF: Don’t forget that I, as the SPI liasion, need to know when things are approved. So writing approved in the forum or sending me an e-mail is needed
Could just subscribe ardupilot.devel (SPI contact) to the funding committee list
Information from SPI is laggy
Aiming for momthly reports
But behind ATM
We track ourselves to some degree to make sure we don’t exceed budget
CC questions from earlier?
We have one we use for hosting
username/password of DO was given to SPI and they paid the bill
So not really applicable for buying merchandise etc
So need to go with the reimbursements path
No high burden of proof
Approval email and a receipt will be fine
We are allowed to sell merchandise
Nothing in non-profit rules about it
Project decision
Not allowed
Buying member of dev-team hardware
If they only use it for development, no problem
Any other use, big problem
Two-laptop pain!
OK for buying stay-at-home-servers
SPI is non-profit for Debian project
Debian is a huge project
Lots of funds
Separate fund
They have their own CC
And paypal account
They run debconfs off CC
rentals/merchandise etc
So CC can happen
But Debian do 100s of thousands of dollars
And hire accountant to audit conference
Different scale than ArduPilot
SPI is only a 5% overhead
Which can’t pay for all of the stuff Debian get
Foreign currency stuff would require getting an exchange rate etc
PayPal is very convenient for reimbursements
Trick is to get the email right the first time
So include all information in mail to liasion
Date of purchase
In $US
Include calculation from e.g. Euros to $US
Perhaps a link to or similar
Banking details
Link to approval process
Batching stuff up would be nice
SPI have “accounting parties” to get rid of backlog
So reimbursements can be sporadic
In process of hiring a ÂĽ-time person to help treasurer with reimbursement requests

11:14am - APSync release on its way
More than half the functionality
Request that the image we kept under 4GB
So it can be flashed onto the compute module

1 Like

Tridge has gone Meta!!