Dec Top Contribution
Copter
Plane
General
Website
10:03am: Peter won “contribution of the month”
10:03am: Randy and Copter updates
Starting beta testing for 3.5
The following PRs should come in before 3.5beta is released: https://github.com/ArduPilot/ardupilot/pulls?q=is%3Aopen+is%3Apr+milestone%3A"AC+3.5.0"
Help in reviewing these PRs would really be appreciated
Object avoidance
https://www.youtube.com/watch?v=qk_hEtRASqg
Forward-facing 3D camera
Distance sensor messages go to ArduPilot
AP_Proximity_MAV takes these and creates obstacles
Z-camera gives 640x480xdepth
Tested in AltHold as well as Loiter
Vehicle attitude is a problem
OpenKAI doesn’t use lean angles from vehicle ATM
You can simply lose sight of the obstacle if you lean too much
May need to form up a “world” instead (occupancy grid or point-cloud or…)
Google Cartographer?
ROS?
Running on something like the Intel Aero might allow passing world-information back and forth convenient
Running something on STM32 might be possible in a separate thread
Heterogeneous computing may also be an option (running code either on companion computer or on autopilot)
Develop code in ardupilot repo in a subdirectory to keep code in sync
Question as to what the goal is; the map is a means to an end, not an end to itself
What sort of path planning is going to be used?
ATM we’re just trying to avoid things, not navigate
Current behaviour is to slide around obstacles
Planning on adding a “sticky/slippery” parameter
Sliding can have you slide sideways into other obstacles
360-vision will negate this issue
10:26am: AP_Arming
Discussion of how to handle parameters which are common to some vehicles, AP_Arming’s ARMING_REQUIRE flag in particular
Tridge suggests annotations in the variable declaration specifying which vehicles it applies to
He points out that other annotations could hide tri-copter parameters when not applicable
Bit flags?
Function pointer?
Tricopter used to include multicopter parameter a a subgroupinfo!
Tricky to fix
FF is concerned about the fact we went down the subclassing route and this seems to be going back the other way
Tridge likes having the subclasses, but not the parameters
Tridge says we’ll be adding another tool to the toolbox NOT taking away the subclass technique if it is applicable
We’ll be going the #ifdef route for the time being and come back and add the flags later
10:50am: rcin/rcou split
We’ll be going with the servo-naming
Motor reordering can be done arbitrarily using the RCn_FUNCTION parameters
Can also then use channels for something else (e.g. plane rudder channels)
10:55am: naming issues
Need better paths for the prec-compiled firmwares
question about file extensions
Firmware.ardupilot.org
Stay away from hardware names (says PR)
.bin isn’t a great name
.dfl?
Lots of people already use .bin, leave it!
Will use symlinks or similar to provide a transition
11:01am: tridge and tailsitters
There are different sorts
Bicopter or coaxial copter which also provides thrust for forward movement
XFrame (no control surfaces)
https://pixhawk.org/platforms/vtol/tbs_caipirinha_vtol
https://www.youtube.com/watch?v=r3bopGTGaXk
What’s required for that?
Get it working in Copter
Get it working in Plane
AHRS wants “up” to be different depending on whether we’re in quad-copter mode or plane-mode
Multiple views?
Can’t just tell AHRS to rotate through 90 as you go through a transition
All surfaces want to be contributing
What do you want the GCS to see? Is the horizon shown when you’re level as a plane or level as a quadcopter?
Should there be an intermediate mode?
11:17am: generic mixer
Mixer table
Like PX4 mixer but much more flexible
Base it on OpenTX mixer setup
Like on Tarranis
Channels, virtual channels, additions, multiplies, proportions
Where do we Store it?
Probably not a parameter
Probably in StorageManager
Steal from waypoints, perhaps
Variable length record size for waypoints
Insert and delete would be a problem!
Could be on SD card in the short term
Could also be baked into the image like parameters can be
Could simple mixers be stored in Flash on the IO processor?
Probably, there’s enough space, but what are the sector sizes?
really fast recovery for in-flight reboots
There’s battery-backed RAM available for in-flight reboots; could checksum the RAM to see if it is viable (20kB, too small to be useful ATM)
E.g. quadcopter without different arm lengths
Probably a few hundred bytes for this sort of thing
Will retain ability to use IO processor
11:32 MdB and AP_Landing
Large chunks of code moved from Plane into this library
Support for other landing types
deepstall
A few bugs found, but looking good
Review requested
Tridge says he needs to review it
11:34 Improving units in GCS by fixing the mavlink XML
https://github.com/mavlink/mavlink/pull/623
Amilcarlucas
Less extensive than Don’s patch
Need to avoid Unicode characters
Making mavlink machine-readable, extracting units
Add bitmask to XML
Enums will stay
Language bindings will all have to work
Enumerations are used to indicate bits in bitmasks atm
Point made that mavlink is additive, we can’t really remove stuff
People can continue to use the enums
Will probably change to add an attribute indicating how the variable should be displayed instead
E.g. “bitmask”
E.g. “hex”
E.g. “radio”
11:56 AP_Sync update
Edison should be up this-arvo
RPi tomorrow
11:57: Francisco and commit rules
Indentation rules etc
Tridge thinks we don’t really need strict enforcement
astyle is the reference
Decision was made on enforcing case-statement format