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

Revision history [back]

Here's my insight:

Software:

--Currently only Indigo is supported on 14.04. You can build the source from scratch for hydro, but its simpler to just use indigo.

--The Nav Stack that already comes with ROS is what you should use.

-- If your talking about the actual tutorials for the nav stack, here it is. If you are talking about a downloadable ros package, I personally really like clearpath robotics husky package. Although its not named tutorial, there are multiple launch files with various configurations for almost all purposes (odom only, odom and gmapping, amcl, etc...). They also give you a already set up model of their husky robot ready to be used in gazebo. I use it myself if i dont feel like plugging in my robot. If you have any questions about that let me know. Ill be glad to help.

Config

-- For people who are new to ROS, I would recommended writing a tf_publisher node that broadcasts all of the transforms from your sensors to your base_link frame. That way they will clearly see where all their data will be going.

-- Make a node that grabs your encoder ticks (motor controller node) and then make a geometry_msgs/Twist message out of that. Then send that to your odometry node, where you can follow the ros tutorial how to get position x, y, z and velocity vx, vy, vz.

-- I currently am using robot_pose_ekf for kalman filtering, but being a beginner and not understanding at all how and why robot_pose_ekf works the way it does with not publishing a odometry message but pose with covariance stamped (PWCS), Robot_Localization would be alot easier for students to understand. Unlike robot_pose_ekf, it does not limit you to the amount of sensors you can have as inputs to the filter. Also, it publishes a odometry message (versus PWCS), which will cause a lot less confusion after going through the navigation tutorials for the first time.

-- Arduino imu should be okay. If you are going to use it, I can give you some advice on how to use it in robot_localization since that imu may be noisy, and how to configure it for your scenario.

-- For encoders, its pretty much a repeat of what I said before. Personally, I like to keep wheel_encoder data in its own node, and odometry as its own node as well.

-- Not fimiliar with using ros on arduino, so can you explain what you want with the base_controller part a little more?

Hope this helps.