Implement ROS on a custom Robot: what steps?

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

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.

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

Lorenz

22731 ●129 ●202 ●316 http://ias.in.tum.de/p...

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

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

Comments

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 ( 2012-11-26 02:01:59 -0600 )edit

add a comment

Implement ROS on a custom Robot: what steps?

1 Answer

Comments

Question Tools

Stats

Related questions

Implement ROS on a custom Robot: what steps? edit

1 Answer

Comments

Question Tools

Stats

Related questions

Implement ROS on a custom Robot: what steps?