* mc_pos_control: use just float for vel and cruise in xy
* mc_pos_control: stick map saturate magnitude to 1
* mc_pos_control: take minimum cruising speed for auto
* mc_pos_control: cruise speed triplet higher than from mc_pos_control
mc_pos_control: fix if for cruise in auto
* mc_pos_control: use PX4_ISFINITE criteria
Backport of upstream NuttX
86400a252dcbe6e4aef3ecca000b469a0fe96b67
08e92abb0ba744927ed0b32294859b0f47726f82
4b65817e99cbdf04fefad883eca0e7c8a9add63c
Improper rounding in redundant stack coloring
routines could overwriting the TOS+1 and BOS-1
depending on the value of CONFIG_ARCH_INTERRUPTSTACK
This applies the compelet upstream set of fixes from
David Cabecinhas <david.cab+bitbucket@gmail.com>
Improper rouding in redundant stack coloring
routines was overwriting the TOS+1 and BOS-1
The legacy OABI 4 byte stack alingment was removed
Only the EABI 8 byte alinement is supported
The redundant interrupt stack coloring. up_initalize
had the correct implemantation (last verson of patch)
and the redundant version in the
arch/arm/src/stmxxx/stmxx_irq.c was calculating the size
wrong.
This is fixed by rounding up CONFIG_ARCH_INTERRUPTSTACK
by 4 bytes when allocated and alining on a 8 byte boundry
nuttx-patches/workarround_for_flash_data_cache_corruption.patch was
patching a file patched in nuttx-patches/wip_inflight_to_upstream.patch
The changes in workarround_for_flash_data_cache_corruption.patch
will be submitted upstream once refactored (upstream coding style
compliant and moved to correct location)
32 bits are still enough to measure elapsed times up to 1 hour.
Testing on Pixracer: I counted 73 allocations and 39 frees during bootup,
resulting in 2kB RAM usage after boot. This patch reduce this by ~0.5kB.
Fixed the block comments at the top of the source file and the help message for the script (starting at line 279) so that an underscore ("_") character is correctly described as the separator for the first message field name rather than a period character "."
* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time
* Added a separate mixer file for CAN quadrotor
* Sampling profiler improvements
* PMSP: Output more endpoints
* Matrix update
* libc usage workaround
* Removed UAVCAN perfcounters
* Matrix submodule update
* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time
* Added a separate mixer file for CAN quadrotor
* Sampling profiler improvements
* PMSP: Output more endpoints
* Matrix update
* libc usage workaround
* Removed UAVCAN perfcounters
In order to ensure correct transmission the mission system needs to default to the legacy protocol and switch to the new implementation when these conditions are met:
* If the GCS sends a MISSION_REQUEST_INT - it will do this based on the AUTOPILOT_VERSION flag indicating int mission support
* If the autopilot sends a MISSION_REQUEST and has the AUTOPILOT_VERSION flag for 2.0 set, the GCS should NACK it, which will make the autopilot retry a MISSION_REQUEST_INT
* If the autopilot sends a MISSION_REQUEST_INT and the GCS does not support it, the GCS will ignore and time out. The autopilot could retry now opportunistically with the old protocol, but this is not great for lossy links.
* If the GCS sends a MISSION_ITEM_INT - this is a fallback
param_save_default() could take something like 0.5s, and because the
LandDetector is running on the HP work queue, this would block other
tasks, like RC handling or drivers.
This allows concurrent read access, which are much more common; reducing
potential lock contention and increasing concurrency.
Taking a lock is expensive, and the reader lock is now even more expensive.
An RCU synchronization scheme would reduce the overhead of the readers to
increasing/decreasing an atomic counter.
Thus this should only be an intermediate step until we move towards RCU.
Tested on SITL & Pixracer.
param_t is only used as an offset and we have <1000 params, so an uint16_t
is enough.
This saves roughly 1KB of RAM. We only do that on NuttX because normal
integers have better performance in general.
Previously on amd64, this was even 64bits because it was an uintptr_t.
This further speeds up param loading.
On Pixracer via USB, it's possible to send up to 11 at once before the TX
buffer gets full, so there is still enough free bandwidth left.
This speeds up parameter loading. Slow links like telemetry are unaffected,
since the mavlink loop runs only with ~100Hz.
Tested on various links, like:
- telemetry link
- pixracer WiFi
- pixracer USB
- SITL
Henry Zhang