ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Implement ROS on a custom Robot: what steps?

asked 2012-11-22 21:33:13 -0500

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

Hi everybody. The robotics lab at my university has designed a custom platform some years ago, and has been using it for many experiments ever since. Now the time has come to make it more accessible and easily interface-able, so the idea was to try ROS.

Now given the fact that it's completely custom, I have to develop (almost) all the drivers and nodes.

My question arises from the fact that it's totally obscure to me what is necessary and what is not necessary in the ROS environment. Theoretically I could make a custom node with custom messages, but that would make the node almost unusable.

So I have been reading about the robot_state_publisher and urdf and tf. And the robot we are talking about is just a simple diff-drive 1 link bot (roomba style) so I guess both URDF and RSP are overkill, I think just publishing the TF should suffice but I'm not sure.

Also the real tf is not generated by the robot, rather by an external algorithm tracking the robot in the environment from video feeds; so I guess that in my case the TF should not even be published by the robot itself (which then becomes an "actuator" node) and rather by the algorithm that really knows the robot pose, right?

I know I'm confused, you don't have to tell me that :P I keep reading lots and lots of wiki pages and tutorials, but it is still quite unclear what are the "core" features any robot should have in ROS.

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2012-11-22 22:15:13 -0500

Lorenz gravatar image

updated 2012-11-22 22:16:54 -0500

Basically, the number of nodes you have to implement depends on what you want to do with your robot. In your case, I would at least implement the following nodes:

  • A driver for the robot's base. It should subscribe to the topic /cmd_vel of type geometry_msgs/Twist. Whenever it receives commands on that topic, it should move accordingly. Don't forget to add a watchdog to stop the robot when it doesn't receive messages for, say, 0.5 seconds :) This will allow you to use ROS for teleoperating your robot and for using move_base. However, move_base works best if you have a 3D sensor on your robot that can be used for obstacle detection and avoidance.

  • I would definitely create a URDF file. It's not that much work and as benefits, you get nice visualization in rviz and maybe even simulation using gazebo. And you get the static transforms in your TF tree published by the robot_state_publisher for free if your robot has any sensors. Creating a URDF file for simple robots is not much work (maybe around 1 or 2 hours) and it's definitely worth it.

  • As I understand it, you are localizing your robot globally using something like a camera. While the robot_state_publisher publishes the transforms in your robot, your localization algorithm should be a second TF publisher that only publishes a transform such as /world -> /base_link

edit flag offensive delete link more


Thank you Lorenz, again this is very exhaustive. But I still have a problem understanding exactly why would I need a robot_state_publisher if I have just one coordinate frame.

Claudio gravatar image Claudio  ( 2012-11-26 02:01:59 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2012-11-22 21:33:13 -0500

Seen: 1,208 times

Last updated: Nov 22 '12