- sitl_gazebo in PX4/Firmware (f4d7052bec): 629e5f5c23
- sitl_gazebo current upstream: ce1eca2bd0
- Changes: 629e5f5c23...ce1eca2bd0
ce1eca2 2020-07-19 Daniel Leonard Robinson - New vehicle type: Airship (#490)
df186d2 2020-07-18 TSC21 - use 'EnableC++XX' and remove duplicated compiler sets
60e5d4e 2020-07-18 TSC21 - remove the check for the 'px4' binary (it's never found since it's built in parallel with sitl_gazebo)
a3b5c5e 2020-07-19 JaeyoungLim - Fix moment calculation (#545)
07820ee 2020-07-19 JaeyoungLim - Fix gimbal imu sensors intefering with each other (#549)
- nuttx in PX4/Firmware (2624730b02ea71fa2bbd28cc424d9bade5766356): 61742342ec
- nuttx current upstream: dc10293feb
- Changes: 61742342ec...dc10293feb
dc10293feb 2020-05-25 Claudio Micheli - [BACKPORT] stm32l4: extend CAN ioctrl with NART/ABOM. Add RTR to CAN header
5735f765e2 2020-05-25 Claudio Micheli - [BACKPORT] stm32: extend CAN ioctrl with NART/ABOM. Add RTR to CAN header
4dc9ae05f5 2020-05-25 Claudio Micheli - [BACKPORT] stm32f7: Add the option to include RTR in CAN header
bdd9e786e1 2020-04-21 Beat Küng - [BACKPORT] stm32f7: add CANIOC_SET_NART and CANIOC_SET_ABOM ioctl's to can driver
- vehicle_air_data won't necessary have an update every iteration and these adjusted throttle values aren't stored
- this only would have worked in the past because the vast majority of systems were using the ms5611 barometer with a publication rate that's faster than the controller
- Spaces -> tabs.
- Remove "brew install python" because it's already a dependency of the
px4-dev tap.
- Remove "brew install ccache" as we can also add it to the px4-dev tap.
- Don't try to update pip installation, it works fine as is.
- Install pip dependencies as user, no need for system-wide install.
This fixes the takeoff and land CI test where we do a takeoff and land
without RC connected.
In my opinion it does not make sense to go into RC lost failsafe if
a datalink is still available.
Of course, this can be dangerous if someone has a companion computer
connected which gets detected as "data link" but actually has no
connection to the ground station.
During takeoff, Navigator is sending a constant yaw value.
However, there is always a reset at 1.5m of the yaw estimate in EKF2
that is not handled by Navigator that produces a glitch in the rate
controller. Given that in FlightTask, the yaw
is already computed and properly corrected in case of an estimator reset
event, we just ignore the yaw value sent by navigator during takeoff.
- increase rate
- cpu load calculation grab timestamp atomically
- only check one task per cycle (but cycle at a higher rate)
- decrease available FD threshold
- minor cleanup
This workaround should fix the test failure where we disarm before
taking off because we accidentally switched to failsafe mode right
before taking off because we were still in Manual mode and not Hold yet.