Ask Your Question

Sachin Chitta's profile - activity

2014-10-18 09:26:31 -0500 received badge  Necromancer (source)
2013-10-27 07:48:58 -0500 received badge  Good Answer (source)
2013-09-18 01:17:48 -0500 received badge  Nice Answer (source)
2013-06-21 06:51:28 -0500 received badge  Good Answer (source)
2013-05-22 08:37:49 -0500 edited answer Why does moveit depend on swig-wx?

It does not depend on swig-wx. The warning:

WARNING: Package name "swig-wx" does not follow the naming conventions. It should start with a lower case letter and only contain lower case letters, digits and underscores.

Will appear anywhere that rosdep is referenced if swig-wx is installed. The best fix is uninstall swig-wx and its upstream dependencies:

sudo apt-get remove swig-wx

Note: swig-wx is deprecated and will be removed in Hydro.

2013-05-22 08:11:34 -0500 answered a question MoveIt Tutorial not working


I believe your issue for the PR2 was solved:

I cannot get the Robonaut gazebo simulator to come up either - I have put a ticket for this on their github page. I will update the MoveIt! page for that robot once that ticket is fixed.

2013-05-15 21:35:36 -0500 received badge  Nice Answer (source)
2013-05-15 21:29:33 -0500 received badge  Nice Answer (source)
2013-05-15 11:33:39 -0500 answered a question Virtual Joint as part of planning group in moveit!

Hi Kai,

Could you please ask future MoveIt! related questions on the moveit-users mailing list: . Its easier for us to track MoveIt! specific questions there.

MoveIt! uses KDL for setting up the default kinematics solver. KDL does not support planar joints so that's why you are having trouble setting up a group like this. However, the fact that KDL does not support the planar joint only means that MoveIt! will not do the full inverse kinematics for you directly. You can still send individual joint values as a goal for the motion planning and MoveIt! will plan a path for you.

We will look into adding planar joint support into KDL in the future.

2013-05-15 11:18:04 -0500 answered a question rosmake sbpl_interface - problem with missing dependency

Hi rosrookie,

Thanks for giving MoveIt! a try. Unfortunately, sbpl_interface has not been fully ported to the latest version of MoveIt! yet which is why its not working. The authors are working on updating it right now and we'll let you know as soon as its fully up and running.

2013-05-15 11:12:39 -0500 answered a question Making sure the goal state is reachable/clearing it when planning with MoveIt!

Hi Stefan,

Could you please ask future MoveIt! related questions on the moveit-users mailing list: Its easier for us to track MoveIt! specific questions there.

It would be unsafe for us to clear a goal state like you suggested - how do we know whether that's an actual obstacle or something that comes from noise? We are working on alternatives that would let you plan away from contact positions or towards contact positions, but this will take some time and won't be available immediately.

2013-05-15 11:07:56 -0500 answered a question Trajectory execution and environment monitoring

Hi Ane,

MoveIt! is indeed an advance on Arm Navigation. I would recommend switching over to MoveIt! as we will be able to provide you better support for it.

2013-05-15 11:05:18 -0500 answered a question Providing MoveIt! with (external) octomap data

Hi Stefan,

Could you please ask future MoveIt! related questions on the moveit-users mailing list: Its easier for us to track MoveIt! specific questions there.

Regarding your questions: you can have MoveIt! plan and maintain everything in a different frame: e.g. odom_combined for the PR2 or map. To do this right, you need to have a virtual joint in your SRDF (which can be added through the Setup Assistant) that connects the frame to the root link on your robot: e.g. for the PR2, the corresponding line in the SRDF looks like this:

<virtual_joint name="world_joint" type="planar" parent_frame="odom_combined" child_link="base_footprint"/>

This forces MoveIt! to do everything in the odom_combined frame. It uses TF information to figure out this particular transform. MoveIt! does use transforms outside of those belonging to the robot, it just needs to know about them through the SRDF.

2013-05-15 10:46:32 -0500 answered a question Plan self motion in Moveit

Hey flyingRobot78,

Could you please ask future MoveIt! related questions on the moveit-users mailing list: Its easier for us to track MoveIt! specific questions there.

Regarding your question:

