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
```
Minor consistency fixes for the copyright header and update the tables to current. PX4Buildbot will periodically update the tables automatically from this point.
- 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
GCC 10 gives a warning
"comparison of unsigned expression in ‘>= 0’ is always true"
for these asserts since checking if an unsigned integer cannot
be negative and hence the statement gets droped.
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.
- updated table to 2 bytes (int16) per element and scaled the inclination/declination/strength tables to use most of the range without being too awkward
- tables have been extended to include the full latitude range
- expanded the API slightly to offer declination/inclination in both degrees/radians and the magnetic strength in Gauss and Tesla
- generated some simple testing that verifies interpolation between points
- 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
Matthias Grob