The length check for unknown packets did not include PACKET_SIZE_TYPE_SIZE
and CRC_SIZE, and hence working_index could overflow CRSF_MAX_PACKET_LEN,
triggering invalid memory access further down in QueueBuffer_PeekBuffer.
Also the working_segment_size was wrong for unknown packets.
Credits for finding this go to @Pwn9uin.
The sparse vector template requires to know which states are non-zero in
the observation jacobian. This complicates the modularity of the code
when the state vector or the derivation is changed.
The computation cost difference is almost negligible for this size.
For FW takeoffs we need to keep the course straight towards the first
waypoint, and not climb in loiter patterns first.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Dataman: Add write function to dataman cache.
RTL and mission have a new common base class mission_base. Both inherit from them and mission, RTL mission, and rtl reverse mission inherit from them and implement their desired functionalities. This simplifies the logic in mission as well as make the logic in rtl mission reverse and mission more readable.
Rtl mission reverse now functional again for VTOL flying back the mission and transitioning to MC at the home position.
Dataman cache has new write functionality to write to dataman while updating write item in its cache if necessary.
Dataman cache is now only updated when the respective module is active. Leads to a higher computation time once on activation, but decreases unnecessary cache updates when inactive.
This is required to support fixed pitch propeller helicopters that have
no collective but only cyclic pitch with two degrees of freedom and
hence only two servos.
The amount of thrust in the body z axis is then controlled using the
motor speed which makes particularly sense on coaxial helicopters
that need to control yaw with changing motor speeds already.
- Preserve tilt variance while doing a yaw reset
- Yaw variance is now correctly set instead of increased
---------
Co-authored-by: Dominique <dominique.leblanc@donecle.com>
Co-authored-by: bresch <[brescianimathieu@gmail.com](mailto:brescianimathieu@gmail.com)>
Events have a global, system-wide sequence number, which must be handled
atomically, (fetching and incrementing the sequence AND sending the event
to uORB must be atomic). Currently in FLAT mode, only one instance of this
sequence number exists, so it is OK to have it in px4_platform.
However, in PROTECTED mode px4_platform is instantiated both in kernel-
and user spaces, which makes two instances of this sequence number, which
causes problems in the mavlink event handling logic.
When mavlink receives and handles events, it expects that:
- The sequence numbers arrive in order (seq n is followed by n+1 etc)
- It increments by 1
- There is only one instance of the sequence number
In PROTECTED mode this is violated, as the kernel and user sequence
numbers run freely on their own. This patch fixes the issue by moving
the event backend to the kernel and by providing user access to it via
ioctl.
Even if there is some horizontal motion, a passing check should be
accepted as the terrain can be flat. However, the vehicle must not be
moving horizontally to invalidate the consistency as a change in terrain
can make the kinematic check temporarily fail.
A setpoint of type IDLE can be published by Navigator without a valid position,
and should be handled in the auto function in FW_POSCTRL_MODE_AUTO. If it wouldn't be
handled there the controller would switch to mode FW_POSCTRL_MODE_OTHER, in which case
no attitude setpoint is published and the lower controllers would be stuck with the
last published value (incl. thrust).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
but this time compared to
2fbb70d9ca94f442de1345221be18ba738cda952
the minimum thrust is ramping to not produce a thrust jump.
The better long term solution will be to always have airmode but
with the effect limited to a magnitude of MPC_MANTHR_MIN.
high rates and (super) expo are necessary for
- acrobatic flying
- fpv
- racing
but they are not useful for:
- a typical vehicle's rate control tuning
- beginners
The defaults that I set in #8036 were put with the assumption Acro mode
is mainly used on racing drones for acrobatic manouvers but instead
users including me use it most of the time to tune any drone.
When tuning the rates are lowered and expo disabled.
My suggested strategy is to make the beginner friendly rates without
expo which are good for tuning the default and document more clearly
how this can be raised for acrobatic flying in documentation and later
on hopefully also directly in the ground station UI
on an Acro mode specific page.