(1) Could you please mention which robot you are doing this with - you mention first roll joint but without knowing the robot its hard to put this in context.

(2) If you are trying to move only one joint of a robot, the right way to do this (if you want to do it with planning) is to have a group just consisting of that one joint and move it directly. The way you are doing it seems overly complicated for a 1 DOF motion.

(3) when you specify path constraints, you need to specify a "planning volume" by setting the workspace bounds in the motion plan request: workspace_parameters.min_corner and workspace_parameters.max_corner.

2013-05-15 10:28:46 -0500 answered a question Suppressing wheel joint errors when using MoveIt!

Hey Patrick,

Thanks for trying out MoveIt! Glad to see it (mostly) worked for you :-)

I am trying to figure out what your situation is exactly -

(1) You have these joints defined in the URDF but are not publishing joint states for them? (2) You don't have these joints defined in the URDF and are publishing joint state for them

If these joints are "passive", e.g. an un-actuated caster, you can actually set them to be passive in the SRDF and then moveit won't complain about them. Otherwise, i.e. if they are actuated, you should have them in your URDF the right way.

2013-01-15 20:56:24 -0500 received badge  Good Answer (source)
2012-11-14 18:57:55 -0500 received badge  Nice Answer (source)
2012-08-09 12:48:04 -0500 received badge  Nice Answer (source)
2012-02-23 17:00:32 -0500 received badge  Guru (source)
2012-02-07 18:00:27 -0500 received badge  Good Answer (source)
2011-12-19 12:32:06 -0500 received badge  Great Answer (source)
2011-11-07 07:38:45 -0500 received badge  Good Answer (source)
2011-11-06 06:40:03 -0500 received badge  Nice Answer (source)
2011-11-04 13:03:32 -0500 answered a question How comunicate to arm_navigation node of ros electric

We are in the process of updating these tutorials. In the meantime, a good introduction to the arm navigation stacks in Electric can be found in an IROS tutorial:

2011-11-04 13:01:49 -0500 answered a question planning_environment in electric for clearing known objects

