UAVCAN
MAVlink
AP_Sync
Copter
Plane
ArduSoar Merge
Prop-hanging
General code
Variable parameter trees
Math
Home
battery monitor
Rover
Sub
firmware.ardusub: link to sub firmwares
GSOC
Attendee count (max): 29
10:02am - discussion of AP_Sync/ArduSync naming
Some confusions cleared up about what this is;
We should possibly consider a different name as Tom was expecting to see a library called AP_Sync!
10:03am - Eugene and UAVcan
https://github.com/ArduPilot/ardupilot/pull/5436
Middle of the night for Eugene!
Many questions on PR
Tridge has looked through
Eugene would like them answered in PR
But important questions right now
Thread architecture
E.g. Do_cyclic spin_once on autopilot’s node
Does it get called by AP_Scheduler or on its own thread?
On own thread would seem preferable, so why via scheduler?
Should move to thread-per-bus
Or thread-per-CAN-interface
Or thread-for-CAN
This would have advantages in terms of blocking issues
We’ll start off by doing one thread for all interfaces
Later we should move to thread-per-bus
Threads would go inside HAL layer but call out to AP_UAVCan
Need to watch threading in GCS_MAVLink for thread-safety
Log_Write ports
Printf works
But isn’t free; good fraction of a millisecond
UAVcan builds for tridge, that’s a good start
Need device drivers
AP_GPS_UAVCAN is obvious first start
Will use AP_UAVCAN to get messages from GPS
Can’t have both old UAVCAN and new UAVCAN in at the same time, so switchover is required, and most things will have to work when we do the switch
There are currently lots and lots of defines for registers
Not nice, but shouldn’t hold things up
Micros64?
Monotonic time counter, time since boot in ms
Safe to use as a monotonic time
Send_statustext
Use printf for now
NuttX calls are OK from within HAL_PX4, but not within libuavcan
Any missing calls should be made into calls on the HAL
FreeRTOS?
Not dropping NuttX any time soon!
Many parallel efforts have been made to move to FreeRTOS
CAN parameters
Bitrates should probably be a new parameter
E.g. BRD_CAN
Hardcode to 1MB for bitrate ATM
Node-id will be another parameter
0 will be automatic node
Delay for drivers to initialise
Currently 1 second
Libuavcan as a separate library?
Yes!
New group of settings for CAN
Define within libuavcan but put within the BRD namespace
For GPS, interface will be provided for GPS messages to be read out by other libraries
GPS will get updated when a message arrives
Something like the register callbacks for i2c and spi
Register a callback which will get called
hal.can.register_callback(…)
There are periodic callbacks on i2c
This gives things the ability to send messages to the device
MOT_PWM_TYPE=CAN
Hal.rcout could send CAN messages
Creating a new task that blocks and never returns
Create new threads in the HAL layer
Tridge and Eugene will talk further later today
Tridge is delighted he has a board running without PX4Firmware!
200-300 messages/second
Will need to do better than that for ESCs
Will need to work on threading and buffer sizes etc
10:35am - pull requests on mavlink from amilcar
Wants enum attributes everywhere (PR #25)
https://github.com/ArduPilot/mavlink/pull/26
https://github.com/ArduPilot/pymavlink/pull/47
This one should actually probably be applied and Don’s work rebased on it
Adding extra parameters in the schema is harmless, so we should probably bring these in
Units attribute?
Not currently done for other flight controllers
No need to add it for every autopilot
Really just ardupilot.xml and common.xml
Just don’t make the units mandatory
https://github.com/ArduPilot/mavlink/commit/e32b1ffcb269916bd743ae25cf6650a63d8dcde1
Reformatting has previously been done but ordering of attributes was done fixed
We can reorder the ardupilot ones, but probably not the common ones
10:49am - Copter update with Randy
rc2 out late this week
Display fixed
Confirmation from Paul that EKF failsafe problems weren’t problems with code
We definitely have some issues
Randy’s a touch behind because of his travels, but back on board now!
Something wrong with mount
Board may stop working if you flip a vehicle upside-down with a mount on it!
Display not working on PixHawk2
Rc outputs 9-14 may not be working
There will be an -rc3
Should we include Paul’s GPS mixing PR?
Smoothing when shifting between GPSs
There’s a parameter to enable/disable
Will look for input further on this, no resolution during meeting
Lots of support from Francisco taking up the slack while Randy’s been off
10:57am - extending EKF for visual odometry
Z-camera data into the EKF
New message will be required to get data from CC to EKF
Precision-landing using cameras into AP_Sync!
11:00am - Plane and ArduSoar
https://github.com/ArduPilot/ardupilot/pull/5737
This crashes tridge’s firefox….
Probably a sign that it should merged
Great progress on this one
Matrixmath is the holdup here
Commit history needs cleaning up
A few build issues
Testing in XPlane
Neat set of patches once everything was squashed together
Matrix-math is templated based
Current maths is a little wrong
Will need to be fixed before this goes in
Merge should be in before next week
Will move soaring to be part of cruise rather than fbwb
If it loses the thermal then it will go into RTL
Cruise will retain old heading when you leave the thermal
Transmitter switch for soaring support
SOAR_ENABLE enabled extra soaring features
Work with any fixed-wing aircraft
Including quadplane
Somewhat unlikely
11:05am - variable parameter trees
https://github.com/tridge/ardupilot/commits/pr-param-conditional
All parameter trees are currently static-const
Defined at compile time
Can’t swap out parameter trees based on a parameter
There’s a very long-standing PR which required a new build type because of this issue
Chinook-style helicopters
This PR allows you to have a constant-pointer-to-a-pointer for a var-info
Could move parameters into backends for drivers
Does it make it more readable?
We’ve been able to dynamically load objects for a while
e.g. motor objects for quadplane
But they had to be the same object
Automatic refetch issues
Existing problem with enable parameters
This allows Conditional parameters
This is precursor work, conditional parameters not done yet
Valgrind is currently happy with this work
Probably need a mavlink message to notify of parameter range changes
11:12am - training system for prop-hang
You can specify a tailsitter mask which specifies your output control axes
Spring-loaded switch on the transmitter
When you hold a switch then you get control of the axes
Otherwise ArduPilot will hover the plane for you
Tridge would like more assistance systems for people learning to fly manually
Harrier
Knife-edge
Rolling loops
Discussing with Mark
AP is doing good hovers now - better than at least one pilot!
Works in RealFlight with many vehicles
Including ICE
Seems rapid control isn’t really required
11:18am - double-precision maths
As new hardware comes out, we should be able to take advantage of it
Position accuracy
Testing is the problem - if you fly OK on Disco then it will work OK on STM32
Need a plan so we can continue to test cross-platform
https://github.com/ArduPilot/ardupilot/issues/5775
If we were to use double-precision then we would need to test separately on both
RTK GPS drivers already do double-precision
Very few places we have to do it
We should be able to do both single and double-precision testing in SITL
Would probably still want to have single precision
E.g. Bebop
If Randy flies 32-bit on this then he could have confidence on STM32
Randy’s wondering whether any problems are actually being caused by our 32-bit code?
The GPS problems were probably more float-related than integer-size-related
Offset-from-origin could be a problem if you ever manage to get one on a different continent
Maybe indoor-vs-outdoor?
Should we aim for low-hanging fruit?
Closely-coupled GPS EKF
Where it takes the RAW-capable GPS and coupling them in with the gyros and compasses
Moves the filtering out of the GPS unit into the CPU
Would definitely require double-precision
Would only build that version of the EKF if you’re building for F7 or Linux
Would mean AHRS_EKF_TYPE to 5 would only be available on e.g. linux
Feeling that we’re not taking advantage of RTK GPS enough
Integer waypoints will make this much better
MP already does
MAVProxy should
QGC - unknown
1.1cm is worst-case worldwide
There are other bits which make our estimations worse than 1cm
Tom’s sold that it doesn’t make sense to generally move to double-precision
But there are still places where it does make sense
He’ll make a note on the issue and close it
11:31am - new label - DevCallTopic
For e.g. Craig to look at before the meeting
11:32am - follow for relative position for AHRS
home should be the ahrs position not the GPS position!
Tridge is convinced
https://github.com/ArduPilot/ardupilot/pull/5782
Brings Plane and Rover closer to Copter
merged!
11:36am - PR count
It’s up again!
Was at 80
11:37am - battery estimate with Jacob
Batteries being destroyed because users are getting remaining-capacity messages as full on boot
Provide a better guess for capacity remaining
https://github.com/ArduPilot/ardupilot/issues/1434
More parameters?
for cell count
Maybe add a battery_type
LiFes are also common on fixed wings
Different mapping from voltage to capacity
Maybe a BATT_CHEM option
Possibly instead go for max-voltage and a chemistry?
Idle current may be significant
Do we assume linear?
If we want % to be accurate we need a curve
Some aircraft already do mapping between voltage and capacity
There’s a little table in AP_BattMonitor_BeBop
Solo also provides and accurate capacity
Pre-arm check for min-voltage already exists
Copter has resistance calculation, but they’re in the wrong spot
Relaxation - how do we handle that?
Estimating at boot is insufficient for calculating capacity (flight batteries may not be present at boot)
Maybe at 1Hz we should update the guesstimate
Moves to being a current monitor when armed
Currently a bug in Plane which allows arming with low battery
Resistance or C-rating?
Maybe just a whole bunch of tables like:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_BattMonitor/AP_BattMonitor_Bebop.cpp#L47
Could do one of these as parameters as a half-way-house
12:08am - rovers and reverse
Grant found a bug where if you were driving in reverse then it would continue to drive in reverse when you flicked into auto
Grant is adding a fix
Failsafe crash checker is on by default ATM
Will be disabled by default in the future by default (like we do elsewhere in ArduPilot)
12:11am - Jacob and linking to sub firmwares
Sub vehicle has been added to autotest
Sub firmwares are now built as part of that
“Dive_ardusub.py”
Want a link on frontpage of firmware.ardupilot.org for sub firmwares
Easy to do - its in the git repo
Image will be required
12:15am - GSOC with Olivier
We’ve been accepted!
3-week period to advertise for students
More advertising the better the selectio nwill be
https://summerofcode.withgoogle.com/organizations/
Past April 3rd formal selection process starts
Students formally apply
AP decides who they want to select
This would be a good time to update http://ardupilot.org/dev/docs/gsoc-ideas-list.html
Add what-you-need-to-do-to-get-selected bits
Who would volunteer to be a mentor?
Where possible the mentoring should be done in a public forum
E.g. the GSOC gitter channel https://gitter.im/ArduPilot/GSoC
https://groups.google.com/forum/#!forum/ardupilot-gsoc
Discourse thread?
Can take a lot of time
Very student-dependent
Still worthwhile!
Having shared-account and remote access to hardware is really important
How many students do we get?
As many as we want?!
Already have had 3 or 4 pop into the GSOC gitter channel
Google will limit the numbers, but they don’t tell you how many
We’ll get one
2 or 3 may get funded
Comes down to person inside google
Last ime only one got funded by google
But 2 others got funded from outside google
Possibly a partner might sponsor?
Or ArduPilot’s own development fund?
Students should made aware it is competitive
Analysing logs on remote web-server?
Peter had concern that it wasn’t really drone-related
Parse dataflash logs in javascript?
So execution can happen entirely in browser
Tridge thinks anything relevant to or of benefit to the ArduPilot project
Just need to be clear that it may not involve a lot of drone-specific physical stuff
Tridge says students should apply to the Ardupilot funding committee if they need hardware
Also hardware people are interested in helping out if the hardware would be worked with
E.g. BeagleBoneBlue
Randy is volunteering as a mentor
Volunteering as a mentor now means that in principle of the right student comes along I would be a mentor
Not a full commitment
depends on the student and project
Addendum: compass orientation
Northern hemisphere when the compass is level you expect z to be positive
Southern hemisphere when the compass is level you expect z to be negative
If you are in the northern hemisphere and z is positive and you pitch nose down
X should become larger because x goes out the nose
If you are in the southern hemisphere and z is negative and you pitch nose down
X should become smaller because x goes out the nose
If you roll vehicle to the right in northern hemisphere y should get larger
If you roll vehicle to the right in southern hemisphere y should get smaller