* 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 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
Note that the MAVLink definition explicitly writes
"A value of INT16_MAX indicates that this axis is invalid."
which before this change was happily executed.
When we use a gimbal connected via "RC", so PWM via the Aux channels, we
need to set the gimbal_device_id to 1 as per the protocol.
This was missing for GIMBAL_DEVICE_ATTITUDE_STATUS, so I added that, and
fixed the name of that variable while at it.
This fixes an issue where we dropped acks that we should have sent out
just because the queue was clogged with acks that have nothing to do
with us and just happen to be sent to us. We should just ignore them and
not publish them to uORB.
We should not send out acks for commands that are not targetted at us.
This can confuse other MAVLink components and MAVLink commands just
don't scale that way, and it unnecessarily fills up our ack queue.
This was likely introduced to debug when MAVLink components were
implemented incorrectly sending commands to a wrong target.
The most we should do in this case is to print/log an info.
This fixes the SITL tests that fail in CI because we catch NAN as non
zero after cast to int. To fix this I've added the check whether they
are finite at all.
The checks for param5 and param6 would be a bit trickier because they
can be int or float, so I have omitted them for now.
This will send the System message if it is already being sent by a ground
station. Otherwise, it will assemble the message itself using the
takeoff/home location.
* Remove euler angles from attitude setpoint message
* Remove usage of euler angles in attitude setpoint messages
This commit removes the usage of euler angles in the vehicle_attitude_setpoint messages
* Fix standard vtol
This adds explicit handling for the few things we want to allow through a MAVLink instance dedicated to a gimbal/(camera) payload as per the MAVLink gimbal mode configuration.
- warn about full traffic conflict buffer at 1/60hz.
- add conflict expiry for buffer.
- use only events for buffer full warning. mavlink_log_critical no longer needed.
- use icao address for conflict warnings id, stop using uas_id. UTM_GLOBAL_POSITION assumed deprecated.
- stop spamming when buffer is full
- fix warning wording if buffer is full.
- remove UTM_GLOBAL_POSITION
Fixes failing unit test:
* [adsbTest] Reduce conflict timestamps - not enough time has passed in ci
- failed ci output - (passes locally with make tests TESTFILTER=AdsbConflict)
- Timestamp: 6000000000
- Time now: 457720038
- Time since timestamp: 0
- Old Conflict warning expired: 0
- --------------------
- adsb_conflict._traffic_state 0
- ../../src/lib/adsb/AdsbConflictTest.cpp:244: Failure
- Value of: adsb_conflict._traffic_state == TRAFFIC_STATE::REMIND_CONFLICT
- Actual: false
- Expected: true
When the yaw estimate is converging, the controller makes the drone yaw
in order to follow the current setpoint. This is unintuitive for the
pilot and it is preferable if the drone continues to fly towards the
same physical direction.
In the mavlink_receiver code, after a while it will try to resend some
parameter update through the MAVLink instance. But for Iridium links
those are not a good idea. So this adds a condition that prevent the
sending if the MAVLink instance is in Iridium mode.
Related to issue #21496
Camera controls should not happen through the flight controller, and
the control allocation has no means of controlling the camera zoom.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
In review it was requested to have a different name for
manual_control_setpoint.z because of the adjusted range.
I started to investigate what naming is most intuitive and found
that most people recognize the stick axes as roll, pitch, yaw, throttle.
It comes at no surprise because other autopilots
and APIs seem to share this convention.
While changing the code I realized that even within the code base
the axes are usually assigned to a variable with that name or
have comments next to the assignment clarifying the axes
using these names.
To be consistent with all other axes of stick input and avoid future
rescaling confusion.
Note: for the MAVLink message 69 MANUAL_CONTROL it's using the full range
according to the message specs now [-1000,1000].
The CameraFeedback module used only the vehicle attitude for the camera orientation so far. With this change, the gimbal_device_attitude_status is used to compute the global camera orientation when a gimbal is used.
