Feat/smac planner include orientation flexibility #4127

stevedanomodolor · 2024-02-20T19:11:15Z

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #4019)
Primary OS tested on	(Ubuntu, MacOS, Windows)
Robotic platform tested on	(Steve's Robot, gazebo simulation of Tally, hardware turtlebot)
Does this PR contain AI generated software?	(No; Yes and it is marked inline in the code)

Description of contribution in a few bullet points

tackles issue [Smac Planner] Enable goal orientation non-specificity #3789
Includes the possibility for the user to determine whether they want the goal heading should be default(the one defined in the goal), bidirectional (user defined + 180 degrees), or all_direction. This way, the user can save time calling the planner multiple times when the angle of the goal does not have to be fixed and has a bit of flexibility.
Results can be seen.

Success rate for  ALL_DIRECTION_SmacHybrid  is:  98.33333333333333 %
Success rate for  ALL_DIRECTION_SmacLattice  is:  97.66666666666667 %
Success rate for  ALL_DIRECTION_Smac2d  is:  100.0 %
Success rate for  BIDIRECTIONAL_SmacHybrid  is:  98.33333333333333 %
Success rate for  BIDIRECTIONAL_SmacLattice  is:  97.66666666666667 %
Success rate for  BIDIRECTIONAL_Smac2d  is:  100.0 %
Success rate for  DEFAULT_SmacHybrid  is:  96.66666666666667 %
Success rate for  DEFAULT_SmacLattice  is:  95.0 %
Success rate for  DEFAULT_Smac2d  is:  100.0 %
Success rate for  NORMAL_SmacHybrid  is:  96.66666666666667 %
Success rate for  NORMAL_SmacLattice  is:  95.0 %
Success rate for  NORMAL_Smac2d  is:  100.0 %

**********************Results Goal heading mode Default **********************
Read data
-------------------  -----------------------  -------------------  ------------------  ------------------
Planner              Average path length (m)  Average Time (s)     Average cost        Max cost
DEFAULT_SmacHybrid   48.59179172137297        0.08409778965140845  1.0656706399532687  54.59154929577465
DEFAULT_SmacLattice  49.30762557367365        0.4135887128204226   0.8137733557552133  53.813380281690144
DEFAULT_Smac2d       48.52958672840513        0.12046826587323943  0.7580233687132835  65.47183098591549
-------------------  -----------------------  -------------------  ------------------  ------------------
**********************Results Goal heading mode bidrectional **********************
Read data
-------------------------  -----------------------  -------------------  ------------------  -----------------
Planner                    Average path length (m)  Average Time (s)     Average cost        Max cost
BIDIRECTIONAL_SmacHybrid   48.72823963695479        0.03030190022535211  1.0223910481559262  54.13028169014085
BIDIRECTIONAL_SmacLattice  49.50773050762388        0.17851250328169013  0.7209227860091986  51.23943661971831
BIDIRECTIONAL_Smac2d       48.52960037283171        0.12235441819718311  0.7580233687132835  65.47183098591549
-------------------------  -----------------------  -------------------  ------------------  -----------------
**********************Results Goal heading mode all direction **********************
Read data
-------------------------  -----------------------  --------------------  ------------------  -----------------
Planner                    Average path length (m)  Average Time (s)      Average cost        Max cost
ALL_DIRECTION_SmacHybrid   48.72823963695479        0.031168896616197185  1.0223910481559262  54.13028169014085
ALL_DIRECTION_SmacLattice  49.50773050762388        0.18361958839788733   0.7209227860091986  51.23943661971831
ALL_DIRECTION_Smac2d       48.52960037283171        0.12754024430633804   0.7580233687132835  65.47183098591549


**********************Results Goal heading mode NO changes **********************
Read data
-----------  -----------------------  -------------------  ------------------  ------------------
Planner      Average path length (m)  Average Time (s)     Average cost        Max cost
SmacHybrid   48.59179172137297        0.0930492549330986   1.0656706399532687  54.59154929577465
SmacLattice  49.30762557367365        0.44674316980633805  0.8137733557552133  53.813380281690144
Smac2d       48.52958672840513        0.12973642600352114  0.7580233687132835  65.47183098591549
-----------  -----------------------  -------------------  ------------------  ------------------

Description of documentation updates required from your changes

How to run

Future work that may be required in bullet points

For Maintainers:

Check that any new parameters added are updated in navigation.ros.org
Check that any significant change is added to the migration guide
Check that any new features OR changes to existing behaviors are reflected in the tuning guide
Check that any new functions have Doxygen added
Check that any new features have test coverage
Check that any new plugins is added to the plugins page
If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

SteveMacenski · 2024-02-21T18:49:21Z

@stevedanomodolor what's the status here - do you want me to review in detail, have gaps that are TODO, or have some questions to discuss? I don't want to go through and nitpick some small issues if you're really looking for feedback elsewhere right now.

SteveMacenski

I didn't review the analytic expansions yet, pending your answer to my above question. But overall from what I read so far, very few notes. This is very good and I couldn't have done it better myself!

nav2_smac_planner/include/nav2_smac_planner/constants.hpp

nav2_smac_planner/CMakeLists.txt

nav2_smac_planner/src/a_star.cpp

nav2_smac_planner/src/smac_planner_hybrid.cpp

nav2_smac_planner/src/smac_planner_lattice.cpp

stevedanomodolor · 2024-02-21T19:13:13Z

@stevedanomodolor what's the status here - do you want me to review in detail, have gaps that are TODO, or have some questions to discuss? I don't want to go through and nitpick some small issues if you're really looking for feedback elsewhere right now.

If you consider the general approach to be ok, then you can review it in detail. If the approach is good, what is just left is to modify the test to take into consideration these changes hench the todo in the CMakelists.

SteveMacenski · 2024-02-21T19:20:33Z

I think the analytic expansions might need to be rethought a bit. I think we should be taking all N of the goals and computing the analytic path, if valid. If any are valid, take the shortest one. There shouldn't be a loop surrounding the preamble which tells us if we want to do analytic expansions in this iteration:

      closest_distance = goal_distance_pair.second;
      NodePtr goal_node = goal_distance_pair.first;
      // We want to expand at a rate of d/expansion_ratio,
      // but check to see if we are so close that we would be expanding every iteration
      // If so, limit it to the expansion ratio (rounded up)
      int desired_iterations = std::max(
        static_cast<int>(closest_distance / _search_info.analytic_expansion_ratio),
        static_cast<int>(std::ceil(_search_info.analytic_expansion_ratio)));
      // If we are closer now, we should update the target number of iterations to go
      analytic_iterations =
        std::min(analytic_iterations, desired_iterations);

      // Always run the expansion on the first run in case there is a
      // trivial path to be found
      if (analytic_iterations <= 0) {

I think your logic is that if we sort by heuristic, then the first that comes back as a valid expansion will be the shortest. I think that would generally be true if the heuristic was a very purist implementation of a distance heuristic. But instead, we have the maximum of a few heuristics including cost information so the "closest" and the one with the "lowest travel cost" aren't necessarily the same thing. So I think largely these changes should be taken back to square one unfortunately and loop to find each of the N goals orientation's analytic expansion length (if valid) and then select the lowest cost one. Interestingly, you can use the new scoringFn to measure that for the final one to store. Luckily, there wasn't a huge number of changes you made to the analytic expansions, so its not a big setback at all and largely its just moving code around and measuring different things

So after

          while (min_turn_rad < max_min_turn_rad) {
            min_turn_rad += 0.5;  // In Grid Coords, 1/2 cell steps
            ompl::base::StateSpacePtr state_space;
            if (node->motion_table.motion_model == MotionModel::DUBIN) {
              state_space = std::make_shared<ompl::base::DubinsStateSpace>(min_turn_rad);
            } else {
              state_space = std::make_shared<ompl::base::ReedsSheppStateSpace>(min_turn_rad);
            }
            refined_analytic_nodes = getAnalyticPath(node, goal_node, getter, state_space);
            score = scoringFn(refined_analytic_nodes);
            if (score <= best_score) {
              analytic_nodes = refined_analytic_nodes;
              best_score = score;
            }
          }

You can use that best_score, store it for that particular angle to decide which to use.

SteveMacenski

I ran out of time this evening to review, but this is a few things -- also you have a number of linting issues I can see. Check CI for the full list of formatting problems

nav2_smac_planner/include/nav2_smac_planner/a_star.hpp

nav2_smac_planner/CMakeLists.txt

nav2_smac_planner/src/smac_planner_hybrid.cpp

SteveMacenski · 2024-02-28T02:56:11Z

Its also ready enough to update docs for the new variable for the mode to describe the mode, and the migration guide update to show this feature. An image/gif of this in action with the different modes would be great!

I looked through it and all looks good except the analytic expansions I didn't get to right now

jwallace42

Looks good!

I think you are missing some work for the distance heuristic.

The distance heuristic is pre computed based on free space. We current only calculate it for the the first goal. This means that we could artificially inflate the cost to go making the heuristic inadmissible.

My suggestion would be to remove the distance heuristic when we are in ALL_DIRECTION mode. For the BIDIRECTIONAL mode I would pre compute the distance for both angles and take the min of those two.

From what I have seen the distance heuristic is rarely greater than the obstacle heuristic so you probably haven't seen any issues.

nav2_smac_planner/src/a_star.cpp

SteveMacenski · 2024-03-08T00:58:27Z

Any questions or anything I can unblock on? 😄

mergify · 2024-03-09T19:22:11Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-09T21:54:27Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-10T04:25:16Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

stevedanomodolor · 2024-03-10T04:31:06Z

Any questions or anything I can unblock on? 😄

No blocking points, just making changes based on @jwallace42 feedback and testing them but after merging to the main and pulling the latest dockers, pr is not building.

mergify · 2024-03-10T04:36:36Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-10T19:15:18Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

SteveMacenski · 2024-03-11T19:52:15Z

Yeah there's a transient issue due to Rolling moving to 24.04 so a bunch of tooling and package indices are being messed with. Don't worry about it, its not your fault as long as it works locally. Just make sure to keep up on unit testing.

Want me to take a look again?

nav2_smac_planner/src/a_star.cpp

nav2_smac_planner/src/analytic_expansion.cpp

stevedanomodolor · 2024-03-12T07:47:16Z

Yeah there's a transient issue due to Rolling moving to 24.04 so a bunch of tooling and package indices are being messed with. Don't worry about it, its not your fault as long as it works locally. Just make sure to keep up on unit testing.

Want me to take a look again?

I will take advantage of the time to add more unit testing after making the modification you suggested. After the added unit tests, you can look into it.

mergify · 2024-03-23T04:32:48Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-24T13:46:14Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-24T14:08:44Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-24T15:04:30Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-24T17:49:25Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-25T19:17:28Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-25T19:33:33Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-25T19:41:28Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-25T19:59:18Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mergify · 2024-03-25T20:09:28Z

@stevedanomodolor, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

Signed-off-by: stevedan <[email protected]>

) Add header data to goal for short paths. Commit d8ae3c1 added the possibility to the rotation shim controller to rotate towards the goal when the goal was closer that the `forward_sampling_distance`. This feature was not fully working as the goal was missing proper header data, causing the rotation shim to give back control to the main controller. Co-authored-by: agennart <[email protected]>

* Added load and save panel Signed-off-by: Alberto Tudela <[email protected]> * Improved dock_panel state machine Signed-off-by: Alberto Tudela <[email protected]> * Added loading dock plugins log Signed-off-by: Alberto Tudela <[email protected]> * Redo UI Signed-off-by: Alberto Tudela <[email protected]> * Update tooltips Signed-off-by: Alberto Tudela <[email protected]> * Fix null-dereference Signed-off-by: Alberto Tudela <[email protected]> --------- Signed-off-by: Alberto Tudela <[email protected]>

Signed-off-by: Daniil Khaninaev <[email protected]>

…4724) Add frame_id to goal when rotating towards goal heading, otherwise the transform would fail. This bug was introduced in 30e2cde by not setting the frame_id. Signed-off-by: agennart <[email protected]> Co-authored-by: agennart <[email protected]>

