Skip to content

Ackermann cost update#3497

Closed
ObeidHaidar wants to merge 1 commit intoros-navigation:humblefrom
ObeidHaidar:patch-1
Closed

Ackermann cost update#3497
ObeidHaidar wants to merge 1 commit intoros-navigation:humblefrom
ObeidHaidar:patch-1

Conversation

@ObeidHaidar
Copy link
Contributor

Is the cost when using an Ackermann motion model meant to be modified twice?

Basic Info

Info Please fill out this column
Ticket(s) this addresses none
Primary OS tested on Ubuntu
Robotic platform tested on custom hardware

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

Is the cost when using an Ackermann motion model meant to be modified twice?
@mergify
Copy link
Contributor

mergify bot commented Mar 22, 2023

@ObeidHaidar, all pull requests must be targeted towards the main development branch.
Once merged into main, it is possible to backport to @humble, but it must be in main
to have these changes reflected into new distributions.

@ObeidHaidar
Copy link
Contributor Author

Also @SteveMacenski , this probably isn't the right place to ask, but any recommendation for trying to increase the prediction horizon? The current horizon doesn't work as good when controlling robots with a bigger footpath.

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please target the main branch as the bot indicates. I'll backport to Humble immediately but as a point of process to keep the git history clean it needs to go there first

(std::move(out_of_max_bounds_motion) +
std::move(out_of_min_bounds_motion)) *
data.model_dt, {1}, immediate) * weight_, power_);
else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linting issue, if nothing else } else {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'll fix it and add pull request to main. Just wanted to double check that it's not done on purpose. I'll add a return instead of an else statement and will create a new pull request to main.

@SteveMacenski
Copy link
Member

SteveMacenski commented Mar 22, 2023

any recommendation for trying to increase the prediction horizon? The current horizon doesn't work as good when controlling robots with a bigger footpath.

Sure, do it! You can increase the number of trajectory timesteps, though it comes obviously with proportionally higher computational costs. Prediction horizon = time_steps * model_dt

@ObeidHaidar ObeidHaidar mentioned this pull request Mar 22, 2023
7 tasks
@ObeidHaidar ObeidHaidar deleted the patch-1 branch March 22, 2023 02:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants