Graph-based Return-To-Land #5829
Conversation
|
Still out of flash, and quite significantly. It seems strange that the tracker would use that much flash. Maybe it has to some dependencies on complex functions from the stdlib that get linked into the binary. I might investigate if I have time, otherwise one could just disable the tracker for px4fmu-v2. |
|
@samuelsadok Any thoughts on getting this small enough to fit in fmu-v2? Try moving your test date to ROMFS/px4fmu_test. If you can resolve the merge conflicts and get this small enough I'll add the test to SITL in the builds. |
|
The target I'm kind of busy right now, so I can't do an in-depth investigation on what causes the huge size. Are there many people still using fmu-v2? If not, we could just disable it (how is that done best?), so that at least other users get the feature. |
|
Ah, sorry I missed the inclusion. |
|
@samuelsadok we now have space available on px4fmu-v2. |
|
The problem is that with each rebase the quality decreases because there usually are conflicts/incompatibilities and I don't have the time to test/fix my stuff each time. This time, it seems for instance that the |
|
Yes, sorry about that. I was hoping we could get it into a state to review and safely merge, but it's even less likely to be reviewed if the builds aren't passing. For running tests under SITL the tests are now listed here https://github.com/PX4/Firmware/blob/master/src/firmware/posix/sitl_tests.cmake#L20, then ctest runs them individually to report overall pass/fail. |
|
Ok I added the navigator_tests. Please note that they only test the logic of the Tracker object. Someone needs to make sure that the integration with the whole RTL works as expected in the real-world (I don't have hardware). Do we have a script to automatically format the code? |
|
We use astyle for formatting. The configuration is |
|
This is really well done. I'm mainly wondering how we should fit it in with the current behavior. There are certain situations where this is better, but many where classic RTL (climb to safe altitude, straight line home) would still be preferred. @LorenzMeier do you have any thoughts on how smart RTL fits into PX4, particularly from the user perspective and fail safes? |
|
@samuelsadok We are just stabilising master for the next stable release, but this is a super high priority for me to get in, so hang in there. I will do a test flight on this branch as soon as time permits. |
|
With v1.6 almost out of the door, I would like to focus on getting this excellent piece of work in. @LorenzMeier @dagar @samuelsadok. |
|
So what's blocking this? I can rebase again but I can't keep doing it forever. I guess the main point is someone actually needs to to flight test it, because I don't have the necessary hardware. |
|
@samuelsadok It would be great if you could rebase it just once more, and then I'll take over. Let me know places where it could break, what needs testing, open concerns, etc. Thanks a lot! |
|
Ok sure that would be cool, I'll have a look and rebase some time this week |
|
@samuelsadok Any luck? |
|
I did a rebase locally today and tried to run the SITL but that broke something in the way I set setpoints. I didn't have the time though to track it down yet. The recorded graph data looks fine. I'll get to the bottom of it as soon as time permits. |
…a memory optimimized format. This means the UAV can return to home by using only known-good flight paths. 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.
|
Ok got it to work again. The issue was probably related to something that changed in the conversion from local to global coordinates. Now I pass the transformation-reference explicitly. That also made me aware that if this reference changes mid-flight this is unhandled. I added an overview of the implementation in the commit message and to As for testing/maintenance: The graph and pathfinding implementation itself is verified through unit tests, so I'm pretty confident in that. The more uncertain part for me is the integration, i.e. the logic in Let me know if you need more information or run across issues while testing. I'm just slightly constrained in time but I'll do my best to assist. |
|
@samuelsadok Thanks a lot! I will start having a look now. Can you please upload your thesis to e.g Google Drive? Or you could email it to me at [email protected]. |
|
OK, I'm closing this in favour of #7363 . I moved the commits over to our repo so that I can work on it easily. |
#5745 rebased