Moveit! Getting the different pieces to work together

[Sudarshan Srinivasan]

Hey all,

I am trying to get Moveit! working on the Meka robot. I have read most of the documentation and have a fairly decent idea of the different pieces involving Moveit! I think I have all the pieces required to get it work, however, I am having some trouble in making them work together. I am hoping this disscussion will not only help me but also other users who are in the same boat trying to get Moveit! to work with their robot. 

Originally, I had asked a question about Moveit on answers.ros.org which you can find here.  I have completed the Moveit! quickstart tutorial including the RViz one where I can set a random goal state for a group and provided the path to the goal is not colliding with anything, the simulation runs. Up until this point, I did not have a FollowJointTrajectoryAction server running, have a contollers.yaml file or running anything on the real robot.

Currently, my setup is: roscore is running on the computer that talks to the robot and I run Moveit! (using the command on the RViz tutorial demo.launch) on my computer while connecting to the remote roscore. Moveit! and RViz at this stage can read /joint_states and I can see the current state of the arms/torso etc on the model.

Based on the universal robot (UR5) action server ur5_driver.py and the associated client test_client.py for Moveit!, I started writing a very simple FollowJointTrajectoryAction server along with a very simple client to test it.

My code can be found here: meka_action_server.py and test_client.py.

When I launch Moveit! using the RViz launch file, I get error saying that it was unable to connect to the action server:

[ERROR] [1381437382.200345290]: Unable to connect to action server within allotted time

even though I was running meka_action_server.py. However, when I do:

$ rostopic list | grep follow
/follow_joint_trajectory/cancel
/follow_joint_trajectory/feedback
/follow_joint_trajectory/goal
/follow_joint_trajectory/result
/follow_joint_trajectory/status

I get all the topics that Moveit! is presumably looking for. In order to test my server I ran the test_client.py which was written based on the tutorials and the UR5 test and it didn't really give me anything. I will also include my controllers.yaml, meka_moveit_controller_manager.launch, andmoveit_planning_execution.launch for completion.

My questions:

1. Why is my test_client and Moveit not able to talk/connect to my FollowJointTrajectoryAction action server and how can I fix this problem?
2. I can't use the pr2_moveit_controller_manager and have to use the moveit_simple_controller_manager. Going by this post, the moveit_simple_controller_manager requires an action server. How do I get the moveit_simple_controller_manager and my action server to work together?

Like I said in the begining, I think I have all the pieces to make Moveit! plan a trajectory and receive it in the action server. Please let me know if I need to do anything in that regard. I would just like some help in getting them to work together. Essentially, I would like to receive the joint angles/velocity etc that Moveit! calculates and just print them onto the screen, because going from there to the robot is trivial.

Thanks for reading and your help is greatly appreciated. Please let me know if you need anymore information.

Thanks,

Sudarshan. 

[Ioan Sucan]

Hello Sudarshan,

It sounds to me like things should work too. I have had the problem you describe with the PR2 as well. All the topics for the actions seem to be there, but the actions do not connect. Things to check:

1. make sure time is the same on the machines you use

2. allow a long time for connection (try 60 s, for instance)

If this still does not work, you may have to set ROS_IP:
http://wiki.ros.org/ROS/EnvironmentVariables#ROS_IP.2BAC8-ROS_HOSTNAME
http://answers.ros.org/question/80226/rqt_rviz-rviz-remote-ros_ip/

Ioan

[Sudarshan Srinivasan]

Hi Ioan,

Thanks for the reply. Sorry I could not get back earlier. Just to clarify things, I will describe my setup a bit more in detail:

1. Computer: meka-mariposa - This runs roscore. ros nodes from other computers will connect to this ros master including nodes from itself.
2. Computer: meka-man - This is the computer on the robot which is running software provided by the manufacturer which interfaces with the roscore on meka-mariposa by publishing a topic which has all the states of the robot and subscribing to a command topic which receves various commands that can be given to it by ros nodes.
3. Computer: lap82 - workstation laptop that runs Moveit! along with the action server and connects to the ros master on meka-mariposa.

As per your suggestion, I updated the time on all the 3 machines (using sudo ntpdate pool.ntp.org) and tried running action server and action client again. But still no luck. As for setting ROS_IP, I already have this on my zshrc file on lap82: export ROS_MASTER_URI=http://meka-mariposa:11311). On lap82, I am able to list all the topics that are currently being published, nodes that are running, messages that are being passed, services that are running etc while running roscore on meka-mariposa, so I'm curious whether setting a specific ROS_IP will help since I am already able to connect to the ros master without any problems. Please let me know if I'm wrong.

I worked with the actionlib tutorials hoping that I could start with something basic. When I run roscore on lap82 and run the fibonacci server and client having them connect to the local ros master, they work. Howerver, when roscore is running on meka-mariposa they do not connect. 

Originally, I had asked this question on answers.ros.org but I deleted it as this question requires a back and forth kind of disscussion so the moveit groups seemed more appropriate. Since I was not able to attach files there, I ended up linking everything. Just to be complete and offer as much information as possible so that poeple who offer their help will have everything they need, I will attach all the files that I am using to get this whole thing to work. Please let me know if more information is required.

Thanks for your help,

Sudarshan.

[Sudarshan Srinivasan]

Hey Guys,

I have started working on this project after a break. I got through the learning actionlib tutorials and sucessfully calculate the fibonacci series on my current setup. For people with similar problems, I had to add the IP addresses and names of all the machines involved in the /etc/hosts file of each machine. After that setting ROS_MASTER_URI got the whole thing to work.

After reading through a lot of documentation and going through the moveit! tutorials, I think I have a conceptual understanding of how things need to work. I have functions that will take joint positions and move the actual robot's arms/hands/base etc to those positions. I have moveit! working with default start positions for the robot and RViz and can see simulations of path planning of arms/hands/base. What I am missing is the part in the middle that gives moveit! the current joint positions of the robot and goal positions and the part that takes the feedback from moveit! and calls the appropriate functions to move the actual robot. This I believe is the action server part that needs to be written. 

