More realistic than plain constant movement. Implemented with white
noise, low pass filter & feedback term ensuring we stay close enough to
upright.
Tuning knobs maybe not very intuitive at the moment. There are:
- update rates alpha_v, alpha_w (bigger = faster movement)
- amplitudes ampl_v, ampl_w (bigger = larger movement)
- feedback gains pos_gains, attitude_gain (bigger = smaller movement)
maybe we could remove the redundance between the latter two?
Also:
- overload setPlatformVelocity for different inputs
- don't set aircraft pose at all (make sure with environment variable
that it is on platform)
- platform height = 2m defined in sdf file
- rename pose -> navsat to be more precise
- gz submodule update. heavier platform & initial pose.
in Tools/simulation/gz submodule. for now I am pointing it to the PR
branch moving_platform_world which contains the moving_platform world.
The world contains the platform so we remove the platform definition and
the code that added it dynamically.
Also the env var GZ_MOVING_PLATFORM is now gone -- world name can be set
with existing env var PX4_GZ_WORLD.
We now have setPlatformVelocity, which commands a velocity command to
the platform. The platform handles it with the
gz::sim::systems::VelocityControl plugin.
We could also set the velocity once and forget about it (has no effect
if doing it directly after creating it though, need to wait a bit, 2
seconds worked). But by setting it constantly we can easily change to
more realistic boat-like movement.
the good:
- we have a platform in gazebo, created dynamically from GZBridge.
- it has a NavSat sensor, with a working callback on the PX4 side,
GZBridge::platformNavsatCallback. From there we can publish the info
as uOrb and do what we want with it.
the bad:
- the platform doesn't move yet
the ugly:
- the platforms sdf file is currently untracked in the
Tools/simulation/gz submodule. Without this the commit here is
useless. Need to find a sensible spot for it.
* remove temp field from airspeed.msg, adjust temp selection
* temp-sensor hirarchy: airspeed, ext. baro, default value
* directly use diff-press or baro temp in true-airspeed calc
* improve clarity
* add enum for temperature source in VehicleAirData.msg
The current approach was wrong because the gimbal protocol now
handles the case properly where the autopilot is in charge of a
non-MAVLink gimbal.
This means that we don't need to send message "as if we were a gimbal
device" and instead set thet gimbal_device_id to 1 (up to 6) to indicate
we are in charge or a non-MAVLink gimbal.
* fix sign error in appropriate place
In PR https://github.com/PX4/PX4-Autopilot/pull/24175 I changed the
control surface deflection signs in generate_fw_aerodynamics to make the
1103 airframe work correctly. However, this breaks the 1101 airframe,
introducing sing errors there.
So, here the change in generate_fw_aerodynamics is reverted to the state
before PR #24175. Instead, the signs are set correctly by using
the HIL_ACT_REV bitfield in the respective airframe config files.
* match control surface parameters to SIH model
* fix max-hagl restriction to position/altitude control
* max hagl vel restriction in ManAcc position mode
* use interpolate func, change naming
* simplyfied vertical vel limitation
* move velocity-constraint adjustment to StickAccelXY
* add standard vtol airframe to SIH.
mostly took changes from 4d930bde and applied to main.
generate_fw_aerodynamics now takes four arguments rather than using the
_u class member, because depending on vehicle type _u is used
differently.
SIH: use projection functions and constants from geo lib
SIH: remove unnecessary member variable
SIH: clarify names of rotation matrices and frames
SIH: do not store DCM corresponding to quaternion attitude
Using DCM is more efficient when more than 1 rotation needs to be done,
which is not the case here.
SIH: don't store local variable as member
SIH: use Wgs84 constants everywhere
SIH: do not store delta_quaternion
Converting an AxisAngle to a Quaternion uses the exponenial
SIH: organise ECEF member variables
SIH: add earth spin rate to gyro data
Co-authored-by: bresch <brescianimathieu@gmail.com>
Without this change the configured dialect would not get included
correctly in the simulator_mavlink module, only in the main mavlink module.
Configured using e.g. CONFIG_MAVLINK_DIALECT="development"
in e.g. boards/px4/sitl/default.px4board file.
Balduin