- replay was not working without these values as only range measurements
were given to the filter which were between the min/max value
Signed-off-by: Roman <bapstroman@gmail.com>
Reasons:
- DeviceMaster::_node_map does not need to be shared among instances,
because there is at most 1 instance per Flavor and different Flavors
have non-intersecting device paths.
- Keeping it static would also require a static lock
- DeviceMaster::_node_map was not locked at all when used from
uORB::Manager
So this fixes two synchronization issues:
- Different DeviceMaster objects could access the same static data in
parallel
- getDeviceNode() called from uORB::Manager did not use any locking at all
This has the following benefits:
- Manager can ensure that there is at most one instance of DeviceMaster
per Flavor
- The Manager needs access to (static) data of DeviceMaster already.
This will make it easier to access this data in a non-static way, and
does not introduce new dependencies.
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.
Lorenz Meier