I was wondering if anyone can share a working example of the action server for moveit! which uses the FollowJointTrajectoryAction that runs a server and a test client from which I could base my own code. I have the definition of FollowJointTrajectoryAction message but I am not sure how to use it. In particular, I am not sure what the server needs to in order to pass moveit! whatever it needs and get its result from moveit! Once I have this, the rest is pretty easy which is just to call the functions that actually controls the robot. 

Any help is greatly appreciated. Please let me know if you need any additional information. I will be continuously upgrading this post on the progress that I make. My hope is that this will help others who are in a similar position as well.

Thanks!

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Nov 12, 2013 at 7:32 PM, Sudarshan Srinivasan <sudar...@gmail.com> wrote:

Hey Guys,

I have started working on this project after a break. I got through the learning actionlib tutorials and sucessfully calculate the fibonacci series on my current setup. For people with similar problems, I had to add the IP addresses and names of all the machines involved in the /etc/hosts file of each machine. After that setting ROS_MASTER_URI got the whole thing to work.

After reading through a lot of documentation and going through the moveit! tutorials, I think I have a conceptual understanding of how things need to work. I have functions that will take joint positions and move the actual robot's arms/hands/base etc to those positions. I have moveit! working with default start positions for the robot and RViz and can see simulations of path planning of arms/hands/base. What I am missing is the part in the middle that gives moveit! the current joint positions of the robot and goal positions and the part that takes the feedback from moveit! and calls the appropriate functions to move the actual robot. This I believe is the action server part that needs to be written. 

I was wondering if anyone can share a working example of the action server for moveit! which uses the FollowJointTrajectoryAction that runs a server and a test client from which I could base my own code. I have the definition of FollowJointTrajectoryAction message but I am not sure how to use it. In particular, I am not sure what the server needs to in order to pass moveit! whatever it needs and get its result from moveit! Once I have this, the rest is pretty easy which is just to call the functions that actually controls the robot. 

Hi,

ros_control  provides solutions to both publishing the current robot state and executing trajectory commands. If you can make your robot (or its simulation) compatible with ros_control, then you can instantiate these controllers:

- joint_state_controller: Publishes the state of all robot joints in a JointState message.

- joint_trajectory_controller: Implements a FollowJointTrajectoryAction server.

The last link is informative even if you don't end up using ros_control, as it explains most of the FollowJointTrajectoryAction behavior.

Best,

Adolfo.

[Sudarshan Srinivasan]

Hey,

Thanks for the reply Adolfo. Unfortunetly, currently I can only work with ROS Groovy and not upgrade to Hydro which is where ros_control will work. I took a look at the joint_trajectory_controller. If I understand it correctly, it seems to do more than what a typical action server does. My understanding for the entire loop is this: 

1. Any ROS node that we write (or in the case of the simulation the RViz GUI using Moveit!) would request a trajectory plan for a new goal position for a specific set of joints. 

2. Moveit! reads the joint_state published by the robots joint_state_publisher and attempts to calculate the new trajectory to the goal and if it succeeds invokes the action server with the result in the form of the FollowJointTrajectoryAction message. If it fails, it sends the appropriate message to the action server.

3. The action server then parses the message and converts it to the appropriate format required by the robot controllers and invokes the controllers to perform the actual action.

I have part 1's simulation working based on the Moveit! tutorial. I'm not sure what action server Moveit! uses for this part but I can see the simulation result of the trajectory planning. I have part 3: robot controllers that can take in joint angles and move joints to that position. I am trying ot get part 2 working: the part that connects Moveit! to the actual robot. My understanding was that all the controller stuff will be done by Moveit! and it will give me the result of its calculations which I can forward to the physical controllers. 

Please let me know if I am understanding this correctly.

Thanks,

Sudarshan.

[Adolfo Rodríguez Tsouroukdissian]

On Wed, Nov 13, 2013 at 5:38 PM, Sudarshan Srinivasan <sudar...@gmail.com> wrote:

Hey,

Hey Sudarshan,

Thanks for the reply Adolfo. Unfortunetly, currently I can only work with ROS Groovy and not upgrade to Hydro which is where ros_control will work.

I understand. You at least know of a possible solution awaiting in Hydro :)

 

I took a look at the joint_trajectory_controller. If I understand it correctly, it seems to do more than what a typical action server does.

The additional features not related to the action interface are:

- The possibility to send trajectories via a topic interface

- A topic with the current controller state (actual and desired state, state error)

- A service to query the controller state at any future time

Implementation-wise, these are minor additions compared to supporting a fully functional FollowJointTrajectoryAction server.

 

My understanding for the entire loop is this: 

1. Any ROS node that we write (or in the case of the simulation the RViz GUI using Moveit!) would request a trajectory plan for a new goal position for a specific set of joints. 

2. Moveit! reads the joint_state published by the robots joint_state_publisher and attempts to calculate the new trajectory to the goal and if it succeeds invokes the action server with the result in the form of the FollowJointTrajectoryAction message. If it fails, it sends the appropriate message to the action server.

3. The action server then parses the message and converts it to the appropriate format required by the robot controllers and invokes the controllers to perform the actual action.

I have part 1's simulation working based on the Moveit! tutorial. I'm not sure what action server Moveit! uses for this part but I can see the simulation result of the trajectory planning. I have part 3: robot controllers that can take in joint angles and move joints to that position. I am trying ot get part 2 working: the part that connects Moveit! to the actual robot. My understanding was that all the controller stuff will be done by Moveit! and it will give me the result of its calculations which I can forward to the physical controllers. 

If you use ros_control, you can leverage the existing pr2_moveit_controller_manager plugin [1], which I believe takes care of what you are missing.

Cheers,

Adolfo.

[1] https://github.com/ros-planning/moveit_pr2/tree/hydro-devel/pr2_moveit_plugins/pr2_moveit_controller_manager

Please let me know if I am understanding this correctly.

Thanks,

Sudarshan.

On Wednesday, November 13, 2013 10:37:56 AM UTC-5, Adolfo Rodríguez Tsouroukdissian wrote:

On Tue, Nov 12, 2013 at 7:32 PM, Sudarshan Srinivasan <sudar...@gmail.com> wrote:

Hey Guys,

I have started working on this project after a break. I got through the learning actionlib tutorials and sucessfully calculate the fibonacci series on my current setup. For people with similar problems, I had to add the IP addresses and names of all the machines involved in the /etc/hosts file of each machine. After that setting ROS_MASTER_URI got the whole thing to work.

