Ask Your Question
1

TF (Broadcaster) and URDF model interaction

asked 2014-08-12 01:12:23 -0600

Andromeda gravatar image

updated 2014-08-12 01:14:14 -0600

Hi, I have a question regarding a simple robotic arm, which I already modeled in URDF, and the TF Broadcaster. In order to really understand how thinks works, I realized a simple base_link shape with above a small arm, which is free to rotate around one axis. Everything compiles and run smooth in RViz. Now let s say I want to drive the arm trough another node. So... Am I right if I create one state_publisher (broadcaster) (Node A) for the robotic arm, which publish constantly the joint_state of the arm (like the tutorials) WHILE the second node (Node B) will subscribe on the joint_state' topic the new joint_state position?

My idea is to broadcast the joint_state of the arm (Node A) while Node B will send the joint_state value (which could be for istance calculated by a math formula) and see it moving in RViz.

It would be helpful if you have some example!

Regards

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2014-08-12 01:37:35 -0600

Rabe gravatar image

updated 2014-08-12 07:15:58 -0600

Hey,

My guess is, that you currently launch things with roslaunch <my_robot>_config demo.launch?

If you inspect this launch-file, you'll notice the following:

<!-- We do not have a robot connected, so publish fake joint states -->

So you are right regarding the fact that you'll need to write your own node, which publishes joint states to the joint_states-topic. What I didn't quite understand what you need your second node for? You either write your own launch file or modify the demo.launch, to stop it from launching the generic joint-state-publisher and launch your own. Rviz/MoveIt should take care of the rest.

If you have any further questions, just ask.

Hope that helps, Rabe


Edit:

If I understand you correctly, you have your understanding of the pipeline mixed up. The pipeline works something like this:

Publishing of Current Joint-States => MoveIt and Rviz => You create a new target state (either via Rviz or in your code with the MoveIt-Interface) => MoveIt computes a path for you. This path will contain certain discrete points with a position, velocity and acceleration for each joint of your robot. If you only have 1 joint, then only for this one ;) => This JointTrajectory gets published to the FollowJointTrajectory-ActionServer. This is a server you need to write yourself, just like the JointStatePublisher. This server takes the trajectory and sends them to your (simulated) robot. Also, it answers to MoveIt when the trajectory was completed, otherwise MoveIt will send commands to cancel the movement, since it took too long. => Your robot starts moving => Your JointStatePublisher shows the new jointstates during the movement.

For me personnaly it was quite a hassle to work into the whole thing of ActionServers and stuff, but I was new to ROS and robotics in general. Follow the tutorials of how to implement your own robot, and you will get quite far.


Edit No 2:

Hey,

First of all, you should take everything I say with a grain of salt, I am by no means a ROS expert and my description of the pipeline was very simplyfied.

Regarding controlling your robot with a Joystick: I somehow assumed you used the whole MoveIt-Package, but now I am not certain if that is correct? For me, it's just the only way I know URDFs and that stuff.

In case you are using MoveIt: You could write a second Node, which depending on the input from the joystick would create new motion-requests, MoveIt would plan the path and you could execute this planned path. You should check out the documentation for the Python-Interface for MoveIt, there are examples how to request movements to new positions. Buuut I somehow get the feeling that's not exactly what you want to do?

In case you are NOT using MoveIt: Sure, you could write a node, which publishes JointStates depending on joystick-input or something like that. It would make the robot move in Rviz. But as far as I understand it, this wouldn't have ...

(more)
edit flag offensive delete link more

Comments

Hi, I need the second nde (Node B) just to understand how I can subscribe to the /joint_states topic. If I m able to use the same node (or same program) to rotate the arm around one axis, why should I publish the joint_state?

Andromeda gravatar imageAndromeda ( 2014-08-12 02:03:39 -0600 )edit

I thank you very much for your explanation, that s really good and told me a lot of things that I didn t know. Ok, but since I m not so far to use moveit_interface, how about if I want to move the arm with a PS3 gamepad or something like that? Current Joint-States => MoveIt and Rviz?????? Thanks!

Andromeda gravatar imageAndromeda ( 2014-08-12 04:58:07 -0600 )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

1 follower

Stats

Asked: 2014-08-12 01:12:23 -0600

Seen: 667 times

Last updated: Aug 12 '14