- mavlink/mavlink is now directly included as a submodule instead of the generated mavlink/c_library_v2
- this also switches to mavlink development.xml by default
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
The number of arguments was increased by one, see: 1719ff9892
Because the above commit was merged before https://github.com/PX4/PX4-Autopilot/pull/15443 . It broke support for the remote host option.
This has been fixed in this commit by increasing all argv's by one.
Signed-off-by: Peter Blom <peterblom.mail@gmail.com>
change motor_count variable to 'pos_thrust_motor_count'
This is more specific to what is actually happening in the code.
'pos_thrust_motors_count' indicates number of motor channels which are configured with 0..1 range (positive thrust) all other motors are configured for -1..1 range
submarine only have motors with -1..1 range.
Thus, pos_thrust_motor_count = 0
Co-authored-by: Thies Lennart Alff <33184858+lennartalff@users.noreply.github.com>
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
* Added an option to the Simulator module to connect to remote Gazebo servers.
This is usefull when the Gazebo simulation is running on a different host than the PX4 instance.
For example, we are running instances of PX4 with a companion application in multiple Dockers, for swarming simulations, which then connect to a remote Gazebo server.
A "-t" input argument has been added and can be called from the rcS startup script as: simulator start -t "192.168.178.122" $simulator_tcp_port
* _tcp_remote_ipaddr defaults to nullptr. This way testing against nullptr it can be determined if localhost or remote host is desired by the user.
* Documented the option in usage().
Signed-off-by: Peter Blom <peterblom.mail@gmail.com>
This commit increases the send thread stack size and changes the thread affinity of the lockstep clocking topic. It also improves verbosity in case error states occur.
using unified way to decide which output should be scale as rotor
fixed case that actuator that wasn't set (value 0 "PWM") results output of -3
make default actuator mode to set all actuator to range of -1 to +1
cleanups
- ekf2 can now run in multi-instance mode (currently up to 9 instances)
- in multi mode all estimates are published to alternate topics (eg estimator_attitude instead of vehicle_attitude)
- new ekf2 selector runs in multi-instance mode to monitor and compare all instances, selecting a primary (eg N x estimator_attitude => vehicle_attitude)
- sensors module accel & gyro inconsistency checks are now relative to the mean of all instances, rather than the current primary (when active ekf2 selector is responsible for choosing primary accel & gyro)
- existing consumers of estimator_status must check estimator_selector_status to select current primary instance status
- ekf2 single instance mode is still fully supported and the default
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
- new sensors work item that subscribes to N x sensor_gps and publishes vehicle_gps_position
- blending is now configurable with SENS_GPS_MASK and SENS_GPS_TAU
Co-authored-by: Jacob Crabill <jacob@volans-i.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
It loads the battery parameters but then overwrites them
with hardcoded values and it breaks the ModuleParams
parent/child hierarchy. Both is undesired.