…on_r1803809978 Signed-off-by: stevedan <[email protected]>

Signed-off-by: stevedan <[email protected]>

…ithub.com:stevedanomodolor/navigation2 into feat/smac_planner_include_orientation_flexibility

Signed-off-by: stevedan <[email protected]>

SteveMacenski · 2024-11-19T21:24:26Z

I just wanted to use the same goals to benchmark the current state of the stack and the changes I made.

But if you use a single goal, its not necessarily representative of randomness. If you have the same random seed at the start, then it should be deterministic.

The issue with this is that we assume that all the possible angles do not collide with the goal which is not the case because during the isinput valid stage, we remove goals in collision.

I guess this is where I'd handwave that the heuristic is an estimate, not an exact science - but this is a good point and a reason that if we don't see performance degradation we could do the for loop over each of the goal orientations for the distance heuristic, we can/should do that (which also simplifies code changes, which makes me happy 😄 ).

Why is that one ALL_DIRECTION_SmacHybrid so much higher than the others (20x)? This is also where maybe the goal non-randomness is working against you (the goal is at a really inconvenient location) rather than an actual problem in the software? I don't know though.

There was no significant difference between the computational time which makes me believe that the bottleneck in all directions is not in the distance heuristic computation stage but most probably is in the expansion stage in the planning loop.