A good introduction to the new arm navigation stacks in Electric is in a recent IROS tutorial ( Working through that tutorial may answer a lot of your questions.

2011-11-04 12:56:37 -0500 answered a question move_arm and arm_controller conflict over action interface message type
2011-11-04 12:55:39 -0500 answered a question How do I find specific planner configuration options?

Currently all the options are not filled in the yaml file itself but you can look into the src/ompl_ros_planning_group.cpp file to find which planners and options are supported. I will try and get out a better yaml file or more information on the Wiki to help with that.

2011-11-04 12:52:28 -0500 answered a question FollowJointTrajectory Usage

See my answer to this question:

We'll try and put up some Wiki documentation soon.

2011-11-04 12:49:15 -0500 answered a question where is the node for follow_joint_trajectory action server (control_msgs/FollowJointTrajectory)

The JointTrajectoryAction was used earlier for connecting to the arm controllers on the PR2. However, since it lived in a PR2 specific stack, we decided to move away from it so that other people using the motion planning pipeline would not have to depend on a PR2 specific stack. The FollowJointTrajectory action is intended to replace the JointTrajectoryAction. To preserve backwards compatibility both interfaces are currently implemented in the following controller: robot_mechanism_controllers/src/joint_trajectory_action_controller.cpp

Using this controller implementation on your own robot will take some work since it is tied into the way that the control infrastructure has been setup on the PR2. However, you can use the code in there and the actionlib tutorials as a guide to how you can implement a similar interface on your own robot. Essentially, you need to have an action interface on your robot that connects to your controller and respects the specifications laid down by the FollowJointTrajectory action spec (control_msgs/action/FollowJointTrajectory.action).

Hope this helps.

2011-08-08 08:08:18 -0500 commented answer ompl planning attempts to move through static obstacles
Your launch and yaml files look fine at first glance. I would still suggest waiting for e-turtle - there are graphical tools in e-turtle that will make this much easier, e.g. Look at the "Automatically Generating Arm Navigation Configurations/Planning Description Configuration Wizard tutorial.
2011-08-03 09:57:17 -0500 answered a question ompl planning attempts to move through static obstacles

Without more information (configuration, launch files, etc.), it will be hard to debug this. There are tools coming in Electric that will help you debug this better.

2011-08-03 09:54:31 -0500 answered a question object_manipulation vs GraspIt vs OpenRave

All the libraries you mention are being actively worked on and maintained. Each library has its own focus and set of things it does well. Depending on your particular use case, you should look for whether the library does everything you want.

What kind of objects are you doing grasp planning for? object_manipulation can do grasp planning for point clouds, GraspIt does it for meshes, and so on. The motion planning stacks in ROS offer a complete pipeline from planning to execution. OpenRave can do fast IK for most arms. Depending on what you want, one or the other library might be more suitable for you.

2011-08-02 09:55:11 -0500 commented question Trajectory filter failing for coordinated arms movement
Would you be able to post or send us (a) your URDF (b) your planning configuration and launch files and (c) your gazebo launch files and environment? We can try and duplicate this with the tools on our end then.
2011-08-01 04:46:51 -0500 commented question Trajectory filter failing for coordinated arms movement
Which robot are you doing this with? On the PR2, separate links define the tip of the hand. If you are not including all the links in your collision operations properly, you will get this error. When you have collisions, can you check which two links are colliding?
2011-07-21 04:57:24 -0500 commented answer Cooperative Robotic Arms?
Hi Adolfo, This is still very preliminary but it will expose task space planning for carrying objects with two arms. It will also include joint space planners configured the way you mention to address two arms simultaneously for the part where the arms have to move in to grasp an object or move out of a grasp. BTW, its cool you got this working way back in boxturtle!
2011-07-20 16:37:35 -0500 commented question Cooperative Robotic Arms?
I am currently working on a multi-arm pipeline for the PR2. It will take a while though for it to be ready for use. My current goal is to get it up and running by the end of the summer.
2011-07-20 16:35:30 -0500 commented answer move_arm: occasional problems with trajectory filter
Thanks for the ticket, Martin. We will look into it.
2011-07-14 05:24:24 -0500 commented question Planning an arm-motion using ompl_planning and trajectory_filter
Its often the resolution of the collision checking that is the problem. I would suggest waiting for e-turtle which will bring out a set of tools that makes debugging this kind of thing easier. More information is here:
2011-07-11 08:54:46 -0500 commented answer Using arm_kinematics, Inverse Kinematics Calculations fail
Try changing the seed state to not be all zeros. Use a random state (within joint limits). arm_kinematics uses a numerical solver unlike the pr2_arm_kinematics which uses a custom analytical solution. Numerical solvers can be very dependent on the initial seed choice.
2011-07-08 06:36:36 -0500 answered a question arm_navigation visualization error: No default planner configuration defined under 'default_planner_config'. A default planner must be defined from among the configured planners

Add the following line at the end of your auto-generated YAML configuration file for OMPL (config/ompl_planning.yaml):

default_planner_config: SBLkConfig1

We'll update the gui soon so it reflects this change and adds the line in automatically.

2011-06-29 02:40:00 -0500 received badge  Nice Answer (source)
2011-06-28 13:13:34 -0500 commented question Undocumented planning_environment parameters
Yes, it does refer to the maximum allowed past/future time. It won't really extrapolate, it will just use the joint states at the cache limits if the timestamps are outside the cache timestamp limits.
2011-06-28 12:47:53 -0500 commented question Planning an arm-motion using ompl_planning and trajectory_filter
Are you using cturtle or diamondback? The planning components in cturtle have been much improved with the new ompl library and the ompl_ros_interface in diamondback.
2011-06-28 12:42:52 -0500 answered a question Multiple solutions from IK solver?

Yes, this is possible. You can call the service multiple times with a different state in the ik_seed_state each time and it should give you different solutions.

2011-06-08 22:39:38 -0500 received badge  Nice Answer (source)
2011-06-07 13:24:02 -0500 commented answer What ist the difference between the inverse kinematics service and the kinematics plugin?
With the current implementation of the pr2 kinematics, no. But the difference between those two frames is a transform that you can use externally to modify the input so that you specify the right input.
2011-05-31 15:08:12 -0500 received badge  Great Answer (source)
2011-05-31 15:08:12 -0500 received badge  Guru (source)