Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

min. turning radius higher than 5m #14

Closed
glebos opened this issue Aug 10, 2016 · 5 comments
Closed

min. turning radius higher than 5m #14

glebos opened this issue Aug 10, 2016 · 5 comments

Comments

@glebos
Copy link

glebos commented Aug 10, 2016

Hello,

is it possible to apply a min. turning radius higher than 5m?

Kind regards.
@beetleskin
Copy link

Speaking of config limits, is there a reason to limit the velocity to 2m/ss?

@croesmann
Copy link
Member

There are no theoretical reasons for the limits. I set them according to my use cases and haven't thought about general cases in the past.

According to the min turning radius there are just practical limitations:
If the minimum turning radius is substantially high (hence only small steering angles are allowed) the problem size drastically increases: The trajectory length could be huge since the robot must often switch moving directions (alternating forward and backward motions) in order to achieve a desired pose. Despite the fact that the computation time increases, the constraint approximation could be less restrictive and hence leading to solutions that are not feasible for the real robot.

I am going to update the code soon, since currently I do not have spare-time left.
Same for issue #15.

@croesmann
Copy link
Member

I changed the upper bounds in commit 216fe3d.
If you need further adjustments, please let me know.

Note, optimization weights and dt_ref as well as dt_hyst are not
tuned for velocities and accelerations beyond the default values (e.g. >1 m/s).
Just increasing the maximum velocity bounds without adjusting the other parameters might lead to an insufficient behavior.

@beetleskin
Copy link

Thanks a lot for the adjustments. Do you have further suggestions when driving with lets say 20m/s?

@glebos
Copy link
Author

glebos commented Sep 9, 2016

Thank you very much for the adjustments, appreciate it!

croesmann added a commit that referenced this issue Dec 23, 2016
@croesmann
Indigo - Kinetic Synchronization (#34)
522a97a 
Backporting kinetic features to indigo

* Support for omnidirectional drives

* Changed inner velocity storage object to geometry_msgs::Twist to also account for the strafing velocity (and later acceleration). This change caused some function prototype modifications.

* Limiting y-acceleration (strafing acceleration) is now supported if holonomic mode is enabled (vel_max_y > 0)

* Increased bounds of many variables in dynamic_reconfigure. Resolves #14.
The particular variables are maximum velocities, maximum accelerations,
minimum turning radius,...
Note: optimization weights and dt_ref as well as dt_hyst are not
tuned for velocities and accelerations beyond
the default values (e.g. >1 m/s). Just increasing the maximum velocity
bounds without adjusting the other parameters leads to an insufficient behavior.

* Removed inline flags in timed_elastic_band.cpp. Fixes #15.

* Removed inline flags in visualization.cpp

* HomotopyClassPlanner public interface extended

* Removed TebConfig dependency in TebVisualization

* Added intermediate edge layer for unary, binary and multi edges in order to reduce code redundancy.

* Added an option to compute the actual arc length
instead of using the Euclidean distance approximation.
The actual arc length is then used for computing velocities, accelerations
and the turning radius.

* Obstacle edge creation code moved to a legacy method

* New default obstacle association strategy.
During optimization graph creation, for each pose of the trajectory a
relevance detection is performed before considering the obstacle
during optimization. New parameters are introduced. The
old strategy is kept as 'legacy' strategy (see parameters).

* update of default parameters for 'costmap_obstacles_behind_robot_dist'

* Added a warning if the optim footprint + min_obstacle_dist is smaller than the costmap footprint.
Validation is performed by only comparing the inscribed radii of the footprints.

* Weight adaptation added for obstacles edges.
Added parameter 'weight_adapt_factor'.
Obstacle weights are scaled repeatedly scaled by this factor in each outer TEB iteration.
Increasing weights iteratively instead of setting a huge value a-priori leads to better numerical conditions.

* Changed HSignature to a generic equivalence class

* Updated the TEB selection in the HomotopyClassPlanner.
* A new parameter is introduced to prefer the equivalence class of the initial plan
* Fixed some bugs related to the deletion of candidates and
  for keeping the equivalence class of the initial plan.

* pose2d class extended

* The trajectory is now initialized backwards for goals close to and behind the robot.
Parameter 'allow_init_with_backwards_motion' added.

* Horizon reduction for resolving infeasible trajectories is not activated anymore if the global goal is already selected
(to avoid oscillations due to changing final orientations)

* fixed wrong matrix assignment that caused a crash of the planner

* max_samples parameter added

* global plan orientations are now taken for TEB initialization if lobal_plan_overwrite_orientation==true

* fixed same wrong assignment as in commit #5f8ad55a7cc26849331b82f7054243703c132af7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@beetleskin @croesmann @glebos