It would be good to understand this to know that's the reason with some confidence. I don't disagree that could be a future improvement, but I'd like for us to at least understand if this is a correct assumption (and if not, maybe the issue is somewhere we can fix easily)

stevedanomodolor · 2024-11-20T06:02:36Z

I just wanted to use the same goals to benchmark the current state of the stack and the changes I made.

But if you use a single goal, its not necessarily representative of randomness. If you have the same random seed at the start, then it should be deterministic.

The issue with this is that we assume that all the possible angles do not collide with the goal which is not the case because during the isinput valid stage, we remove goals in collision.

I guess this is where I'd handwave that the heuristic is an estimate, not an exact science - but this is a good point and a reason that if we don't see performance degradation we could do the for loop over each of the goal orientations for the distance heuristic, we can/should do that (which also simplifies code changes, which makes me happy 😄 ).

Why is that one ALL_DIRECTION_SmacHybrid so much higher than the others (20x)? This is also where maybe the goal non-randomness is working against you (the goal is at a really inconvenient location) rather than an actual problem in the software? I don't know though.

I dont think it is though because i did two tests.

generated lots of random start and goal position using the map that is currently used for benchmarking the planners and still got similar results where the all directions is high. This was the initial result i sent.
the second one that i did was a known start and end goal with no obstacle. The reason i chose this to do the optimization is because in the previous case, there was a chance that the goalsset might be reduced because it might be in collision. This way I know that i am working in the worse case where there is no obstacle and i expand to all the bins. I did this just to have a reference. This is just for this test specifically.

