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.
- 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
Daniel Agar