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]>

SteveMacenski

Overall looks really good to me, I have a couple of small changes and after that the next review I'll go into detail line by line to make sure we didn't miss anything subtle, but its largely code I've already reviewed pre-coarse search and approved, so its more just for my piece of mind (and don't expect to find any issues).

Please pull in the updates from the main branch (some smac optimizations were made) and benchmark against your changes with main pulled in and the new main itself. If they are similar/same/better, then this is good to go!

SteveMacenski · 2025-01-29T19:21:42Z

nav2_smac_planner/src/smac_planner_lattice.cpp

+  _goal_heading_mode = fromStringToGH(goal_heading_type);
+
+  nav2_util::declare_parameter_if_not_declared(
+    node, name + ".coarse_search_resolution", rclcpp::ParameterValue(4));


for both planners: check that this is an exact increment of the lattice or hybrid primitive set (i.e. equally divisible so that we don't end up with like prim_set.size() / coarse_resolution = 2.3535. It should be 2 or 3). Otherwise, in the code, we need to explicitly set a policy for handling this. overall though, I think its a misconfiguration if someone selects something non-exact, so throwing and failing to configure / do a param update seems OK

Also for the lattice planner: I think this should default to the lattice's size and not do coarse resolution (so default = 1 whereas hybrid = 4). The doc PR should be updated accordingly

What of the situations where some goals are invalid because they are in a collision and we prune them earlier? This would not be valid right?. Currently, I divide with the valid number of goals(to make the search as equally distributed as possible) and not the whole angular binprepareGoalsForExpansion).

I think the behavior should be that the goals_to_expand is based on the even-distribution of primitives. If a primitive at a position was pruned due to collision, then it should be skipped, not replaced with a nearby one.

That way, which of the primitives used is deterministic, regardless of collision state of the goal, which may change based on request. We always use the 'every-Nth' the user sets, but if its in collision, then its just not attempted.

In setGoals the _goals_vector should be the full set. Its pruned in areInputsValid before we currently do the prepareGoalsForExpansion.

To resolve that, I think (a) the preparation of goals to expand should be done before the areInputsValid method is called (probably not good), (b) do the preparation inside of areInputsValid's loop since we're already in a for loop for _goals_set which could be changed to _goals_vector, or (c) we have an _raw_goals_vector and _goals_vector to store the goals separately unpruned to use in the coarse preparation.

Separately, I'm thinking maybe we should do this a little more clearly while we're making this change.

Having prepareGoalsForExpansion return coarse_search_goal_size to denote where the coarse then fine search nodes are separated could be improved. I think either:

We should return 2 vectors: the coarse list and the fine list. Coarse used when coarse searching. Coarse+fine used for fine searching (though I think coarse is already exhausted from your current implementation, so functionally just the 'fine' list).

We should have the vector stored object have a field for indicating coarse or fine that can be referenced in the iteration for coarse serach and skip if its a fine-search node. Then we only pass into tryAnalyticExpansion the vector and change the while condition into a for-each and continue; if the goal is fine. This would be a new struct containing the node + the coarse/fine state. I think the 2x vectors in my first point is subjectively better, but I'm pretty ambivalent as to which.

Besides the first point, I only use the goals vector for the coarse expansion actually because I needed a vector that stored the goals in order. I will go with C but with two vectors, one that stores the raw goals vector and another vector of boolean that stores if a goal is valid or not. I can use this info for the preparation of the coarse and fine list in the next stage, what do you think?

Besides the second point, I think the first option works fine for me, clearer to understand, to return two vector.

If you're going to go that route, it shouldn't be 2 separate vectors, but one vector with a struct containing the goal & the collision state. 2 vectors that 'zip' together is not very clear that they're associated. Structs make sense because the collision state is an attribute of the goal, so they should be bundled together.