I think the problem is we are trying to expand to multiple goals, we are jumping from 1 goals to the worst case 72 different goals(if we have 72 bins).
In both cases the all directions was significantly higher, the second is higher because no goal in collision and we are using all the goalset. This is what i suspect.

There was no significant difference between the computational time which makes me believe that the bottleneck in all directions is not in the distance heuristic computation stage but most probably is in the expansion stage in the planning loop.

It would be good to understand this to know that's the reason with some confidence. I don't disagree that could be a future improvement, but I'd like for us to at least understand if this is a correct assumption (and if not, maybe the issue is somewhere we can fix easily)

I think i can do just that, i will time the functions in the planning loop to see where rhe bottleneck is.

SteveMacenski · 2024-11-20T23:12:10Z

Yeah that sounds good to me. I generally agree that this is probably the issue, I just want to know for sure before we assume too much :-)

I'm trying to think of some strategies to speed this up (if this is the case): Check every-Nth bin rather than all 72? Full resolution granularity when you don't care about your orientation at all seems over kill. Then we could do a refinement step to check in the sliver that has the 2 lowest bounding costs. So for example, we check every 5th bin (drops the cost for checking during search when unsuccessful by 4/5ths). If any are valid, we check the bounding range only between the 2 shortest ones.

That way, normal searches that have no expanions possible completes N-1/Nx faster and we only do the dense checking for a smaller sliver once we know there is any valid solution. I'd aruge the probability that we have some single-orientation solution to the planning problem that its 2 neighbors on either side are not valid at all for is virtually non-existent in practice -- which in exchange we speed up our planning time again

