If `make px4_sitl_default` is run, and not `make px4_sitl_default gazebo` then each model instance will throw the following errors:
```
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_gps_plugin.so: libgazebo_gps_plugin.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_multirotor_base_plugin.so: libgazebo_multirotor_base_plugin.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_groundtruth_plugin.so: libgazebo_groundtruth_plugin.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_magnetometer_plugin.so: libgazebo_magnetometer_plugin.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_barometer_plugin.so: libgazebo_barometer_plugin.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_mavlink_interface.so: libgazebo_mavlink_interface.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:178] Failed to load plugin libgazebo_imu_plugin.so: libgazebo_imu_plugin.so: cannot open shared object file: No such file or directory
```
- this lowers the load immediately at boot while still allowing each VehicleIMU instance to properly measure the actual accel/gyro data rates
- for lockstep builds this is ignored and VehicleIMU initially runs with every new sensor_accel/sensor_gyro publication
I changed the input constraint in #15349 but screwed up the usage
because I was convinced it's püass by reference. I'll double check
for sure next time.
- matrix in PX4/Firmware (20d5e7acd6d7be141de802ad155592e7be4c9f77): 9a30828a0a
- matrix current upstream: 0fd99c59f1
- Changes: 9a30828a0a...0fd99c59f1
0fd99c5 2020-07-14 Matthias Grob - Switch operator() to return a const reference
8a59b46 2020-07-17 kamilritz - Quaternion: Use template type instead of single hardcoded type
- sitl_gazebo in PX4/Firmware (f4d7052bece7608fc3f94b6520b788fc83339635): 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
