Revision history [back]

You're close, but let me clear up a few things. You're right that ROS is a huge thing, so you should prepare yourself regarding how much troubleshooting you'll have to do to make everything work.

RVIZ is simply a visualization tool. Technically you don't need it all to run the Navigation stack which will do what you're talking about. The nodes that do the mapping, pathfinding, obstacle avoidance, and closed loop control are in the Navigation stack, but they publish data that RVIZ can use to show what is happening.

You don't mention any sensors that will generate odometry data. While there is a node that can generate odom data from laser scans, I think you'll find that the neato lidar is too slow to get acceptable results without sensor based odom data. I use encoders on the wheel-drive motors, and I think that is pretty standard, but you could also use an IMU to get the data.

http://wiki.ros.org/navigation/Tutorials

Follow the navigation stack tutorial line by line, and follow every link in the tutorial where additional detail is provided. These links include things like setting to odom publisher, creating a map, etc. It's a good way to start.

You're close, but let me clear up a few things. You're right that ROS is a huge thing, so you should prepare yourself regarding how much troubleshooting you'll have to do to make everything work.

RVIZ is simply a visualization tool. Technically you don't need it all to run the Navigation stack which will do what you're talking about. The nodes that do the mapping, pathfinding, obstacle avoidance, and closed loop control are in the Navigation stack, but they publish data that RVIZ can use to show what is happening.

You don't mention any sensors that will generate odometry data. While there is a node that can generate odom data from laser scans, I think you'll find that the neato lidar is too slow to get acceptable results without sensor based odom data. I use encoders on the wheel-drive motors, and I think that is pretty standard, but you could also use an IMU to get the data.

http://wiki.ros.org/navigation/Tutorials

Follow the navigation stack tutorial line by line, and follow every link in the tutorial where additional detail is provided. These links include things like setting to odom publisher, creating a map, etc. It's a good way to start.

You're close, but let me clear up a few things. You're right that ROS is a huge thing, so you should prepare yourself regarding how much troubleshooting you'll have to do to make everything work.

RVIZ is simply a visualization tool. Technically you don't need it all to run the Navigation stack which will do what you're talking about. The nodes that do the mapping, pathfinding, obstacle avoidance, and closed loop control are in the Navigation stack, but they publish data that RVIZ can use to show what is happening.

You don't mention any sensors that will generate odometry data. While there is a node that can generate odom data from laser scans, I think you'll find that the neato lidar is too slow to get acceptable results without sensor based odom data. I use encoders on the wheel-drive motors, and I think that is pretty standard, but you could also use an IMU to get the data.

http://wiki.ros.org/navigation/Tutorials

Follow the navigation stack tutorial line by line, and follow every link in the tutorial where additional detail is provided. These links include things like setting to odom publisher, creating a map, etc. It's a good way to start.

Update after follow on question:

You will need to model your robot in a sense, but then again no.

1 - For the path planning, the node needs to know the shape of the robot, so there is a line to enter the robot shape in one of the YAML files I think. Don't remember which file but it is discussed in the tutorials so you'll be told about it before you need it,

2 - ROS units are in meters and quaternions. If you have a robot that takes commands and issues odometry directly in meters and quaternions then you do not need to model the drive of the robot. Otherwise you will need to provide nodes that do the conversions from meters/sec and quaternions to what ever units your robot works with. In my case, I get motor position data in encoder counts and have a node that converts to position, velocity and angle that gets published on odom topic. I have another node that subscribes to the cmd_vel topic that converts that data to encoder counts/sec for each motor and sends it to robot. So in a sense, I had to model the drive of the robot.

3 - Once the robot is navigating, you'll find that you need to tune some parameters to optimize performance. Again this not modeling the robot, but requires setup based on your robot.