After reading through a lot of documentation and going through the moveit! tutorials, I think I have a conceptual understanding of how things need to work. I have functions that will take joint positions and move the actual robot's arms/hands/base etc to those positions. I have moveit! working with default start positions for the robot and RViz and can see simulations of path planning of arms/hands/base. What I am missing is the part in the middle that gives moveit! the current joint positions of the robot and goal positions and the part that takes the feedback from moveit! and calls the appropriate functions to move the actual robot. This I believe is the action server part that needs to be written. 

I was wondering if anyone can share a working example of the action server for moveit! which uses the FollowJointTrajectoryAction that runs a server and a test client from which I could base my own code. I have the definition of FollowJointTrajectoryAction message but I am not sure how to use it. In particular, I am not sure what the server needs to in order to pass moveit! whatever it needs and get its result from moveit! Once I have this, the rest is pretty easy which is just to call the functions that actually controls the robot. 

Hi,

ros_control  provides solutions to both publishing the current robot state and executing trajectory commands. If you can make your robot (or its simulation) compatible with ros_control, then you can instantiate these controllers:

- joint_state_controller: Publishes the state of all robot joints in a JointState message.

- joint_trajectory_controller: Implements a FollowJointTrajectoryAction server.

The last link is informative even if you don't end up using ros_control, as it explains most of the FollowJointTrajectoryAction behavior.

Best,

Adolfo.

Any help is greatly appreciated. Please let me know if you need any additional information. I will be continuously upgrading this post on the progress that I make. My hope is that this will help others who are in a similar position as well.

Thanks!

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

[Sudarshan Srinivasan]

Hi All,