stevedanomodolor · 2024-11-25T21:02:19Z

Yeah that sounds good to me. I generally agree that this is probably the issue, I just want to know for sure before we assume too much :-)

You are right on this. I assumed wrong. I did the following test for all the cases: default, bidirectional, and all_direction for the two planners. The start and end are on the left.

I measured the total time it took to call both the get_expansion and get_heuristic functions. The increase in execution time for both functions is more or less the same, but the get_heuristic function showed a significantly increase in comparison. This occurs in the all_direction mode, as the increase is not as pronounced in the bidirectional mode. By the way, I am using the default parameters provided on the Nav2 website. What I find strange is that the SMAC Hybrid planner performed much worse in all_direction mode compared to the SMAC Lattice planner.

<title></title>
<meta name="generator" content="LibreOffice 24.2.6.2 (Linux)"/>
<style type="text/css">
	body,div,table,thead,tbody,tfoot,tr,th,td,p { font-family:"Liberation Sans"; font-size:x-small }
	a.comment-indicator:hover + comment { background:#ffd; position:absolute; display:block; border:1px solid black; padding:0.5em;  } 
	a.comment-indicator { background:red; display:inline-block; border:1px solid black; width:0.5em; height:0.5em;  } 
	comment { display:none;  } 
</style>

	get heuristic time(ms)	get expansion time(ms)	?x heuristic	?x expansion
Default hybrid	0.841365	1.427716
Bidirectional hybrid	0.95309	1.517734	1.13279016835737	1.06305035455231
All direction hybrid	7.583123	12.685215	9.01288144859841	8.88497082052733
Default lattice	0.600979	1.27284
Bidirectional lattice	1.057823	1.427675	1.76016632860716	1.12164529713083
All direction lattice	2.145226	2.166438	3.569552347087	1.70205053266711

I'm trying to think of some strategies to speed this up (if this is the case): Check every-Nth bin rather than all 72? Full resolution granularity when you don't care about your orientation at all seems over kill. Then we could do a refinement step to check in the sliver that has the 2 lowest bounding costs. So for example, we check every 5th bin (drops the cost for checking during search when unsuccessful by 4/5ths). If any are valid, we check the bounding range only between the 2 shortest ones.

That way, normal searches that have no expanions possible completes N-1/Nx faster and we only do the dense checking for a smaller sliver once we know there is any valid solution. I'd aruge the probability that we have some single-orientation solution to the planning problem that its 2 neighbors on either side are not valid at all for is virtually non-existent in practice -- which in exchange we speed up our planning time again

Would try this, it should improve the overall I believe.

SteveMacenski · 2024-11-26T22:33:10Z

What I find strange is that the SMAC Hybrid planner performed much worse in all_direction mode compared to the SMAC Lattice planner.

The Hybrid-A* can have 64, 72, or other total bins it needs to check. The state lattice planner typically has ~16 since the primitives have to create a regularized lattice structure. You could do more, but typically 16 is sufficient. If you reduced Hybrid-A* to 16, do you see a similar result as the state lattice planner?

SteveMacenski · 2024-12-05T18:28:41Z

To summarize our call: We should do a course-to-fine search rather than going for all N (72) bins. We could introduce a new parameter for the analytic expansion that is the coarse search resolution (default: 4). If we find any valid path in that coarse search, then we do the full resolution. If we make it default to 4, it should have similar characteristics to the state lattice performance.

This should be relatively easy to implement using a queue and a while loop to replace the for loop, where it is initialized with every Nth goal orientation to start with. When the queue is empty at the end of the while loop, we can check if any expansion is valid. If so, then queue up the remaining non-Nth goal.

:-)

