ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hectpr mapping)?

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hectpr hector mapping)?

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Degub output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should by 0.00000 or 0.00100. It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Degub Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should by 0.00000 or 0.00100. It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should by 0.00000 or 0.00100. lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDITEDIT 1

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

EDIT 3

I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

FTCPlanner:
  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT 1

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

EDIT 3

I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

FTCPlanner:
  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false

EDIT 4

I used ROS indigo and Kinetic. With amcl and without amcl.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT 1

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

EDIT 3

I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

FTCPlanner:
  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false

EDIT 4

I used ROS indigo and Kinetic. With amcl and without amcl.

EDIT 5

Thanks for your measurements @scopus. This log calculation time is coused of to slow tf. Hector_mapping use often tf transformations. So tf is overwhelmed. If the planner moves with hector mapping and less wait time also good, you can use this as fix. But only if you use hector_mapping simultaneously. Because with less wait time it could be that ftc_planner use older positions to calculate the velocity. This can lead to bad/wrong path calculation. Maybe you can reduce the frequency of the calculation of hector_mapping. But this can lead to bad mapping results.

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT 1

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

EDIT 3

I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

FTCPlanner:
  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false

EDIT 4

I used ROS indigo and Kinetic. With amcl and without amcl.

EDIT 5

Thanks for your measurements @scopus. This log calculation time is coused of to slow tf. Hector_mapping use often tf transformations. So tf is overwhelmed. If the planner moves with hector mapping and less wait time also good, you can use this as fix. But only if you use hector_mapping simultaneously. Because with less wait time it could be that ftc_planner use older positions to calculate the velocity. This can lead to bad/wrong path calculation.

Maybe you can reduce the frequency of the calculation of hector_mapping. But this can lead to bad mapping results.

I consider if i can reduce the Transform calculation.

Answer

Thanks for your measurements @scopus. This log calculation time is occurs of to slow tf. Hector_mapping and ftc_planner use often tf transformations. So tf is overwhelmed. I have minimized the calls of tf transformations and put this changes for the moment in an new branch "fix_transformation". If I have test the changes in detail I will merge it to the master branch.

Old conversation

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?

EDIT 1

I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.

EDIT 2

My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.

EDIT 3

I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

FTCPlanner:
  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false

EDIT 4

I used ROS indigo and Kinetic. With amcl and without amcl.

EDIT 5

Thanks for your measurements @scopus. This log calculation time is coused of to slow tf. Hector_mapping use often tf transformations. So tf is overwhelmed. If the planner moves with hector mapping and less wait time also good, you can use this as fix. But only if you use hector_mapping simultaneously. Because with less wait time it could be that ftc_planner use older positions to calculate the velocity. This can lead to bad/wrong path calculation.

Maybe you can reduce the frequency of the calculation of hector_mapping. But this can lead to bad mapping results.

I consider if i can reduce the Transform calculation.