Just an update. As mentioned earlier, I have a very basic action server written that just starts and monitors the topic follow_joint_trajectory. I attached it here for completion. Earlier, I was going through the Moveit! tutorials and was running roscore on the same computer that was running Moveit! RViz GUI client. Here I could set a "random" goal state for the various planning groups that I had defined during the Moveit! setup and I could see the simulation of the set of joints moving. Here is an example of the output after running demo.launch and selecting a random goal for the "left_arm" planning group and clicking on Plan (I can't click on Pland and Execute as this computer is not connected to the robot by any means):

All is well! Everyone is happy! You can start planning now!

[ INFO] [1384975315.408226312]: No root joint specified. Assuming fixed joint

[ INFO] [1384975316.442928279]: Starting scene monitor

[ INFO] [1384975316.445609985]: Listening to '/move_group/monitored_planning_scene'

[ INFO] [1384975319.307890818]: No active joints or end effectors found for group 'left_hand'. Make sure you have defined an end effector in your SRDF file and that kinematics.yaml is loaded in this node's namespace.

[ INFO] [1384975319.324352664]: Constructing new MoveGroup connection for group 'left_hand'

[ INFO] [1384975320.134654340]: Ready to take MoveGroup commands for group left_hand.

[ INFO] [1384975320.134962593]: Looking around: no

[ INFO] [1384975320.135494582]: Replanning: no

[ INFO] [1384975325.887646644]: Constructing new MoveGroup connection for group 'left_arm'

[ INFO] [1384975325.949539897]: Ready to take MoveGroup commands for group left_arm.

[ INFO] [1384975325.950224405]: Looking around: no

[ INFO] [1384975325.950354648]: Replanning: no

[ INFO] [1384975329.210413368]: Planning request received for MoveGroup action. Forwarding to planning pipeline.

[ INFO] [1384975329.223537011]: No planner specified. Using default.

[ INFO] [1384975329.223769016]: Attempting to use default projection.

[ INFO] [1384975329.227477486]: Starting with 1 states

[ INFO] [1384975329.325186279]: Created 9 (4 start + 5 goal) states in 7 cells (4 start (4 on boundary) + 3 goal (3 on boundary))

[ INFO] [1384975329.325272838]: Solution found in 0.101228 seconds

[ INFO] [1384975329.372275776]: Path simplification took 0.046812 seconds

On the RViz I can actually see the left arm move to the goal position. Please keep in mind that at this point in time there is no "Action server" that I specifically run and I'm assuming Moveit! uses its default action server of some sort. 

Now, after setting up the computers as mentioned in a previous post and running roscore on a remote machine which as access to the robot, I run the same Moveit! demo.lauch from the laptop from earlier. I do the same thing: set a random goal for the left_arm planning group and hit Plan. But this is the output I get in that case:

All is well! Everyone is happy! You can start planning now!

[ INFO] [1384975670.731652838]: Starting scene monitor

[ INFO] [1384975670.734718736]: Listening to '/move_group/monitored_planning_scene'

[ INFO] [1384975673.631198291]: No active joints or end effectors found for group 'left_hand'. Make sure you have defined an end effector in your SRDF file and that kinematics.yaml is loaded in this node's namespace.

[ INFO] [1384975673.646757604]: Constructing new MoveGroup connection for group 'left_hand'

[ INFO] [1384975674.391198120]: Ready to take MoveGroup commands for group left_hand.

[ INFO] [1384975674.391532730]: Looking around: no

[ INFO] [1384975674.391723449]: Replanning: no

[ INFO] [1384976744.405166074]: Constructing new MoveGroup connection for group 'left_arm'

[ INFO] [1384976744.468589378]: Ready to take MoveGroup commands for group left_arm.

[ INFO] [1384976744.470021455]: Looking around: no

[ INFO] [1384976744.470124572]: Replanning: no

[ INFO] [1384976749.912784340]: Planning request received for MoveGroup action. Forwarding to planning pipeline.

[ WARN] [1384976749.913302746]: Joint 'left_arm_j6' from the starting state is outside bounds by a significant margin: [ -0.0473226 ] should be in the range [ 0.1 ], [ 1.0472 ] but the error above the ~start_state_max_bounds_error parameter (currently set to 0.1)

[ INFO] [1384976749.931722591]: No planner specified. Using default.

[ INFO] [1384976749.932087191]: Attempting to use default projection.

[ WARN] [1384976749.932457211]: Skipping invalid start state (invalid bounds)

[ERROR] [1384976749.932629793]: Motion planning start tree could not be initialized!

[ INFO] [1384976749.932693237]: No solution found after 0.000269 seconds

[ WARN] [1384976749.941088837]: Goal sampling thread never did any work.

[ INFO] [1384976749.941282411]: Unable to solve the planning problem

[ WARN] [1384976749.992087271]: Fail: ABORTED: No motion plan found. No execution attempted.

In this case, since the joint states are published by the robot's controllers, if I move the physical robots arms, I can see them move on the Moveit! RViz GUI. Again, just to emphasize, I'm still not running any action server at this point. I'm hoping that with some help I could get the simulation that I described I achieved to be executed by the robot itself. 

• Where does the meka_action_server piece fit in here?
• If I'm not running any action server in the first case, how come I am able to see the simulation? Does Moveit! use something by default? If that is the case, why does this process fail when the ros master is set to a remote computer where roscore is running?

I appreciate all the help that you guys provide and hopefully with my questions, I can help others as well. Please let me know if you need anymore detailed information because getting Moveit! to work on our robot will save us from writing a kinematics solver for a pretty complicated robot.

Thanks!

[Sudarshan Srinivasan]

Hi All,

I have made some good progress but am stuck at the next step. I was able to resolve all the network issues. Currently, I working with the Moveit! RViz plugin and I can give it a random goal for any of the planning group and it will plan in simulation the path it takes provided there is a path without collisions. However, I am not able to "plan and execute" and I am trying to figure out how I can do that. I have attached the action server that I am currently using in the previous post. I am also attaching a snapshot of what the Movit! RViz GUI looks like. This is the error I get when I start demo.launch:

[FATAL] [1386001362.349164446]: Exception while loading controller manager 'moveit_simple_controller_manager/MoveitSimpleControllerManager': According to the loaded plugin descriptions the class moveit_simple_controller_manager/MoveitSimpleControllerManager with base class type moveit_controller_manager::MoveItControllerManager does not exist. Declared types are  moveit_simple_controller_manager/MoveItSimpleControllerManager

It seems to me that the moveit_simple_controller_manager is either not loading correctly or is not configured correctly. I wonder if anyone else got this error and if they did how to fix it. Thanks for all your help. 

[Dave Hershberger]

Hi Sudarshan,

I'm not sure how or where you are specifying MoveitSimpleControllerManager as the plugin class to load, but you (or someone) has forgotten to capitalize the "i" in Moveit.  If you look at the "FATAL" error message you posted carefully, it says it can't find

Move i tSimpleControllerManager but has a definition for the class
Move I tSimpleControllerManager.  (spacing added for clarity).

So it might be a one-character fix if you can find where the plugin class is specified.

Dave

[Sudarshan Srinivasan]

Hi All,

@Dave Thanks for your reply. That was awesome that you spotted that case discrepency because amongst other things that was also a problem that I had to fix.

I'm definetly making progress. I have loaded the moveit_simple_controller_mamager and had the Moveit! RViz (demo.launch) connect to my action server. Currently, in the execte_cb function, I just receive the goal and print it out. When I plan a path for the right arm, I get the planned path as such:

The action server for humanoid controller has been started

I am executing and I got the goal: trajectory: 

  header: 

    seq: 0

    stamp: 

      secs: 0

      nsecs: 0

    frame_id: /world

  joint_names: ['right_arm_j0', 'right_arm_j1', 'right_arm_j2', 'right_arm_j3', 'right_arm_j4', 'right_arm_j5', 'right_arm_j6']

  points: 

    - 

      positions: [0.0027193813023440225, 0.15097985270211212, -0.473096067507469, 0.28544958053352865, 2.935930703577066, 0.32079097282838764, 0.3097277628606504]

      velocities: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

      accelerations: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

      time_from_start: 

        secs: 0

        nsecs: 0

    - 

      positions: [-0.04034932051094953, 0.18948687897769811, -0.5008591120814256, 0.31611881659718033, 2.8961891109274362, 0.33868367382295667, 0.33108339444700813]

      velocities: [-0.09539947568647861, 0.08529512063914785, -0.061496627116777745, 0.0679339965448907, -0.08802975112080293, 0.03963328871384638, 0.04730386499978713]

      accelerations: [-0.10726498131736066, 0.0959038763681274, -0.06914539635878572, 0.07638342682457905, -0.09897863212977115, 0.04456276035947718, 0.0531873803176495]

      time_from_start: 

        secs: 0

        nsecs: 622255161

    - 

      positions: [-0.08341802232424307, 0.2279939052532841, -0.5286221566553824, 0.346788052660832, 2.856447518277806, 0.35657637481752574, 0.3524390260333658]

      velocities: [-0.1391370302778377, 0.12440015731242637, -0.08969082909063364, 0.09907952288149391, -0.128388526864636, 0.057803861626152656, 0.06899114748140055]

      accelerations: [-0.11160151979763687, 0.09978110493956165, -0.07194082566256403, 0.0794714772359255, -0.1029801677817955, 0.04636435602203882, 0.05533765451319752]

      time_from_start: 

        secs: 0

        nsecs: 976482088

    - 

      positions: [-0.12648672413753662, 0.2665009315288701, -0.5563852012293391, 0.3774572887244837, 2.8167059256281766, 0.37446907581209476, 0.3737946576197235]

      velocities: [-0.1708360452743822, 0.15274173140197495, -0.11012472027487961, 0.1216524013984448, -0.15763875471799438, 0.07097307670057731, 0.08470911569068817]

      accelerations: [-0.11146151434396116, 0.09965592833900397, -0.07185057502840445, 0.07937177930846996, -0.1028509779182992, 0.04630619137776716, 0.05526823275765533]

      time_from_start: 

        secs: 1

        nsecs: 251349509

    - 

      positions: [-0.16955542595083017, 0.3050079578044561, -0.5841482458032957, 0.4081265247881354, 2.7769643329785465, 0.3923617768066638, 0.39515028920608125]

      velocities: [-0.1959696281273474, 0.17521325932297713, -0.12632638764983445, 0.1395500336276339, -0.18083073797995458, 0.08141471213365478, 0.09717161196419893]

      accelerations: [-0.09966685531361262, 0.08911051540405805, -0.0642474750832599, 0.07097279891523312, -0.0919674705245061, 0.04140615263785404, 0.04941984675264399]

      time_from_start: 

        secs: 1

        nsecs: 484174586

    - 

      positions: [-0.2126241277641237, 0.34351498408004205, -0.6119112903772523, 0.43879576085178706, 2.737222740328917, 0.4102544778012328, 0.4165059207924389]

      velocities: [-0.215763192394822, 0.1929103634205028, -0.1390857600919768, 0.15364503694795376, -0.19909522553317466, 0.08963786054871566, 0.10698625806404051]

      accelerations: [-0.08809487020615048, 0.07876419160434468, -0.056787915709023036, 0.06273238469229203, -0.08128943522450553, 0.03659862279079722, 0.04368187369394764]

      time_from_start: 

        secs: 1

        nsecs: 692280014

    - 

      positions: [-0.2556928295774173, 0.3820220103556281, -0.6396743349512091, 0.46946499691543875, 2.697481147679287, 0.4281471787958019, 0.43786155237879665]

      velocities: [-0.23237989070936693, 0.2077670833045968, -0.14979725397397536, 0.16547779302721788, -0.21442826386019948, 0.09654119410513462, 0.11522565401624328]

      accelerations: [-0.08417998191057874, 0.0752639536097761, -0.05426429150685357, 0.05994459150966658, -0.0776769767718035, 0.03497219982584364, 0.04174067489709495]

      time_from_start: 

        secs: 1

        nsecs: 884062799

    - 

      positions: [-0.2987615313907108, 0.4205290366312141, -0.6674373795251658, 0.5001342329790904, 2.657739555029657, 0.4460398797903709, 0.4592171839651544]

      velocities: [-0.2477094340267846, 0.22147297882648892, -0.15967901907255777, 0.17639396562949367, -0.22857358146616405, 0.10290978483143283, 0.12282681369115211]

      accelerations: [-0.08642127596438395, 0.07726785819448477, -0.05570907958030607, 0.06154061770804474, -0.0797451281565602, 0.035903335491820454, 0.04285202137549915]

      time_from_start: 

        secs: 2

        nsecs: 63374094

    - 

      positions: [-0.34183023320400435, 0.45903606290680005, -0.6952004240991224, 0.5308034690427421, 2.6179979623800276, 0.46393258078493993, 0.48057281555151204]

      velocities: [-0.26202620016434397, 0.23427336673300936, -0.16890792544069153, 0.18658893928447795, -0.2417843601510079, 0.10885762177388397, 0.12992578743006775]

      accelerations: [-0.08264778899818963, 0.07389404483025673, -0.05327660582486995, 0.058853516456397664, -0.07626314761002427, 0.03433565708150508, 0.04098093647967063]

      time_from_start: 

        secs: 2

        nsecs: 232119223

    - 

      positions: [-0.3848989350172979, 0.49754308918238604, -0.722963468673079, 0.5614727051063938, 2.5782563697303975, 0.48182528177950895, 0.5019284471378698]

      velocities: [-0.2770921149148102, 0.24774355623806837, -0.17861974969250904, 0.19731738190157772, -0.2556864148148025, 0.1151166891822393, 0.13739622678338764]

      accelerations: [-0.1063064022474255, 0.09504682640192826, -0.06852747493729823, 0.07570082236835564, -0.09809410444918676, 0.04416452293982222, 0.0527120685343326]

      time_from_start: 

        secs: 2

        nsecs: 392331283

    - 

      positions: [-0.4279676368305914, 0.536050115457972, -0.7507265132470358, 0.5921419411700455, 2.538514777080768, 0.499717982774078, 0.5232840787242274]

      velocities: [-0.29115453675852665, 0.2603165390454403, -0.18768470006313703, 0.20733123690517746, -0.2686624976092865, 0.12095885991679951, 0.1443690838109397]

      accelerations: [-0.07829851815993219, 0.07000543246449673, -0.05047296895950947, 0.05575639932894094, -0.07224986319002738, 0.032528771817338265, 0.038824348939752854]

      time_from_start: 

        secs: 2

        nsecs: 543258290

    - 

      positions: [-0.47103633864388494, 0.574557141733558, -0.7784895578209924, 0.6228111772336972, 2.498773184431138, 0.517610683768647, 0.5446397103105852]

      velocities: [-0.3022199380818409, 0.2702099345174919, -0.19481770424560962, 0.21521091265660705, -0.27887308333351385, 0.12555593177936175, 0.1498558671145161]

      accelerations: [-0.07396638609506552, 0.06613214359746102, -0.04768038012926863, 0.05267148672738712, -0.068252393552456, 0.03072900678049498, 0.03667625966689029]

      time_from_start: 

        secs: 2

        nsecs: 688296177

    - 

      positions: [-0.5141050404571785, 0.6130641680091441, -0.8062526023949491, 0.6534804132973488, 2.459031591781508, 0.5355033847632161, 0.5659953418969429]

      velocities: [-0.3129301601836177, 0.2797857700204598, -0.20172175199001685, 0.22283766517302817, -0.28875592785947757, 0.13000544601090858, 0.15516653467085725]

      accelerations: [-0.0790026289802386, 0.07063496650468284, -0.050926854478839295, 0.056257796864825946, -0.07289958060018427, 0.032821291532212325, 0.03917348254817643]

      time_from_start: 

        secs: 2

        nsecs: 828360669

    - 

      positions: [-0.5571737422704721, 0.6515711942847301, -0.8340156469689058, 0.6841496493610005, 2.419289999131878, 0.5533960857577851, 0.5873509734833006]

      velocities: [-0.3231918243268392, 0.28896055714330465, -0.2083366492824, 0.23014499942653538, -0.2982248660702258, 0.13426860882963743, 0.16025478459897446]

      accelerations: [-0.07237502635823687, 0.06470933472187072, -0.046654554194260456, 0.05153827895988826, -0.06678396827476198, 0.03006788344157922, 0.03588718335788403]

      time_from_start: 

        secs: 2

        nsecs: 963640125

    - 

      positions: [-0.6002424440837657, 0.6900782205603161, -0.8617786915428625, 0.7148188854246522, 2.3795484064822485, 0.5712887867523542, 0.6087066050696583]

      velocities: [-0.33298485979576675, 0.2977163509853039, -0.2146494580923063, 0.23711862305415915, -0.3072613777370201, 0.13833708194578487, 0.16511066482710818]

      accelerations: [-0.07682754887954675, 0.06869026273924975, -0.04952474939453129, 0.054708921643221636, -0.07089252806081689, 0.03191766415915498, 0.038094968282696894]

      time_from_start: 

        secs: 3

        nsecs: 94941032

    - 

      positions: [-0.6433111458970592, 0.728585246835902, -0.8895417361168192, 0.7454881214883039, 2.3398068138326185, 0.5891814877469232, 0.630062236656016]

      velocities: [-0.33462493611841926, 0.2991827165684628, -0.21570668782372204, 0.2382865219176979, -0.30877475618552125, 0.13901844437404404, 0.16592389727307075]

      accelerations: [0.051732683543660694, -0.046253351520973776, 0.033348040193545, -0.03683886017008282, 0.047736271341041144, -0.021492113746694817, -0.025651670104232943]

      time_from_start: 

        secs: 3

        nsecs: 222380399

    - 

      positions: [-0.6863798477103528, 0.767092273111488, -0.9173047806907758, 0.7761573575519556, 2.300065221182989, 0.6070741887414922, 0.6514178682423737]

      velocities: [-0.3264237425701076, 0.2918501627147381, -0.21042001577522387, 0.23244644942080106, -0.3012071147309268, 0.13561129491793394, 0.16185733244496442]

      accelerations: [0.0738297643880379, -0.06600999234977503, 0.047592310733567525, -0.0525741983669779, 0.06812632603710461, -0.03067224789874004, -0.036608515743361936]

      time_from_start: 

        secs: 3

        nsecs: 352381297

    - 

      positions: [-0.7294485495236462, 0.805599299387074, -0.9450678252647324, 0.8068265936156073, 2.260323628533359, 0.6249668897360613, 0.6727734998287315]

      velocities: [-0.31682366858821603, 0.28326689260200477, -0.20423159423821222, 0.22561023372859101, -0.2923486580435508, 0.13162298679505696, 0.15709713224093194]

      accelerations: [0.06955097776169093, -0.06218439877228241, 0.044834109561296395, -0.04952727306892918, 0.0641780808386158, -0.028894644987560513, -0.034486877825780304]

      time_from_start: 

        secs: 3

        nsecs: 486321353

    - 

      positions: [-0.7725172513369398, 0.84410632566266, -0.9728308698386892, 0.837495829679259, 2.220582035883729, 0.6428595907306303, 0.6941291314150891]

      velocities: [-0.3070925820670274, 0.2745664863072937, -0.1979587190999747, 0.21868072396607394, -0.28336930969356144, 0.12758025009426863, 0.1522719694212495]

      accelerations: [0.07132234536774225, -0.06376814975797913, 0.04597597257859358, -0.05078866449652886, 0.06581260816054817, -0.029630551796714602, -0.03536521110274602]

      time_from_start: 

        secs: 3

        nsecs: 624319926

    - 

      positions: [-0.8155859531502333, 0.882613351938246, -1.000593914412646, 0.8681650657429106, 2.1808404432340995, 0.6607522917251993, 0.7154847630014468]

      velocities: [-0.2965970151813868, 0.2651825705441818, -0.19119304288948175, 0.21120682749635955, -0.27368453800937453, 0.12321991341945152, 0.1470677387325378]

      accelerations: [0.07562860716594724, -0.06761830844008482, 0.048751884858692605, -0.05385515487308852, 0.06978620604068358, -0.031419569146118646, -0.03750047259439206]

      time_from_start: 

        secs: 3

        nsecs: 766889083

    - 

      positions: [-0.8586546549635269, 0.921120378213832, -1.0283569589866024, 0.8988343018065623, 2.1410988505844695, 0.6786449927197683, 0.7368403945878045]

      velocities: [-0.2831620716373813, 0.2531706058858839, -0.1825325790083601, 0.20163979998670356, -0.26128746005909714, 0.1176384257592496, 0.1404060170499787]

      accelerations: [0.10435058376448544, -0.09329816088516271, 0.06726671077597156, -0.07430808341348774, 0.09628937530315909, -0.0433519868325855, -0.05174227522241359]

      time_from_start: 

        secs: 3

        nsecs: 914838551

    - 

      positions: [-0.9017233567768205, 0.959627404489418, -1.0561200035605591, 0.929503537870214, 2.10135725793484, 0.6965376937143374, 0.7581960261741623]

      velocities: [-0.2706498989282476, 0.2419836756328213, -0.17446695376275634, 0.19272987787785684, -0.2497418677836696, 0.11244029914639189, 0.13420185162424825]

      accelerations: [0.05742206236685591, -0.05134013265466491, 0.03701554051780966, -0.04089026861374146, 0.05298613878769555, -0.02385574092471136, -0.028472750679869072]

      time_from_start: 

        secs: 4

        nsecs: 71326817

    - 

      positions: [-0.944792058590114, 0.998134430765004, -1.0838830481345159, 0.9601727739338657, 2.0616156652852102, 0.7144303947089065, 0.7795516577605199]

      velocities: [-0.2601204248743214, 0.23256944402165397, -0.16767942023628138, 0.1852318361029759, -0.24002580830084644, 0.10806587588901784, 0.12898080805370904]

      accelerations: [0.07194732609729564, -0.06432693487018219, 0.04637884907875039, -0.05123371346999033, 0.0663893083748784, -0.029890197266648582, -0.03567510802666297]

      time_from_start: 

        secs: 4

        nsecs: 233190676

    - 

      positions: [-0.9878607604034076, 1.03664145704059, -1.1116460927084726, 0.9908420099975174, 2.02187407263558, 0.7323230957034755, 0.8009072893468777]

      velocities: [-0.24667041553902097, 0.22054400928423099, -0.15900924461049032, 0.17565408023861578, -0.2276148284098246, 0.10247812921269647, 0.12231161599301194]

      accelerations: [0.0857242661586066, -0.07664467305595977, 0.05525977153312564, -0.06104427680682702, 0.0791019631989994, -0.03561376586190463, -0.04250640880772994]

      time_from_start: 

        secs: 4

        nsecs: 402645045

    - 

      positions: [-1.0309294622167011, 1.075148483316176, -1.1394091372824293, 1.021511246061169, 1.9821324799859503, 0.7502157966980445, 0.8222629209332354]

      velocities: [-0.23152391803110584, 0.2070017720454863, -0.14924547491818457, 0.16486825461467375, -0.21363841610379092, 0.09618558405545062, 0.1148012196498634]

      accelerations: [0.08222096060583764, -0.07351242450209619, 0.053001462735270885, -0.058549571824388656, 0.07586929222579951, -0.03415833312051044, -0.04076929346481164]

      time_from_start: 

        secs: 4

        nsecs: 582713374

    - 

      positions: [-1.0739981640299947, 1.113655509591762, -1.1671721818563858, 1.0521804821248208, 1.9423908873363205, 0.7681084976926136, 0.8436185525195932]

      velocities: [-0.2127829496132334, 0.19024577678875898, -0.13716462920799607, 0.1515228051288529, -0.19634521010117145, 0.08839973191383478, 0.10550850358800798]

      accelerations: [0.10923579573906522, -0.09766594951000808, 0.070415827236264, -0.07778684439214728, 0.10079719876024087, -0.04538152646290425, -0.054164609371303934]

      time_from_start: 

        secs: 4

        nsecs: 775097678

    - 

      positions: [-1.1170668658432883, 1.152162535867348, -1.1949352264303426, 1.0828497181884724, 1.9026492946866906, 0.7860011986871827, 0.8649741841059508]

      velocities: [-0.1896302478661865, 0.1695453224683746, -0.12223988191941261, 0.1350357589562113, -0.174981082490399, 0.07878104474345693, 0.09402822793720694]

      accelerations: [0.10583611960283985, -0.09462635433312955, 0.0682243202687227, -0.07536593394970403, 0.0976601517061587, -0.043969146102626276, -0.052478878712575984]

      time_from_start: 

        secs: 4

        nsecs: 988628487

    - 

      positions: [-1.1601355676565819, 1.190669562142934, -1.2226982710042993, 1.1135189542521242, 1.8629077020370608, 0.8038938996817516, 0.8863298156923085]

      velocities: [-0.16497646982339337, 0.14750278022965635, -0.10634750741307855, 0.117479795882769, -0.15223183853829422, 0.06853874208900343, 0.08180364305475277]

      accelerations: [0.0958626537942236, -0.08570924065703028, 0.06179520204264086, -0.0682638258206272, 0.08845714816104866, -0.039825714002746655, -0.04753353203434695]

      time_from_start: 

        secs: 5

        nsecs: 231183434

    - 

      positions: [-1.2032042694698752, 1.22917658841852, -1.250461315578256, 1.1441881903157758, 1.8231661093874312, 0.8217866006763207, 0.9076854472786662]

      velocities: [-0.13470161890118645, 0.12043452809137067, -0.08683166411538937, 0.09592106504964142, -0.12429575636673346, 0.05596118965766921, 0.06679184712393171]

      accelerations: [0.10873805174911179, -0.09722092469865802, 0.07009497037275773, -0.07743240074084867, 0.10033790609387983, -0.04517474093167085, -0.053917802831372506]

      time_from_start: 

        secs: 5

        nsecs: 513804492

    - 

      positions: [-1.2462729712831688, 1.267683614694106, -1.2782243601522125, 1.1748574263794276, 1.7834245167378013, 0.8396793016708897, 0.929041078865024]

      velocities: [-0.08323413896835087, 0.07441829080835628, -0.05365458007698666, 0.05927105645397516, -0.07680420133773055, 0.03457925357391255, 0.04127167832737312]

      accelerations: [0.10905816082483788, -0.09750712902038056, 0.07030131981361736, -0.07766035051403125, 0.10063328635739721, -0.045307728826275595, -0.05407652903394762]

      time_from_start: 

        secs: 5

        nsecs: 881872286

    - 

      positions: [-1.2893416730964624, 1.306190640969692, -1.3059874047261693, 1.2055266624430792, 1.7436829240881715, 0.8575720026654587, 0.9503967104513816]

      velocities: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

      accelerations: [0.11357800125740589, -0.10154824488806688, 0.073214909639022, -0.08087893030307046, 0.10480396366481029, -0.04718547647127571, -0.05631769356975055]

      time_from_start: 

        secs: 6

        nsecs: 752733157

path_tolerance: []

goal_tolerance: []

goal_time_tolerance: 

  secs: 0

  nsecs: 0

It seems that all the details in terms of positions, velocities, acceleration along with the timestep (secs and nsecs) are contained within this goal variable that is passed to the call back function. Now I need to figure out how to extract these componentents and pass them to the node which controls the actual hardware. If anyone has examples of action servers where they disect this result provided by Moveit! it'd be great if you could share it. I am going by the UR5_driver which I have attached to a previous post but am also looking for something simpler.

Thanks. 

[Sudarshan Srinivasan]

Hey All,

Sucess! We were able to set a random goal to a planning group on the Moveit! RViz GUI and have it execute on the physical robot. We think all the parts are in place for the action server, now its just tweaking to make it better. Currently, the Moveit! RViz GUI is acting as the "client" and giving goal positions to Moveit! which then plans the path and returns the wavepoints to our action server. I would like to write my own client which would give a goal position to Moveit! and have the robot execute it. Are there any examples for doing this? Do I communicate my goal the the action server or directly to Moveit!? If I need to talk directly to Moveit! which node am I actually working with?

Thanks!

[Sachin Chitta]

Hi Sudarshan,

When you are talking to MoveIt! you are actually working with the move_group node. If you want to talk directly to move_group, the best way is to use the move_group_interface class. Here's a really simple example: http://moveit.ros.org/wiki/MoveGroup_Interface#motion_plan

Best Regards,
Sachin

[Sudarshan Srinivasan]

Hi All,

We have gotten a good action server working and able to use the MoveGroupCommander from moveit_commander to be able to issue random or pre-planned targets and have the arms (or any group for that matter) move. I have attached a very simple client file where I move the left arm to a specified position. 

Ideally, as I proceed in development, I would like to preempt the current goal requrest and give move_group new goals. I am trying to figure out how to do this. Currently, group.go() is a blocking call and it returns TRUE if the move succeeded and false if the move failed. If the move failed, I would like to attempt it a couple of more times (I've noticed for certain positions the move will fail but if we attempt the move a couple of more times it will eventually get there). So, the return value of group.go() is important to check for the result of the move. However, when group.go() is blocking, I am not sure how to preempt the current goal with a new goal, since control does not get back to the client program until group.go() returns. To circumvent this, I used group.go(wait = False), which essentially makes group.go() a non-blocking function call. The problem with this approach is that now I can not rely on the return value of group.go() to check whether the move was sucessfull or not. 

So in essence, when group.go() is blocking there is no clear way that I can see to preempt the current goal for a new one since my client does not get control back until after gourp.go() returns. If group.go() is made non-blocking by passing wait=False, then it returns immediately, but its return value can not be used to check the result of the move to see where another attempt can be made or not. I was wondering if there is a way where group.go() can be blocking and the current goal can also be preempted for a new one. I appreciate any help I can get on this problem. Please let me know if you need any additional information.

Thanks.

[Sam Pfeiffer]

Hello,

I tried the MoveGroupCommander too and I found it very useful to use it with Ipython to test stuff on the way. But for sending goals I found it too slow as it needs to connect at the start to the movegroup etc.

So what I do is call the /move_group actionserver directly.

Here you can see a python snippet I prepared for sending a goal to it: https://github.com/reem-utils/rockin_snippets/blob/master/scripts/moveit.py

It's a bit personalized for my robot but you can easily change the few fields that probably change in your case (group names, frame_id, default tolerances...).

As it's a normal actionserver (as far as I know) you can preempt the call and send another goal. I also experimented "spamming" a bit the /move_group actionserver and if a new goal comes I found out it stops the previous goal and executes the new one.

I hope this information is useful :)

[Sudarshan Srinivasan]

Hi Sam,

Thanks for that. I tried your code with some modifications (which I've attached just in case anyone needs it) and it seems to work. I set up my goal and send it and receive Goal achieved message. When using MoveGroupCommander, all I had to do was call group.go() which would actually execute the action by publishing the result to the action server that we've written for the robot (not the move_group action server), but it seems this approach gives me a lot more in-depth control. So, would I need to publish the result to my action server for execution separetly? Also, I thought move_group was just a node which has to connect to the action server that we provide. So I guess my question how does the action server that actually executes the action that was written for the robot fit in here?

[Sudarshan Srinivasan]

Hi Sam,

I figured out the action server part, all I had to do was let plan_only = False. I did run some tests for checking speed, I found out that there wasn't significant differences in terms of run time between using MoveGroupComnder interface vs connecting to move_group directly from the client code. When you said that you found MoveGroupCommander to be slower, what aspect were you referring? The most clear advantage that I can see of connecting to move_group directly is that we can control the timeout (either make it blocking by passing 0 or pass it a specific amount of seconds that it can wait). Other than that, for the more code overhead, I am curious what advantage connecting to move_group directly offers.

Thanks.

[Sachin Chitta]

Hey guys,

We would like the move_group_interface to serve as primary client API to MoveIt! going forward. If you see things missing or not doing what you expect them to do, feel free to modify the code and give us a pull request, e.g. if the timeout is something that you would like to pass in, its not hard to add it as an optional parameter in the API calls.

And yes, minimizing code overhead would be good - we want to have the use cases drive the client API to a better state.

Sachin

[Sam Pfeiffer]

What I meant is that the initalization is slow.

For example in the example: http://moveit.ros.org/wiki/MoveIt_Commander

The line:

group = MoveGroupCommander("arm")

Starts saying "Loading robot model..." many times and I feel it takes too long. (That's not exactly the output but I can't test it right now).

Using directly the /move_group actionserver I only need to wait a few milliseconds until it connects and I'm ready to send goals. Maybe this is not the intended use, but if I just want to make some little script that say... returns the robot to a home position, this is a lot faster than waiting for the MoveGroupCommander for sending the pose. Also I feel I can use the usual actionserver stuff... cancel goal, send goal and wait... and if some feedback was published I could read it too!

I'm sorry if this wasn't the intended use but I think it makes a lot of sense! I'm slow working on C++ so I'll struggle helping on coding new features but I can test whatever you need!

P.S.: I updated the pose goal file and the joints goal file and I've played around with them in simulation and in the real robot and they work fine.

[Christopher Korpela]

Hi Sam,

I am doing similar work.  move_group_python_interface_tutorial works but I am experiencing the same timeout issues.  I tailored your script to work on my 7-dof arm.  However, my desired goal continues to fail.

Two quick questions:

1. Do you know the command to obtain the current pose for the end-effector?  I am sure it is something simple.

2. If I have changed frame_id, group, end_link, tolerances, etc. - can you think of anything else it would be causing the goal to fail?

[Mohamed LAAZIZI]

you can do this

target_pose = group.getCurrentPose().pose;

 ROS_INFO("*********x*********** (%%): %f",(float)target_pose.position.x);

    ROS_INFO("**********y********** (%%): %f",(float)target_pose.position.y);

    ROS_INFO("**********z********** (%%): %f",(float)target_pose.position.z);

    ROS_INFO("**********rot x********** (%%): %f",(float)target_pose.orientation.x);

    ROS_INFO("**********rot y********** (%%): %f",(float)target_pose.orientation.y);

    ROS_INFO("**********rot z********** (%%): %f",(float)target_pose.orientation.z);

[Nick Pestell]

Hi Sachin,

I have been trying to use the moveit_commander interface with a simulated ur5. Here is a link to my previously asked question. I would very much appreciate it if you could take a look and offer some advice... As a new user of ros it seems to me that the moveit_commander library is essentially the best way to interface with a robot in python without the need for an action server and client? Is this now an out-dated technique?  

Many thanks,

Nick :)

[Nick Pestell]

Hi Sam,

I have been trying to use the moveit_commander interface with a simulated ur5. Here is a link to my previously asked question. I would very much appreciate it if you could take a look and offer some advice... As a new user of ros it seems to me that the moveit_commander library is essentially the best way to interface with a robot in python without the need for an action server and client? Is this now an out-dated technique?  

Many thanks,

Nick :)