struct GoalState { NodePtr goal; // <-- or whatever we need to store here, I think this is right though bool is_valid = true; // default to valid } typedef GoalStates std::vector<Goal>;

Then in the areInputsValid, we set the is_valid state to false instead of deleting the goals vector entry.

I love this approach.

nav2_smac_planner/src/smac_planner_lattice.cpp

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

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

nav2_smac_planner/src/smac_planner_hybrid.cpp

nav2_smac_planner/src/smac_planner_lattice.cpp

SteveMacenski · 2025-02-05T20:20:23Z

nav2_smac_planner/src/smac_planner_lattice.cpp

+  _goal_heading_mode = fromStringToGH(goal_heading_type);
+
+  nav2_util::declare_parameter_if_not_declared(
+    node, name + ".coarse_search_resolution", rclcpp::ParameterValue(4));


I think the behavior should be that the goals_to_expand is based on the even-distribution of primitives. If a primitive at a position was pruned due to collision, then it should be skipped, not replaced with a nearby one.

That way, which of the primitives used is deterministic, regardless of collision state of the goal, which may change based on request. We always use the 'every-Nth' the user sets, but if its in collision, then its just not attempted.

In setGoals the _goals_vector should be the full set. Its pruned in areInputsValid before we currently do the prepareGoalsForExpansion.

To resolve that, I think (a) the preparation of goals to expand should be done before the areInputsValid method is called (probably not good), (b) do the preparation inside of areInputsValid's loop since we're already in a for loop for _goals_set which could be changed to _goals_vector, or (c) we have an _raw_goals_vector and _goals_vector to store the goals separately unpruned to use in the coarse preparation.

Separately, I'm thinking maybe we should do this a little more clearly while we're making this change.

Having prepareGoalsForExpansion return coarse_search_goal_size to denote where the coarse then fine search nodes are separated could be improved. I think either:

We should return 2 vectors: the coarse list and the fine list. Coarse used when coarse searching. Coarse+fine used for fine searching (though I think coarse is already exhausted from your current implementation, so functionally just the 'fine' list).

We should have the vector stored object have a field for indicating coarse or fine that can be referenced in the iteration for coarse serach and skip if its a fine-search node. Then we only pass into tryAnalyticExpansion the vector and change the while condition into a for-each and continue; if the goal is fine. This would be a new struct containing the node + the coarse/fine state. I think the 2x vectors in my first point is subjectively better, but I'm pretty ambivalent as to which.

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

SteveMacenski · 2025-02-11T01:06:13Z

nav2_smac_planner/src/smac_planner_lattice.cpp

+  node->get_parameter(name + ".goal_heading_mode", goal_heading_type);
+  _goal_heading_mode = fromStringToGH(goal_heading_type);
+
+  nav2_util::declare_parameter_if_not_declared(


Default = 1 for lattice so that we do all resolution

SteveMacenski · 2025-02-11T01:12:16Z

nav2_smac_planner/src/smac_planner_lattice.cpp

+  _goal_heading_mode = fromStringToGH(goal_heading_type);
+
+  nav2_util::declare_parameter_if_not_declared(
+    node, name + ".coarse_search_resolution", rclcpp::ParameterValue(4));


If you're going to go that route, it shouldn't be 2 separate vectors, but one vector with a struct containing the goal & the collision state. 2 vectors that 'zip' together is not very clear that they're associated. Structs make sense because the collision state is an attribute of the goal, so they should be bundled together.

struct GoalState { NodePtr goal; // <-- or whatever we need to store here, I think this is right though bool is_valid = true; // default to valid } typedef GoalStates std::vector<Goal>;

Then in the areInputsValid, we set the is_valid state to false instead of deleting the goals vector entry.

SteveMacenski · 2025-02-11T01:13:39Z

nav2_smac_planner/src/a_star.cpp

+  if (_coarse_search_resolution <= 0) {
+    throw nav2_core::PlannerException("Invalid coarse search resolution, Cannot be <= 0");
+  }
+  else if(goal_heading_mode != GoalHeadingMode::ALL_DIRECTION) {


the } and else if should be on the same line

SteveMacenski · 2025-02-11T01:22:03Z

nav2_smac_planner/src/analytic_expansion.cpp

+          current_best_goal = current_goal_node;
+          current_best_node = node;
+          found_valid_expansion = true;
+          break;


Note: the break here then wouldn't attempt all coarse resolutions, it ends early. We'd need to iterate through the full set so we actually get the "best" one -- since in the 'fine search' we don't reattempt any of the coarse resolutions. They're simply skipped and could actually be better than the first one found.

Also, I think this should be updated to store the current best if its better than the last score. refineAnalyticPath should be responsible for attempting to refine the path and then returning the best score and its nodes only. Instead, it should have a return of best_score that we compare to our current best score and only update current_best_* if its an improvement. We do that in the fine search but not sure why we don't do that here as well.

SteveMacenski · 2025-02-11T01:24:51Z

nav2_smac_planner/src/analytic_expansion.cpp

+  const NodeGetter & getter,
+  NodePtr & node,
+  AnalyticExpansionNodes & analytic_nodes,
+  float & best_score


To that end, best_score should be a return type (it doesn't need to have input argument at all)

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

…ility

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

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 Outdated Show resolved Hide resolved

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

stevedanomodolor added 3 commits January 25, 2025 12:50

fix test

a88928e

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

update test file

f358765

cahnge to reszie

b81f52e

stevedanomodolor requested a review from SteveMacenski January 25, 2025 21:02

stevedanomodolor marked this pull request as ready for review January 25, 2025 21:03

SteveMacenski reviewed Jan 29, 2025

View reviewed changes

stevedanomodolor added 2 commits February 5, 2025 06:50

minor changes in coarse search resolution

009a8a9

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

minor changes in coarse search resolution , missing changes in lattic…

ffb9ac0

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

SteveMacenski linked an issue Feb 5, 2025 that may be closed by this pull request

[Smac Planner] Enable goal orientation non-specificity #3789

Open

SteveMacenski reviewed Feb 5, 2025

View reviewed changes

remove throw

27bdcd7

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

SteveMacenski reviewed Feb 11, 2025

View reviewed changes

SteveMacenski requested changes Feb 11, 2025

View reviewed changes

stevedanomodolor added 17 commits February 17, 2025 21:54

wip

3f57df9

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

Merge branch 'main' into feat/smac_planner_include_orientation_flexib…

3b3d8df

…ility

wip

470ecbf

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

cleanup and include granularity

60a266f

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

formmatting

3cea247

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

change default value

b4651bd

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

WIP

c3c7f0a

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

WIP

cced727

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

WIP

82b361a

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

fixed issue with test

fa1efc7

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

more testing

b032d9c

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

more testing

b6e70ac

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

fix test

33076f9

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

include more testing

ec8a174

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

fix typo

ec0fc7b

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

include more testing

b9a4993

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

include more testing

c4eff1b

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 left a comment

Choose a reason for hiding this comment

SteveMacenski Jan 29, 2025 • edited Loading

Choose a reason for hiding this comment

stevedanomodolor Feb 5, 2025

Choose a reason for hiding this comment

SteveMacenski Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

stevedanomodolor Feb 7, 2025

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

stevedanomodolor Feb 17, 2025

Choose a reason for hiding this comment

SteveMacenski Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

SteveMacenski Feb 11, 2025

Choose a reason for hiding this comment

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 Jan 29, 2025 •

edited

Loading

SteveMacenski Feb 5, 2025 •

edited

Loading

SteveMacenski Feb 11, 2025 •

edited

Loading

SteveMacenski Feb 5, 2025 •

edited

Loading

SteveMacenski Feb 11, 2025 •

edited

Loading

SteveMacenski Feb 11, 2025 •

edited

Loading