It uses a queue length of 6. There are 3 RTCM msgs/s, but due to
fragmentation and WiFi lags, there can be more than that. During several
tests, a length of 6 showed no queue overflows.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
We should not spam the console just because the input data is
degenerate, it would only make things worse because everything would
slow down due to the printfs.
Opening/seeking/closing the file for each data chunk was extremely
expensive and drastically slowed the download process as the position
in the file increased. Over USB with large files this change + nuttx
update results in ~ 10x speedup for log downloads.
issue (GCC 6.1.1):
../src/modules/fw_pos_control_l1/fw_pos_control_l1_main.cpp:1284:27: error: implicit conversion from ‘float’ to ‘double’ to match other operand of binary expression [-Werror=double-promotion]
if ((fabs(air_gnd_angle) > M_PI) || (ground_speed_2d.length() < 3.0f)) {
Since the FRAM and the baro are on the same bus on the Pixracer, we
currently need to lock down everything (instead of just this SPI bus)
for the time when the params are written.
Therefore, we need to keep this locking as short as possible.
This change makes the locking even shorter by moving all param_get and
param_name and param_size calls out of the lock.