There is no reason to keep an uncertainty on the origin as it is then
already contained in the local position estimate when GNSS data is fused
in the filter.
The command is sent by a dedicated mavlink command and forwarded to the fixed wing position controller.
The pattern is defined by the radius of the major axis, the radius of the minor axis and the orientation. The pattern is then defined by:
The upper part of the pattern consist of a clockwise circle with radius defined by the minor axis. The center of the circle is defined by the major axis minus the minor axis away from the pattern center.
The lower part of the pattern consist of a counter-clockwise circle with the same definitions as above.
In between, the circles are connected with straight lines in a cross configuration. The lines are always tangetial to the circles.
The orientation rotates the major axis around the NED down axis.
The loitering logic is defined inside its own class used by the fixed wing position control module. It defines which segment (one of the circles or lines) is active and uses the path controller (npfg or l1-control) to determine the desired roll angle.
A feedback mavlink message is send with the executed pattern parameters.
- make it work again
- also supports Kconfig based clk source selection
- adapt to recent changes of default PWM limits
- support outputting in duty-cycle mode
- i2c addr use use hex representation
- revert back to common min/max value & move duty-cycle mode to advanced
We provide a latency measurement in the input capture handler.
However, since the timer was not enabled, none of the counter were
running therefore all counters were zero, thus latency was also zero.
Since the HRT is used to provide a timestamp, the lack of the running
timer was never noticed. After enabling the timer, latency now correctly
shows 9-10 counts.
* Fixed an issue where if the GCC_VER_STR would not contain the right NUTTX_GCC_VERSION, the grep -c command would throw a failure, silently exiting the entire ubuntu.sh setup script
This is a tool that can be used to generate advanced lift drag plugin parameters automatically using AVL. Rather than having to create .avl files yourself, pass them to AVL, read out the correct parameters and place them in the Advanced Lift Drag plugin, this tool will do all that for you and generate a complete advanced_lift_drag plugin sdf containing all necessary parameters for any vehicle. All that is required is to specify what the physical geometries of the vehicle are. The scripts are adaptable enough to support a self-selected number of control surfaces.
---------
Co-authored-by: frederik <frederik@auterion.com>
alexklimaj
bresch
Frederik Markus
Konrad
Mathieu Bresciani
Daniel Agar
Peter van der Perk
David Sidrane
Matthias Grob
SalimTerryLi
Niklas Hauser
Roman Bapst
Julian Oes
Engin Oksuz
Titus
Robbie Drage