Revision history [back]

A robot driver (but that is what we're talking about here) typically only needs to publish JointState messages, the rest will be taken care of by the robot_state_publisher (using forward kinematics).

An exception to this would be if you have 'strange' joint types which cannot be modelled properly in urdf or for which it doesn't make sense to go through JointState msgs first: then the driver would have to publish the corresponding TF frames itself (and the joints should not be part of the urdf in that case).

So having a robot_description parameter with a valid urdf, your driver + RSP should be enough to make RViz happy (and result in a working system, at least for displaying robot state).

and also write a subscriber to /joint_states that moves the actual arm.

I'm a little confused by this: /joint_states is for reporting state of your robot, not for controlling it.

So having a robot_description parameter with a valid urdf, your driver + RSP should be enough to make RViz happy (and result in a working system, at least for displaying robot state).

and also write a subscriber to /joint_states that moves the actual arm.

I'm a little confused by this: /joint_states is for reporting state of your robot, not for controlling it.

Edit:

Okay, so i was using joint_state_publisher before to change the arms location on rviz, but that's only changing what's reported by the robot?

Well, that depends on what you consider "the robot": if you're just playing with your urdf, then you typically use the JSP to publish some fake JointState msgs where the values are taken from the sliders in the GUI.

With a real robot you would not use this, as your driver would be the entity publishing JointState msgs.

How can I control the joint angles? Is there a way to set joint angles and have RSP calculate the tf's for me? T

The RSP will always calculate TFs for you, provided that you got your urdf loaded and you have JointState msgs published by 'something' (ie: your driver). That is not influenced by whether or not you can control your robot.

Typical ROS robot drivers (for arms at least, but I'm guessing that is what you have) could implement a FollowJoinTrajectory action server. That would accept a JointTrajectory together with some constraints and would translate that into motions of the arm corresponding to what the trajectory prescribes (in space and time).

If you're writing a new driver you could perhaps take a look at ros_control. It's a framework that comes with a lot of infrastructure already so removes the need to develop things like that FollowJointTrajectory action server, controllers and state publishers. The 'only' thing you need to do is write a small hardware_interface class that allows ros_control to read out state and write new setpoints to your robot (and/or its controller).

ros_control is a bit of an advanced subject (and C++ only at the moment), so might be out of scope for now. I just wanted to mention it as it is a good example of an area where software re-use can really speed up your development.