stevedanomodolor · 2024-12-15T18:32:00Z

What I find strange is that the SMAC Hybrid planner performed much worse in all_direction mode compared to the SMAC Lattice planner.

The Hybrid-A* can have 64, 72, or other total bins it needs to check. The state lattice planner typically has ~16 since the primitives have to create a regularized lattice structure. You could do more, but typically 16 is sufficient. If you reduced Hybrid-A* to 16, do you see a similar result as the state lattice planner?

yes, get the same result

SteveMacenski · 2024-12-17T19:30:33Z

Oh great - that means what we discussed will almost definitely improve performance to that level!

stevedanomodolor · 2024-12-18T07:37:31Z

I tried the improvement, and it did reduce the overall time. 🎉

Now, I am testing another idea to further reduce the time for the distance heuristic. What do you think:

The main issue with the current method of storing a loopup table that contains the minimum values for all directions is that the chosen minimum goal might still end up in collision. In addition during the isInputValid check, we discard goals that are in collision. As a result, the "minimum" value stored may not be valid.

I propose the following, the first lookup table stores the distance as is now. In addition to this, i create another lookup table that for each position (x, y, θ) to (x,y,theta) i store the index of the position of the loop up table but sorted from minimum to maximum distance.

During the isInputValid step, I create a boolean list that marks which goals are invalid (i.e., in collision) and gives this information to the distance heuristic.

Using the Second Table, when evaluating the getDistance heuristic, we iterate through the indices in the second lookup table for the given (x, y, θ). We pick the first index corresponding to a goal that is not marked as invalid in the boolean list.

I tried before to create another lookup table during the is input valid, but its takes a long time to do that loop.

stevedanomodolor marked this pull request as draft February 20, 2024 19:14

SteveMacenski requested changes Feb 21, 2024

View reviewed changes

SteveMacenski requested changes Feb 28, 2024

View reviewed changes

nav2_smac_planner/include/nav2_smac_planner/a_star.hpp Outdated Show resolved Hide resolved

nav2_smac_planner/CMakeLists.txt Outdated Show resolved Hide resolved

nav2_smac_planner/src/smac_planner_hybrid.cpp Outdated Show resolved Hide resolved

jwallace42 reviewed Mar 5, 2024

View reviewed changes

nav2_smac_planner/src/a_star.cpp Outdated Show resolved Hide resolved

stevedanomodolor requested review from SteveMacenski and jwallace42 March 10, 2024 22:39

SteveMacenski requested changes Mar 11, 2024

View reviewed changes

nav2_smac_planner/src/a_star.cpp Outdated Show resolved Hide resolved

nav2_smac_planner/src/a_star.cpp Show resolved Hide resolved

nav2_smac_planner/src/analytic_expansion.cpp Outdated Show resolved Hide resolved

stevedanomodolor marked this pull request as draft November 18, 2024 18:30

stevedanomodolor and others added 20 commits November 18, 2024 19:36

remove unnecessary local variable

e06f1db

Signed-off-by: stevedan <[email protected]>

dont need to break after throw

d5a3776

Signed-off-by: stevedan <[email protected]>

readd removed line

3acc50e

Signed-off-by: stevedan <[email protected]>

readd removed line

9419977

Signed-off-by: stevedan <[email protected]>

move line of code out of loop

18dba40

Signed-off-by: stevedan <[email protected]>

linter fixes

7c1f439

Signed-off-by: stevedan <[email protected]>

