search

ros-navigation / navigation2

ROS 2 Navigation Framework and System
https://nav2.org/
Other
2.48k stars 1.26k forks source link

how can i decrease calculate time on Embedded Chips when use theta star planner #3535

Closed dahuacai closed 1 year ago

dahuacai commented 1 year ago

Issuse: I use the theta star algorithm on rockchip 3308 embedded chip(the IoT processor is based on ARM quad-core 64-bit Cortex-A35 kernel with 4cpu 255M RAM 512M ROM).when i plan a path with map w,h=(192,254) res=0.05, it wasters near 90ms to get a 15m path.when i use navfn_planner, it only waster 9ms. the 90ms is not acceptable.how can i optimize the code to decrease calculate time.I guess the time was wasted on the "loscheck" function.Could you give me some suggestions for revision (we want the output path is as far away obstacle as possible and as smooth as possible)

plan map: theta

CPU INFO: cpu

SteveMacenski commented 1 year ago

I removed the LOS function copy + paste, I don't think it needs to be in the ticket.

I'm happy to field a PR to increase the performance of the Theta* planner of course! You may want to start with profiling the codebase to see where the most time is used and start tackling the bigger entries first. Its better to know than guess. If you get a flamegraph, then it should be more understandable where is good to address. I agree LOS is probably part of it and perhaps there are elements of the system that can be optimized further via software optimization processes rather than robotics technique updates. Though, maybe both could be useful.

However, you're going to have to do some of the heavy lifting here to experiment since these are your requirements, not mine :smile: I only have so much time and this isn't a top priority to me -- but as you're progressing, happy to help answer questions or otherwise bounce ideas around once we know better what parts of the system are worth looking into as the highest compute sections. There may be some really easy low-hanging fruit changes - I don't think anyone's profiled this code formally yet.

Screenshot from 2023-04-19 08-45-14

For reference, here are some compute times from a paper benchmarking nav2's algorithms. Theta* is definitely the slowest currently of them, but only by about 50% compared to NavFn. It might be you overtuned some parameters resulting in a great deal of re-expansions if you overplayed your hand in trying to keep the robot far from obstacles by jacking it up unrealistically high so any minorly further path recomputes an entire region multiple times.

dahuacai commented 1 year ago

that's ok. I will further test and give some feedback

SteveMacenski commented 1 year ago

@dahuacai any feedback :smile:

SteveMacenski commented 1 year ago

Closing - happy to reopen or have a PR if you find a way to speed things up! But for now, it meets our requirements on performance. Improvements always welcome, but if there's not a tangible suggestion or actionable change, I don't think we need to have a performance ticket open for every algorithm 'to make it faster'. Obviously, we'd be happy if any algorithm was made faster :smile:

If you find a potential improvement, I'd love to know!