Developer Conference Update
Issues & Pull Requests
Antenna Tracker
Plane
Copter
Rover
Developer Conference Update
Issues & Pull Requests
Antenna Tracker
Plane
Copter
Rover
Attendee count (max): 16
UTC2304 - Conference
Very successful, a lot of fun
Luis is working on the videos
Lost audio on some lightning talks
Post-conference fun, too
Many thanks to Grant and James and Daryl for bbqs and the like
~45 attendees on Saturday/Sunday
Leonard’s ArduKid t-shirts
Night flying was good
Demos on Thursdays
Whole host of problems on new boat
Forgot to plug hole in back of boat
Badly tuned
Got most of it sorted
Got things sorted on subsequent visits
Iain / blurobotics was great!
Scripting was good
Long talk
Demo
Aion Robotics and Peter’s rover
hotter/colder game
Swift QuadPlane was awesome
Very refined
Flies beautifully
Attention to detail
Demonstrated new sort of landing
Landing into the wind
Big circles required
Tandem-heli / Rover
didn’t fly
Heli + Rover + fire extinguisher
Fire-fighting robot
Videos in next day or so
UTC2314 - https://github.com/ArduPilot/ardupilot/pull/10888
UTC2314 - https://github.com/ArduPilot/ardupilot/pull/10882
UTC2326 - https://github.com/ArduPilot/ardupilot/pull/10865
Merged
Header cleanups
UTC2328 - https://github.com/ArduPilot/ardupilot/pull/10854
Only used by attitudes_consistent
And get secondary quaternion
Prearm checks were failing for Mark on tailsitter
Will change logging of quaternion
May affect Paul
Could localise to attitudes-consistent to avoid logging changes
Needs Paul to OK it
UTC2332 - https://github.com/ArduPilot/ardupilot/pull/10828
Makes it easier to test/fly body-frame roll option
Needs a rebase
Two different control modes
If you are flying multi then you expect roll to operate in earth frame for Copter
Body-frame-yaw if pointing vertically in tailsitter
_M is not good
Can go in after a rebase
UTC2339 - https://github.com/ArduPilot/ardupilot/pull/10814
Q_trim_pitch was briefly broken
Plane: VTOL Pitch trim bug fix for non tailsitters
Does a transpose when first setting trim rather than at runtime
Fixes mavlink
UTC2341 - https://github.com/ArduPilot/ardupilot/pull/10802
Merged!
We really should broaden compiler support
UTC2343 - https://github.com/ArduPilot/ardupilot/pull/10781
No objections on devcall
Peter to work with Pierre on getting this in
UTC2350 - https://github.com/ArduPilot/ardupilot/pull/10720/files
Randy likes it
Follow-up PR
Need to add checks for heli
Peter to add #if guards around check and can then merge it
UTC2359 - crow flaps
UTC0000 - https://github.com/ArduPilot/ardupilot/pull/10570
Merged
Can sort problems out
UTC0005 - https://github.com/ArduPilot/ardupilot/pull/10457
Discussions on why this is failing in CI
Randy to test on his machine
UTC0006 - https://github.com/ArduPilot/ardupilot/pull/9716/files
UTC0009 - https://github.com/ArduPilot/ardupilot/pull/9017
UTC0015 - tracker release
Peter Hall to split fix-scan mode out
Start building Tracker for all boards
UTC0022 - Plane update
UTC0023 - Copter update
Number of people asking cxof optical flow sensor available on cheaper boards
Openmv as optical flow camera is a thing
Beta will come along sometime….
UTC0024 - dronekit and ArduPilot
Bring it under umbrella of ArduPilot
Anything not on chat?
Discussion of how transfer would happen
Vote required
My apologies for the rambling nature of this post. I’m going to get another coffee. OK, my 2c on the dronekit-android and dronekit-python thing. I can really only speak for dronekit-python here. These are APIs meant to abstract mavlink into a vehicle model which a Python/java programmer can use to manipulate the vehicle. That abstraction is important. A lot of the most recent contributions to dronekit-python have come from PX4 users - and I have bounced patches that moved the API to be ArduPilot-specific. There’s been NO talk in here of talking to the relevant communities (such as they are) to see what they think of the concept of ArduPilot taking over these repositories? Will non-ArduPilot users drop dronekit-python, believing they’ll get screwed over? We just had a conference where we discussed what we should take on or drop as a project - bizarrely that didn’t even cover taking over dronekit-python! Why would be ever drop anything as a project if we’re willing to pick up a project and then apparently be happy to do absolutely nothing with it - where the act of taking it might actively harm that project? Promises of future support for the project where there has been none also count for very little in my eyes when making a decision like this; nobody has really associated dronekit with 3DR for a long time AFAICS.
Luis should we be stretching ourselves like this?
Won’t it look stale?
Randy: do we have the resources in the devteam to maintain this?
Luis: does it make sense for ArduPilot to maintain DroneKit?
Resourcing issue
Who is going to maintain it?
Kelly has his own fork
This is a serious impediment to take this on
Don’t just try to volunteer Peter’s time
Randy: Need to decide other issues BEFORE we take on the project
Is this aligned with ArduPilot as a project
Randy thinks “yes!”
Why move things under the ardupilot project rather than just take dronekit on?
This sort of thing happened before
Randy we do want an SDK and dronekit is the closest thing to it
Luis: Why did PX4 give up on it?
Any vote has to cover these points
E.g. “should we take this on with no resources allocated?”
E.g. “should we take this on only if resources are allocated?”
UTC0045 - first video of conference will be up in a few minutes