get forward kinematics fail [closed]

al5b_arm_kinematics

asked 2012-05-31 06:03:14 -0600

ocli
215 ●9 ●13 ●20

updated 2012-06-03 04:14:55 -0600

Kevin

2952 ●50 ●76 ●113 http://walchko.github.io/

When using the get_fk.cpp and get_ik.cpp source code from this tutorial and am receiving a kinematics failed response in one terminal, and this daunting error message in the other.

[al5b_arm_kinematics-4] process has died [pid 1722, exit code -11, cmd /home/oliver/ros_workspace/Source/arm_navigation/arm_kinematics_constraint_aware/bin/arm_kinematics_constraint_aware __name:=al5b_arm_kinematics __log:=/home/oliver/.ros/log/e3db037a-ab39-11e1-add2-00242c4909b3/al5b_arm_kinematics-4.log].
log file: /home/oliver/.ros/log/e3db037a-ab39-11e1-add2-00242c4909b3/al5b_arm_kinematics-4*.log

EDIT: I seem to be publishing four links (two joint's connections), even though I've verified the urdf using

urdf_parser check_urdf <urdf_model>

gets

---------- Successfully Parsed XML ---------------
root Link: world has 1 child(ren)
    child(1):  shoulder_roll_link
        child(1):  shoulder_flex_link
            child(1):  upperarm_link
                child(1):  forearm_flex_link
                    child(1):  forearm_roll_link
                        child(1):  wrist_flex_link
                            child(1):  wrist_roll_link
                                child(1):  laser

and the planning components visualiser. But running

rosrun tf tf_monitor

I get two trees

->laser - wrist_roll_link ->world - shoulder_roll_link

the same as this pos

EDIT1: I'm not using the services above mentioned exactly from this tutorial - the requested services were altered to match the services created by the planning description component wizard ("/al5b_arm_kinematics/get_fk " etc. which are available - checked using rosservice list), sorry about that confusion.

The error does not occur anymore but now I am curious as to why, when I publish the topic /joint_states as a sensor_msgs/JointState (with all joints) the al5b_arm_navigation node gives me the warning

[ WARN] [1338564374.593596001]: Got joint state update but did not update some joints for more than 1 second.  Turn on DEBUG for more info
[ INFO] [1338564375.318709521]: Waiting for robot state ...
[ INFO] [1338564375.318775881]: Waiting for joint state ...
[ INFO] [1338564375.552888161]: Waiting for environment server planning scene registration service /register_planning_scene
[ INFO] [1338564375.554357401]: waitForService: Service [/register_planning_scene] has not been advertised, waiting...

and does not instantiate the above mentioned /al5b_arm_kinematics/ services, continuously.

but when I use the robot_state_publisher, which according to my previous post, does not correlate to the IK/FK described in the planning configuration wizard, the output is

[ INFO] [1338564645.890675001]: Successfully connected to planning scene action server for /al5b_arm_kinematics
[ INFO] [1338564646.191609841]: Successfully connected to planning scene action server for /ompl_planning
[ INFO] [1338564646.491904641]: Successfully connected to planning scene action server for /planning_scene_validity_server
[ INFO] [1338564647.294952841]: Successfully connected to planning scene action server for /trajectory_filter_server

The robot_state publisher shoulder just publish the currently Cartesian and Quaternion states of each link to tf from a robot description URDF and joint state, correct? Why is this allowing my al5b_arm_navigation to work rather than just publishing the states raw as a sensor_msgs/JointState?

EDIT2:The Forward kinematics still fails, which leads me to believe the tree is not complete...somewhere, but I've scoured all my launch files/nodes etc. and don't know where to look anymore. My urdf is located in a previous question here. Forward kinematics is essentially just a transform matrix from the "frame_id" to the target id, given the robot description (urdf) and joint states ("/joint_states" topic), which is why I previously posted regarding the discrepancy between my link description ... (more)

edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by tfoote
close date 2013-05-27 13:27:24

Comments

So, what's in the logfile?

dornhege ( 2012-05-31 06:27:41 -0600 )edit

I'm quite new at this - how do you read a logfile? 'cat <filename>' returns nothing

ocli ( 2012-05-31 17:09:42 -0600 )edit

could it be incorrect publishing on the tf topic.

ocli ( 2012-05-31 17:16:45 -0600 )edit

It seems like the tip and root link are being published simultaneously, but all other links are not, is there a way to rectify this?

ocli ( 2012-05-31 19:16:57 -0600 )edit

I still think your FK node is segfaulting. You said that you used an existing node and changed it, so chances are good that something is wrong with that code. Please provide a backtrace or try the arm_kinematics node.

Lorenz ( 2012-06-03 06:10:10 -0600 )edit

OK I'll get back to you in a few days. Thanks for your help. p.s. I had assumed the FK and IK nodes did not need inertia or mass of the links because it's kinematics. Is this correct, or should each joint/link be fully defined for these nodes to work?

ocli ( 2012-06-03 17:47:10 -0600 )edit

add a comment

answered 2012-06-01 01:34:27 -0600

Lorenz

22731 ●129 ●202 ●316 http://ias.in.tum.de/p...

Are you really using a PR2 arm? The IK services you are using are PR2 specific, so I expect it to fail when your arm has a different kinematic chain. Maybe you can provide a little more information on your hardware setup?

If you don't use a PR2 arm, try the more generic arm_kinematics node for calculating IK/FK. At least FK should work without a problem.

A possible launch file for arm_kinematics can look like this:

<launch>
  <node name="al5b_arm_kinematics" type="arm_kinematics" pkg="arm_kinematics">
    <rosparam>
      root_name: shoulder_roll_link
      tip_name: wrist_roll_link
    </rosparam>
  </node>
</launch>

If you want to get IK for laser, you can also replace tip_name with laser.

edit flag offensive delete link

Comments

I've added an edit to the question as well because I can't describe the problem fully here. I'm using the planning configuration wizard (refer question edit) to get the IK and FK for a custom robotic arm. The IK services were derived from the planning configuration wizard by Dylan Lu

ocli ( 2012-06-01 05:13:01 -0600 )edit

Without more information, it's hard to help. Which ik/fk node are you using (name of ros package). Your ik node is probably segfaulting. Try executing it in gdb (http://www.ros.org/wiki/roslaunch/Tutorials/Roslaunch%20Nodes%20in%20Valgrind%20or%20GDB) and provide a backtrace.

Lorenz ( 2012-06-01 05:35:40 -0600 )edit

I've updated the question now with two edits, is this sufficient or would backtracing be more useful?

ocli ( 2012-06-01 06:21:20 -0600 )edit

add a comment

get forward kinematics fail [closed]

Closed for the following reason question is not relevant or outdated by tfoote
close date 2013-05-27 13:27:24

Comments

1 Answer

Comments

Question Tools

Stats

get forward kinematics fail [closed] edit

Closed for the following reason question is not relevant or outdated by tfoote close date 2013-05-27 13:27:24

Comments

1 Answer

Comments

Question Tools

Stats

get forward kinematics fail [closed]

Closed for the following reason question is not relevant or outdated by tfoote
close date 2013-05-27 13:27:24