Added parameter rotate_to_heading_once (ros-navigation#4721)

9d6e75a

Signed-off-by: Daniil Khaninaev <[email protected]>

fix https://github.com/ros-navigation/navigation2/pull/4127\#discussi…

defa146

…on_r1803809978 Signed-off-by: stevedan <[email protected]>

remove unnecessary local variable

fd9d66f

Signed-off-by: stevedan <[email protected]>

dont need to break after throw

75a53aa

Signed-off-by: stevedan <[email protected]>

readd removed line

1f03314

Signed-off-by: stevedan <[email protected]>

readd removed line

cdcabc9

Signed-off-by: stevedan <[email protected]>

move line of code out of loop

124d163

Signed-off-by: stevedan <[email protected]>

linter fixes

38b94ec

Signed-off-by: stevedan <[email protected]>

include testing

44ec788

Signed-off-by: stevedan <[email protected]>

Merge branch 'feat/smac_planner_include_orientation_flexibility' of g…

18ef671

…ithub.com:stevedanomodolor/navigation2 into feat/smac_planner_include_orientation_flexibility

include more testing

a573dc3

Signed-off-by: stevedan <[email protected]>

Feat/smac planner include orientation flexibility #4127

Are you sure you want to change the base?

Feat/smac planner include orientation flexibility #4127

Conversation

stevedanomodolor commented Feb 20, 2024 • edited Loading

Basic Info

Description of contribution in a few bullet points

Description of documentation updates required from your changes

How to run

Future work that may be required in bullet points

For Maintainers:

SteveMacenski commented Feb 21, 2024 • edited Loading

SteveMacenski left a comment • edited Loading

Choose a reason for hiding this comment

stevedanomodolor commented Feb 21, 2024 • edited by SteveMacenski Loading

SteveMacenski commented Feb 21, 2024 • edited Loading

SteveMacenski left a comment

Choose a reason for hiding this comment

SteveMacenski commented Feb 28, 2024

jwallace42 left a comment • edited Loading

Choose a reason for hiding this comment

SteveMacenski commented Mar 8, 2024

mergify bot commented Mar 9, 2024

mergify bot commented Mar 9, 2024

mergify bot commented Mar 10, 2024

stevedanomodolor commented Mar 10, 2024 • edited Loading

mergify bot commented Mar 10, 2024

mergify bot commented Mar 10, 2024

SteveMacenski commented Mar 11, 2024 • edited Loading

stevedanomodolor commented Mar 12, 2024

mergify bot commented Mar 23, 2024

mergify bot commented Mar 24, 2024

mergify bot commented Mar 24, 2024

mergify bot commented Mar 24, 2024

mergify bot commented Mar 24, 2024

mergify bot commented Mar 25, 2024

mergify bot commented Mar 25, 2024

mergify bot commented Mar 25, 2024

mergify bot commented Mar 25, 2024

mergify bot commented Mar 25, 2024

SteveMacenski commented Nov 19, 2024 • edited Loading

stevedanomodolor commented Nov 20, 2024 • edited Loading

SteveMacenski commented Nov 20, 2024 • edited Loading

stevedanomodolor commented Nov 25, 2024

SteveMacenski commented Nov 26, 2024 • edited Loading

SteveMacenski commented Dec 5, 2024

stevedanomodolor commented Dec 15, 2024

SteveMacenski commented Dec 17, 2024

stevedanomodolor commented Dec 18, 2024

stevedanomodolor commented Feb 20, 2024 •

edited

Loading

SteveMacenski commented Feb 21, 2024 •

edited

Loading

SteveMacenski left a comment •

edited

Loading

stevedanomodolor commented Feb 21, 2024 •

edited by SteveMacenski

Loading

SteveMacenski commented Feb 21, 2024 •

edited

Loading

jwallace42 left a comment •

edited

Loading

stevedanomodolor commented Mar 10, 2024 •

edited

Loading

SteveMacenski commented Mar 11, 2024 •

edited

Loading

SteveMacenski commented Nov 19, 2024 •

edited

Loading

stevedanomodolor commented Nov 20, 2024 •

edited

Loading

SteveMacenski commented Nov 20, 2024 •

edited

Loading

SteveMacenski commented Nov 26, 2024 •

edited

Loading