The flight graph is stored as a series of delta elements at 1m resolution and a list of nodes. Both lists share the same buffer. Each delta element takes up 2 bytes or sometimes 6 bytes if the delta is large. The path can consist of multiple disconnected segments, in which case the gaps are stored as delta elements with a jump-bit set.
Once in a while or when required the graph is consolidated, which means:
- Points that lie roughly in a line are replaced by a single line
- Points that lie close to previously recorded lines are pruned
- For lines that pass close to each other a node element is created
Furthermore:
- The graph is recorded at a higher precision closer to home
- If the graph becomes full, the overall precision is reduced and the whole graph is re-consolidated
- If the graph becomes full once more, all data is removed except for the shortest path home at that moment. One of these actions is repeated at each subsequent fill-up.
Path finding information is generated/refreshed on demand and stored in the nodes. During return-to-home, the best direction to home is continuously evaluated by using the information stored in the nodes.
The graph recording and path finding is implemented in navigator/tracker.cpp.
The graph based return-to-home is implemented in navigator/smart_rtl.cpp.
I observed stack overflows when executing `uavcan params list`, so the
stack size probably needs to be increased.
Signed-off-by: Alex Mikhalev <alexmikhalevalex@gmail.com>
Sometimes, the mission_result timestamp is the same as the
internal_state timestamp which would meant that we would not switch to
LOITER even though the takeoff is clearly done at that point.
Track Changes in NuttX stm32h7 flash driver:
The STM32H7 flash driver uses up_progmem_pagesize to
describe minimum write size to satify the block size
requierment for ECC.
Therefore, the image size needs to be padded to a multiple
of up_progmem_pagesize()
sensors having mixer_module creates a dependency on sensors for
the param MOT_SLEW_MAX. Things that do not uses sensors.
IE. PWM only device should not have to include them.
Motors in Px4 ecosystem are indexed using 1-based indexing (Airframe reference, dshot command, etc.) motor_test command is 0-based. This PR changes motor_test to use 1-based indexing.
This PR refers to Github issue #15721.
* Added buffer length check to SMBus::block_read (triggered hardfault in batt_smbus module by writing beyond buffer end due to device returning longer byte_count than requested/expected)
Co-authored-by: Florian Olbrich <florian.olbrich@scarabot.de>
Co-authored-by: Daniel Agar <daniel@agar.ca>
Co-authored-by: BazookaJoe1900 <BazookaJoe1900@gmail.com>
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
- new sensors work item that subscribes to N x sensor_gps and publishes vehicle_gps_position
- blending is now configurable with SENS_GPS_MASK and SENS_GPS_TAU
Co-authored-by: Jacob Crabill <jacob@volans-i.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
So that clang 12 does not complain:
loop variable 'child' is always a copy because the range of type 'List<ModuleParams *>' does not return a reference
Co-authored-by: Yashom Dighe <yashom7@gmail.com>
120 seconds of learning time in 3D fusion mode was too long for most normal flights. The learned bias is usually really good after a shorter period and was not used to update the parameters. 30s seems to be a good compromise.
So that clang 12 does not complain:
loop variable 'child' is always a copy because the range of type 'List<ModuleParams *>' does not return a reference
- simplifies creation of an airframe config
- could be done from QGC, but it only knows if a param is non-default from
metadata, which can be incorrect/missing information
- for the list of exceptions we could look at '@category', but we don't have
that info in the build
- there might be some more exceptions to be added