- mavlink v2.0 in PX4/Firmware (16d67ed1): https://github.com/mavlink/c_library_v2/commit/f5c0ba684659fbc6c6c5f8777bd30e0b3c32fdef
    - mavlink v2.0 current upstream: https://github.com/mavlink/c_library_v2/commit/e550f4124bc331848aad3d691b27ec941a94c1e5
    - Changes: https://github.com/mavlink/c_library_v2/compare/f5c0ba684659fbc6c6c5f8777bd30e0b3c32fdef...e550f4124bc331848aad3d691b27ec941a94c1e5

    e550f41 2018-06-29 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/9e9398d5d1d8d1eab689086b73b1258b595969bb
4fae56b 2018-06-27 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/174fc3aad7ce26be66979051261bfd1e5e2dde1e

* frsky_telemetry added support for hw flow control com port and minor improvements

* DTYPE tested OK. Return 0 for unix compatibility, whitespace removed. Full test start - status- stop - start -status OK

The MissionManager handles the MAVLINK_MSG_ID_MISSION_SET_CURRENT command which should also be supported for SatCom.

Uses a relaxed yaw innovation check threshold for fixed wing vehicle that can recover from larger yaw errors after takeoff.
Replaces the peak hold with decay filtering applied to the magnetic yaw innovations with a conventional lowpass filter. This prevents mag heading innovation transients caused by preflight handling from failing the check, but catches persistent errors. Sign swapping of innovations due to angle wrapping is not a problem due to the way that innovations are calculated inside the EKF, so a simple LPF sufficient.

The calibration warning was only used in the ESC calibration and in all
cases it actually meant that the calibration failed. In order to keep
the API as small as possible, I've deprecated the warning string and
converted the warning messages to failed messages.

This fixes a problem where the pyserial write call gets stuck.
It happens on a specific Fedora 28 system with internal USB ports as
well as USB hubs.
It is not clear why the problem is resolved but it is clearly
reproducible that with a timeout of 0, the write can get stuck and with
a timeout > 0 it works every time.

The exception added as part of this commit makes sense but has never
been triggered in my testing.

    - sitl_gazebo in PX4/Firmware (18abeb11): https://github.com/PX4/sitl_gazebo/commit/3c7d18d0a52657106a3a7190c54006ed6b442071
    - sitl_gazebo current upstream: https://github.com/PX4/sitl_gazebo/commit/fcee53fc4c6ef734204fd74eeed2db5b767027ad
    - Changes: https://github.com/PX4/sitl_gazebo/compare/3c7d18d0a52657106a3a7190c54006ed6b442071...fcee53fc4c6ef734204fd74eeed2db5b767027ad

    fcee53f 2018-06-22 TSC21 - vision: by default, do not send ODOMETRY Mavlink msgs

NuttX:
 - https://github.com/PX4-NuttX/nuttx/tree/px4_firmware_nuttx-7.22+
 - https://github.com/PX4-NuttX/nuttx/commit/d5c12b24fa5349791220ce44a46b96f345ec77c1

