marcoesposito1988's profile - activity

I was also bitten by this - (and a solution is not on the horizon). As an alternative to the accepted answer, another

I also ran into this problem and this question many times, so I eventually created a python package called tf_bag. I h

Sorry for necroposting, but this might be interesting for who lands here and reads this: I also encountered a problem a

Hi, I also just got this error with code that used to work until the end of March.

If your case is really the same as mine, even if you use Time.now() as parameter for the first waitForTransform this will succede but then lookupTransform will throw an 'Extrapolation into the future' exception. Could you please check?

UPDATE:

I think I have found the problem. This happens if one of the frames doesn't exist yet in the TF database. I already opened an issue and I will forward this information to the TF people.

UPDATE 2:

The bug must be in TF2 (TF is now implemented as a shim layer over TF2). @sklaw, you were on the right path: you should check out both geometry on the tag 1.11.4 and geometry-experimental 0.5.7. This should give you a working configuration.

Hi Mike,

ideally you don't need to transform it by hand; it will be automatically done by moveit.

In practice the system might be a bit "deaf" wrt the frame_id attribute of the target pose. In my experience this will help:

mgc.set_pose_reference_frame(pose_target.header.frame_id)

I think that overlaying is the simplest way if you are developing ROS programs, you will just need to use catkin_make_isolated because of OMPL packaging.

And have no fear, you have complete control over it. catkin will find the underlay at compilation time only if you have sourced from its devel/setup.bash or install/setup.bash (devel_isolated and install_isolated for catkin_make_isolated) in your CURRENT shell.

It depends on the controller you are using.

For example the joint_trajectory_controller publishes a control_msgs::JointTrajectoryControllerState which already includes "error" as a field, that you can directly plot.

If you remove the line:

projection_evaluator: joints(shoulder_pan_joint,shoulder_lift_joint)

the default will be RRTConnect, else LBKPIECE1.

I am also interested in a deterministic way to set the default planner.

You can take a look at this new (experimental!) package:

https://github.com/CentroEPiaggio/kuk...

it still requires some tuning of the PID gains, but the arm can already be moved a bit with MoveIt!

There is a new package for it, even though it is still experimental:

https://github.com/CentroEPiaggio/kuk...

it requires some tuning of the PID gains, but it already brings the robot to life with MoveIt!

Hi Robert,

have you seen this? https://bitbucket.org/khansari/iiwa/src

looks like it is currently used, so I assume it is in a working state: https://bitbucket.org/samirmenon/scl-...

Ok, then you may have something wrong on your setup. You should launch Rviz with the debug argument, so that it is executed in GDB and we can see from the backtrace where the problem is Cheers Marco

You should add xyz as fields in the header. I have some MATLAB code for it but it should be straightforward to port it to Python, I hope you won't mind ;)

        f = pc.getFields;
        XField = rosmatlab.message('sensor_msgs/PointField',RTC.node);
        XField.setName('x');
        XField.setDatatype(7);
        XField.setCount(1);
        f.add(XField);
        YField = rosmatlab.message('sensor_msgs/PointField',RTC.node);
        YField.setName('y');
        YField.setDatatype(7);
        YField.setCount(1);
        YField.setOffset(4)
        f.add(YField);
        ZField = rosmatlab.message('sensor_msgs/PointField',RTC.node);
        ZField.setName('z');
        ZField.setDatatype(7);
        ZField.setCount(1);
        ZField.setOffset(8)
        f.add(ZField);

Cheers, Marco

It's a long while since I got it working in my repo, but it could be due to the SRDF not in sync with the URDF. This can be corrected by running again the moveit setup assistant.

But I'm using the UR5 right now with a development of my repo (I attached an end effector you aren't interested in for sure), so the base code for it should work:

https://github.com/marcoesposito1988/...

Please let me know if you encounter more problems.

Cheers, Marco

For anyone interested, I found the problem.

I had updated the URDF in ur_description, but not the SRDF in ur_moveit_config. These resulted in a discrepancy between the joints name and indices, I presume.

I still think this is a bug, as no single useful error message was emitted, just a SEGFAULT.

Hi everyone,

I'm trying to start the Universal Robot UR5 moveit_config demo.launch, but rviz crashes:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffa0353a03 in dynamics_solver::DynamicsSolver::DynamicsSolver(boost::shared_ptr<moveit::core::RobotModel const> const&, std::string const&, geometry_msgs::Vector3_<std::allocator<void> > const&) ()
   from /opt/ros/hydro/lib/libmoveit_dynamics_solver.so
(gdb) backtrace
0x00007fffa0353a03 in dynamics_solver::DynamicsSolver::DynamicsSolver(boost::shared_ptr<moveit::core::RobotModel const> const&, std::string const&, geometry_msgs::Vector3_<std::allocator<void> > const&) ()
   from /opt/ros/hydro/lib/libmoveit_dynamics_solver.so
0x00007fffa25c4675 in moveit_rviz_plugin::MotionPlanningDisplay::onRobotModelLoaded() () from /opt/ros/hydro/lib/libmoveit_motion_planning_rviz_plugin_core.so
0x00007fffa207a2a7 in moveit_rviz_plugin::PlanningSceneDisplay::executeMainLoopJobs() () from /opt/ros/hydro/lib/libmoveit_planning_scene_rviz_plugin_core.so
0x00007fffa207a688 in moveit_rviz_plugin::PlanningSceneDisplay::update(float, float) () from /opt/ros/hydro/lib/libmoveit_planning_scene_rviz_plugin_core.so

I can start rviz on its own or spawn the model; the problem seems to be in relationship with MoveIt!.

I am already using shadow-fix, so if the problem is known was not solved (others were known with MoveIt!: see question 75769, ros-moveit-pr2-demo-launch-fails)

Shall I file a bug or does anyone know about this?

Thanks in advance! Marco