The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Hey murdock,
I think we should clarify a few things: the planner itself (and in general the complete navigation stack) cannot and is not intended to be integrated into Gazebo.
We need to separate between:
The former usually takes velocity commands (and for car-like robots often a steering angel) as controllable input. The robot low-level driver (talking about a real robot) now controls your robot according to this input (open-loop/closed-loop control) by e.g. generating torques at each wheel. A URDF file describes the kinematic structure and metrics of your robot such that we can apply transformations between important parts (laser-scanner, wheels etc.). The local planer generates a trajectory (w.r.t. a global plan, robot constraints and the changing environment) and provides the velocity profile for the robot-low-level interface. The robot interface and the local planner should be created completely independent of each other.
Now, if I got it right, you want to create a simulation model for your car-like robot. But this part should be completely independent of the chosen planner! You just replace your real robot with a model and provide the same low-level interface that accepts velocity commands. Here comes the tricky part, you must not only define the visual (and maybe dynamic) model of the robot, you also have to implement/simulate the controllers (open-loop or closed-loop) which move the robot according to the incoming velocity commands. For your car-like robot you might even control the steering angle of the front wheels. There are some controller plugins that can be integrated into gazebo (I am not a gazebo expert!).
In summary, I think you should first create your gazebo model without trying any planner. For testing your Gazebo model I suggest to command some pre-defiend velocity sequences for which you already know the movement. If you have the real car-like robot, the best approach would obviously be to record some demonstrations in order to verify your model later. Then if you have a working model, you can start with the configuring the planner (e.g. by the Tutorials and the teb_local_planner_tutorials package. According to the quote you added: I provide only stage navigation configurations since they do not have a lot of heavy dependencies and they are easily customizable. And I think it's enough to just demonstrate how working planner configurations can look like. With
easily extendable and integrable
I do not mean the creation but the inclusion of working gazebo models resp. URDF files. E.g., you can replace the stage node from the launch file with a gazebo configuration accepting the same control inputs (subscribing to cmd_vel topic, or if you check the car-like tutorial by adding a ackermann_msgs converter). Also adding a working URDF model just for visualization purposes is simple by just filling the robot_description parameter with the model url (see navigation tutorials).
Hope that helps.
| | 2 | No.2 Revision |
Hey murdock,
I think we should clarify a few things: the planner itself (and in general the complete navigation stack) cannot and is not intended to be integrated into Gazebo.
We need to separate between:
The former usually takes velocity commands (and for car-like robots often a steering angel) angle) as controllable input. The robot low-level driver (talking about a real robot) now controls your robot according to this input (open-loop/closed-loop control) by e.g. generating torques at each wheel.
A URDF file describes the kinematic structure and metrics of your robot such that we can apply transformations between important parts (laser-scanner, wheels etc.).
The local planer generates a trajectory (w.r.t. a global plan, robot constraints and the changing environment) and provides the velocity profile for the robot-low-level interface.
The robot interface and the local planner should be created completely independent of each other.
Now, if I got it right, you want to create a simulation model for your car-like robot. But this part should be completely independent of the chosen planner! You just replace your real robot with a model and provide the same low-level interface that accepts velocity commands. Here comes the tricky part, you must not only define the visual (and maybe dynamic) model of the robot, you also have to implement/simulate the controllers (open-loop or closed-loop) which move the robot according to the incoming velocity commands. For your car-like robot you might even control the steering angle of the front wheels. There are some controller plugins that can be integrated into gazebo (I am not a gazebo expert!).
In summary, I think you should first create your gazebo model without trying any planner. For testing your Gazebo model I suggest to command some pre-defiend velocity sequences for which you already know the movement. If you have the real car-like robot, the best approach would obviously be to record some demonstrations in order to verify your model later. Then if you have a working model, you can start with the configuring the planner (e.g. by the Tutorials and the teb_local_planner_tutorials package. According to the quote you added: I provide only stage navigation configurations since they do not have a lot of heavy dependencies and they are easily customizable. And I think it's enough to just demonstrate how working planner configurations can look like. With
easily extendable and integrable
I do not mean the creation but the inclusion of working gazebo models resp. URDF files. E.g., you can replace the stage node from the launch file with a gazebo configuration accepting the same control inputs (subscribing to cmd_vel topic, or if you check the car-like tutorial by adding a ackermann_msgs converter). Also adding a working URDF model just for visualization purposes is simple by just filling the robot_description parameter with the model url (see navigation tutorials).
Hope that helps.
| | 3 | No.3 Revision |
Hey murdock,
I think we should clarify a few things: the planner itself (and in general the complete navigation stack) cannot and is not intended to be integrated into Gazebo.
We need to separate between:
The former usually takes velocity commands (and for car-like robots often a steering angle) as controllable input. The robot low-level driver (talking about a real robot) now controls your robot according to this input (open-loop/closed-loop control) by e.g. generating torques at each wheel. A URDF file describes the kinematic structure and metrics of your robot such that we can apply transformations between important parts (laser-scanner, wheels etc.). The local planer generates a trajectory (w.r.t. a global plan, robot constraints and the changing environment) and provides the velocity profile for the robot-low-level interface. The robot interface and the local planner should be created completely independent of each other.
Now, if I got it right, you want to create a simulation model for your car-like robot. But this part should be completely
independent of the chosen planner! You just replace your real robot with a model and provide the same low-level interface that accepts velocity commands.
Here comes the tricky part, you must not only define the visual (and maybe dynamic) model of the robot, you also
have to implement/simulate the controllers (open-loop or closed-loop) closed-loop, numerical integration) which move the robot according to the incoming velocity commands. For your car-like robot you might even control the steering angle of the front wheels.
There are some controller plugins that can be integrated into gazebo (I am not a gazebo expert!).
In summary, I think you should first create your gazebo model without trying any planner. For testing your Gazebo model I suggest to command some pre-defiend velocity sequences for which you already know the movement. If you have the real car-like robot, the best approach would obviously be to record some demonstrations in order to verify your model later. Then if you have a working model, you can start with the configuring the planner (e.g. by the Tutorials and the teb_local_planner_tutorials package. According to the quote you added: I provide only stage navigation configurations since they do not have a lot of heavy dependencies and they are easily customizable. And I think it's enough to just demonstrate how working planner configurations can look like. With
easily extendable and integrable
I do not mean the creation but the inclusion of working gazebo models resp. URDF files. E.g., you can replace the stage node from the launch file with a gazebo configuration accepting the same control inputs (subscribing to cmd_vel topic, or if you check the car-like tutorial by adding a ackermann_msgs converter). Also adding a working URDF model just for visualization purposes is simple by just filling the robot_description parameter with the model url (see navigation tutorials).
Hope that helps.
| | 4 | No.4 Revision |
Hey murdock,
I think we should clarify a few things: the planner itself (and in general the complete navigation stack) cannot and is not intended to be integrated into Gazebo.
We need to separate between:
The former usually takes velocity commands (and for car-like robots often a steering angle) as controllable input. The robot low-level driver (talking about a real robot) now controls your robot according to this input (open-loop/closed-loop control) by e.g. generating torques at each wheel. A URDF file describes the kinematic structure and metrics of your robot such that we can apply transformations between important parts (laser-scanner, wheels etc.). The local planer generates a trajectory (w.r.t. a global plan, robot constraints and the changing environment) and provides the velocity profile for the robot-low-level interface. The robot interface and the local planner should be created completely independent of each other.
Now, if I got it right, you want to create a simulation model for your car-like robot. But this part should be completely independent of the chosen planner! You just replace your real robot with a model and provide the same low-level interface that accepts velocity commands. Here comes the tricky part, you must not only define the visual (and maybe dynamic) model of the robot, you also have to implement/simulate the controllers (open-loop or closed-loop, numerical integration) which move the robot according to the incoming velocity commands. For your car-like robot you might even control the steering angle of the front wheels. There are some controller plugins that can be integrated into gazebo (I am not a gazebo expert!).
In summary, I think you should first create your gazebo model without trying any planner.
For testing your Gazebo model I suggest to command some pre-defiend velocity sequences for which you already know the movement. If you have the real car-like robot, the best approach would obviously be to record some demonstrations in order to verify your model later.
Then if you have a working model, you can start with the configuring the planner (e.g. by refer to the Tutorials and the teb_local_planner_tutorials package.
package).
According to the quote you added: I provide only stage navigation configurations since they do not have a lot of heavy dependencies and they are easily customizable. And I think it's enough to just demonstrate how working planner configurations can look like. With
easily extendable and integrable
I do not mean the creation but the inclusion of working gazebo models resp. URDF files. E.g., you can replace the stage node from the launch file with a gazebo configuration accepting the same control inputs (subscribing to cmd_vel topic, or if you check the car-like tutorial by adding a ackermann_msgs converter). Also adding a working URDF model just for visualization purposes is simple by just filling the robot_description parameter with the model url (see navigation tutorials).
Hope that helps.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
