Copter
- copter-3.5.3 release progress
Plane
- Plane 3.8.2 (includes climb rate fixes, plus some other minor changes)
AP_SYNC
Issues & Pull requests
GSOC
japan-innovation-challenge update
total silence on UAVCAN for months 
maybe this could get some attention: https://github.com/ArduPilot/ardupilot/issues/6801
Attendee count (max): 25
09:04 - Randy and Copter
3.5.3rc1 preparations have begun
Tridge is going to help out with compass stuff
Thursday arvo, maybe
Hopefully get this out late this week
A few issues pulling in the SBF fixes
Can’t get MdB’s increase-message-size patch in
Might just change the constant 128 to 256
There’s also a delay period which could be removed
Could also bring in full changes from master to avoid the conflict in question
Remove reference to non-existent structure
Don’t expect a release for at least a weekend + a few days
So maybe earlier next week
Don’t fly Septentrino on 3.5 at this point!
Septentrino have been in touch
We really should have nudged them ourselves
Perhaps we should do a 3.5.3 and then a follow-up 3.5.4
3.5.3 out before next dev call, then, hopefully
SmartRTL was renamed and merged
Only in master
3.6 feature
Japan innovation challenge update
Will take up a chunk of Randy’s time in the next little while
Way behind schedule!
have vehicles and cameras
Running APSync
And CUAV
Winch support
SimpleBGCS support
For 3-axis gimbals
A couple of PRs to pull in to fix support which Randy needs
09:17am - tridge and Plane
3.8.2 went out yesterday
Mainly for SBF bug
Still some configuration issues outstanding with SBF
3.8.2 will work quie acceptable but will be better in future
A few feature requests
Low risk changes
Leonard found a bug where quadplanes would descend too quickly in qrtl
Tridge reproduced it in SITL and it fell out after that
The rule was “Don’t go from fixed-wing to qloiter”
Easy to break wings off this way
We now ramp the pitch to avoid stressing the airframe
Qgroundcontrol support with Don
Adding support for Joystick
And guided mode
For use on $80,000 quadplanes….
Qgroundcontrol’s enable/disable stuff means that a lot of our capabilities aren’t being shown
Need to watch out for this!
09:26 - Peter and APSync
RPi and TX1 images up which have support for APWeb are up
Edison to follow later this week
Wiki changes to move APSync up to the same level as the vehicles
Apparently the Wiki is out-of-date
Randy will look at this
Need to improve video
Peter wants to revisit BeagleBoneBlue
Tridge: Strategy for IMUS on i2c could change
Maybe stop pulling from IMU at 1kHz to something lower
400 or 800
Maybe change strategy for bringing in data to reduce interrupt count
C920 is a camera we should definitely support
09:37 - Paul and GPS2
Two requirements
When analyzing data from logs it is important to know physically which is GPS1 and GPS2
Storing position of GPS antennas against GPS numbers!
Plugging things in can change order of GPS units!
Michael says GPS2 will always be GPS2…
Unless you change parameters e.g. change SERIAL3 to non-GPS may mean SERIAL4 may become GPS
We’ve solved the problem in a few different ways
Compass has an arming check which checks the device IDs
Bus id and device id and the device type etc
Doesn’t really work for a GPS
No calibration phase
Could get an ID from the compass driver
“Primary” method to bless a device as the first
E.g. baro
Doesn’t scale
Doesn’t let you order things
Blending….
Incorrect offsets
Solution needs to be scalable to different device types
Uavcan
We’re bring back SERIAL_GPS and SERIAL_GPS2
You can set all to GPS
This doesn’t address the UAVCan instances!
Enumeration ordering is essentially random
FF: Maybe we should be nominating serial ports in devices?
GPS_SERIALPORT
GPS2_SERIALPORT
Maybe GPS busid?
Like compass ID
GPS_BUSID1
GPS2_BUSID
Serial port would need to be set to GPS
The GPS library would then nominate the serial port it wants with a BUSID
E.g. 2 for SERIAL2 (which would have to have the GPS protocol nominated in the serial parameters)
MdB is looking forward to GPS autodetection dying
Tridge will be looking at doing a BUSID on the GPS object
Plugging in multiple devices will work
Blend only works from same manufacturer
And try to stay with same generation!
Results will be screwy if you try to blend different compasses
Maybe we should enforce them to be the same?
Or at least a warning…
But sometimes you might have the same device across different access mechanisms….
Reported accuracies
In particular if they use different metrics for them
Will get rather strange results
MdB: u-Blox and SBF use different accuracies
09:57am - https://github.com/ArduPilot/ardupilot/issues/6724
Define motor ramp curve for Copter
More gentle ramp up of throttle
MOT_SPOOL_TIME documentation is inaccurate
Says 0 to minimum
Implementation actually ramps from 0-min then min-full
See graph in PR
Tridge would like to split the parameter to have one value for each stage
Problematic on quadplanes as-is
MOT_SPOOL_TIME_H
New parameter giving min-to-max spool time
10:06am - https://github.com/ArduPilot/ardupilot/pull/6893
FF has issues with the resolution on this…
Moving home and origin
OF and no GPS you can get pretty accurate local position
But you won’t get messages because we’re comparing against one rather than the other
Origin migration enabled or disabled by default?
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF2/AP_NavEKF2.cpp#L551
Controls correction of locations, buth origin and home
Add a mavlink2 extension to add the origin so we publish both home and origin over mavlink?
Input controller for Copter does a correction
MdB would rather not publish home and expose things as home-based
FF: Home is movable
FF Origin is supposed to be still
Should origin ever we exposed?
EKF origin is not always set
If you don’t have an absolute position it is zero
Can do loiter with a local lock without a origin
FF suggests we should send the local position vs origin not vs home
MdB you must change the input version at the same time
Who then does the height corrections?
Tridge points out this could break people’s working controllers who are expecting something at the moment
Publishing extra stuff might be required
New message or mavlink2 extensions to LOCAL_POSITION
We changed the way things work (origin vs home)
The ticket says it shouldn’t have been changed
And yes, that is a problem
Ekf origin will only change in altitude
Home can shift arbitrarily
We should revisit this at some stage
Relative position is relative to what?
Home?
Origin?
Tridge: Publish everything!
Publish both origin and home
And our relative position to both
MdB: that needs to be stream rate limited… IE 10Hz eats a ridiculous amount of bandwidth
Set home, bring all numbers to zero
Origin might be a long way away
Floats relative to origin will become inaccurate
We’d need more frames on the input
Frame-relative-to-origin
Tridge thinks the current one should be relative-to-home?
Will need to check lat/non/alt=0/0/0 if we use mavlink2
Luis: let’s postpone to get input on the ROS guys
3.4 we were vs origin
3.5 we’re vs home
Randy thinks we should revert
This will give us a consistency between in/out (mdB)
We should fix input side if we revert
Will discuss again next week with new PR and stuff
10:34am - Olivier and GSoC
Quick summary
Officially over for students, mentors and admins
Except for the party
Jaime will be going
Google headquarters
Couple of days
Breakfast / dinner….
Deadline was last week for mentors to get evals in
Three brilliantly passed
One did not
Very successful program for ArduPilot
External dependencies sunk one project
Along with lacking time from student
We’ve got lots of great stuff!
Admins and mentors have held a meeting to record lessons learnt
We did well in the selection
Time commitments are always going to be a big thing
Big thanks to Olivier for doing the admin work
And the mentors
And google
The successful students worked very hard and it worked out for them, we think
10:40am - Interdrone Report
After-hours session went well (and late!)
Panel took lots of questions
Craig spoke with lots of people
Lots of companies using ArduPilot
And they prefer to say they’ve done their own thing
We suggest they get into the partner program
Still have the problem:
“What do you fly?”
“PixHawk”
And they don’t know more
Lots of people hiding the use of ArduPilot
Using UGCS in place of MP
But many starting to proudly announce the use of ArduPilot
Thanks to Randy on the work on that program
We’re making a lot of progress
HiTec have a nice plane coming out with AP on it
They’d like help getting MP changes back upstream
Need to spruik the Open_source nature
It’s an advantage
One vendor was saying ”propriety” was one of their advantages!
MicroPilot appears to be stagnating
Their supported feature set is actually OK
They came out with an SDK recently
Embed within your own GCS
Massive HW boards
Kestrel is within distance of MicroPilot
Cloudcap/Picolo apparently having some issues
FlytOS
They’re now suggesting people buy their hardware and if they want a CC program written they could do that for you
ArduPilot on $110,000 planes…
And on weird tilt/quad
Coriolis?
Sprite
Coaxial code?!
Looked cool
Dubious flight-time claims
ARM would like to help out with support and stuff
Jeff got swamped by military people
The emerging technologies guys
He considered the booth very successful based on
SkyRocket
Need to use this as a success story and push it at startups
Working with the ArduPilot team
Amazing to bring a product to market this quickly
Interest just for training purposes
Maybe split hw/sw into different booths next time?
Should worry about partners who are directly competing
Currently we’re all ardupilot-first…
Marketing team will be making a report on InterDrone
Lots of high-end stuff at InterDrone this year
Not much in the way of e.g. FPV
FBI had a booth
Counterintelligence at trade shows
US people: Sort out your export stuff!