Changes from PX4-NuttX/nuttx (https://github.com/PX4-NuttX/nuttx/commit/f57752b6f16f54bd50188024475657c6a7a1604c) in current PX4/master (bb8e6534)
https://github.com/PX4-NuttX/nuttx/compare/f57752b6f16f54bd50188024475657c6a7a1604c...d5c12b24fa5349791220ce44a46b96f345ec77c1

d5c12b2 (HEAD, origin/px4_firmware_nuttx-7.22+, origin/HEAD, px4_firmware_nuttx-7.22+) [BACKPORT] stm32f7:I2C reset Configure I2C pins as GPIO output

Apps:
 - https://github.com/PX4-NuttX/apps/tree/px4_firmware_nuttx-7.22+
 - https://github.com/PX4-NuttX/apps/commit/36806ba3d84c0fa07ed86857d4c92a997b7cd194

Changes from PX4-NuttX/apps (https://github.com/PX4-NuttX/apps/commit/36806ba3d84c0fa07ed86857d4c92a997b7cd194) in current PX4/master (bb8e6534)
https://github.com/PX4-NuttX/apps/compare/36806ba3d84c0fa07ed86857d4c92a997b7cd194...36806ba3d84c0fa07ed86857d4c92a997b7cd194

Previously the rate controller disabled updating the integral below 20%
throttle. This is not ideal for several reasons:
- some racers already hover with 20% throttle.
- for acro it is important to always keep the integral enabled, it has a
  noticeable effect on flight performance.

It's now the same way as in the ARM logic further down.

A reason for using switch arming in the first place is that you cannot
accidentally disarm in-air with the sticks during acrobatic flights.

It also adds a low-throttle arming requirement for switch arming.

This changes the arming logic such that the preflight checks don't need
to be satisfied if arming happens < 5 seconds after the last disarming.
This allows to recover from accidental in-air disarming.

if fRunPreArmChecks was set to false, there were still cases where the
preflight checks could be called. This fixes that.

arming_state_transition() with fRunPreArmChecks=false is only called
when entering & leaving preflight calibration mode.
All other places use fRunPreArmChecks=true, which means there is no change
for these.

- this matches the logic in arming_state_transition()
- if Commander::preflight_check was run in armed state and the checks
  failed, disarming was not possible anymore
  (because disarming checks for condition_system_sensors_initialized).
  That is currently not the case, but the existing logic is way too fragile.

Alternative solution: check if armed in Preflight::preflightCheck, and
only transition to false if disarmed (but also respect the re-arming
grace period).

- libuavcan in PX4/Firmware (fab974fde713b9de0ece1b85239d9dc52622052e): https://github.com/UAVCAN/libuavcan/commit/231b221b64265db4e98f86e53721316f9e17e143
    - libuavcan current upstream: https://github.com/UAVCAN/libuavcan/commit/dfcdf22eda16ff06847976fd6c7f40671fc92eb5
    - Changes: https://github.com/UAVCAN/libuavcan/compare/231b221b64265db4e98f86e53721316f9e17e143...dfcdf22eda16ff06847976fd6c7f40671fc92eb5

    dfcdf22 2018-06-26 Pavel Kirienko - Merge pull request #142 from thirtytwobits/feature/issue141
529a376 2018-06-21 Dixon, Scott - Issue #141 Add Vagrantfile to automate dev environment

    - nuttx in PX4/Firmware (537fe886015be0ccb6b691a8a2802fb29d17c410): https://github.com/PX4-NuttX/nuttx/commit/63775322bf25adb406594f8e610122fe0cef2f7a
    - nuttx current upstream: https://github.com/PX4-NuttX/nuttx/commit/f57752b6f16f54bd50188024475657c6a7a1604c
    - Changes: https://github.com/PX4-NuttX/nuttx/compare/63775322bf25adb406594f8e610122fe0cef2f7a...f57752b6f16f54bd50188024475657c6a7a1604c

    f57752b 2018-06-25 Daniel Agar - Merged in dagar/nuttx/pr-fixCompileError (pull request #660)

Displays all enabled streams and their configured rates.
Example output:
instance #1:
        Name                Rate Config (current) [Hz] Message Size (if active) [B]
        HEARTBEAT                       1.00 (1.000)    21
        STATUSTEXT                     20.00 (6.320)
        COMMAND_LONG                  unlimited
        ALTITUDE                        1.00 (0.316)
        ATTITUDE                       25.00 (7.900)    40
        ATTITUDE_TARGET                10.00 (3.160)    49
        ESTIMATOR_STATUS                1.00 (0.316)    44
        EXTENDED_SYS_STATE              1.00 (0.316)    14
        GLOBAL_POSITION_INT            10.00 (3.160)    40
        GPS_RAW_INT                     1.00 (0.316)    62
        HOME_POSITION                   0.50 (0.158)
        RC_CHANNELS                     5.00 (1.580)
        SERVO_OUTPUT_RAW_0              1.00 (0.316)    49
        SYS_STATUS                      5.00 (1.580)    43
        SYSTEM_TIME                     1.00 (0.316)    24
        VFR_HUD                        25.00 (7.900)    32
        WIND_COV                        2.00 (0.632)

This implementation does not need more resources.
It's not super efficient in terms of runtime, but it's also not something
that is called often.

- add datarate
- add UDP remote port
- add partner IP

Plus correct return value.
Iridium links are below that.