ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

point cloud height problem

asked 2011-07-27 13:57:50 -0600

liuhuanjim013 gravatar image


We are using pr2_laser_snapshotter with laser_scan_assembler to get point cloud from our tilt laser. We noticed an offset in the z direction of the /base_link when the torso is not fully raised. image description

Unlike the point cloud in the picture above that is shifted up, the point cloud in the picture below is at the right height. The blue horizontal line is drawn in the /base_footprint frame as a reference.

image description

Below is the launch file we used to get the point cloud:

  <node pkg="pr2_mechanism_controllers" type=""
    args="laser_tilt_controller linear 10 1 .35" />

  <node type="laser_scan_assembler" pkg="laser_assembler"
    <remap from="scan" to="tilt_scan"/>
    <param name="max_scans" type="int" value="400" />
    <param name="fixed_frame" type="string" value="base_link" />
    <param name="ignore_laser_skew" type="bool" value="true" />

  <node pkg="pr2_laser_snapshotter" type="pr2_laser_snapshotter" output="screen\
    <remap from="laser_scanner_signal"
    <remap from="full_cloud" to="tilt_laser_cloud" />

Thanks for your help!


edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2011-07-28 09:29:03 -0600

watts gravatar image

Changing the mechanical reduction of the torso is only going to mask other problems. The mechanical reduction numbers for your robot will never change, even after calibration. Recalibrating the robot only changes the offsets of each joint.

Thank you for bringing this to my attention. I'm going to investigate this value and make sure the mechanical reduction is correct for the PR2 torso.

edit flag offensive delete link more


Hi Kevin, Thanks for the reply! What do you recommend us to do now? Shall I play with the mechanicalReduction value at all?
liuhuanjim013 gravatar image liuhuanjim013  ( 2011-07-28 09:32:00 -0600 )edit
Kevin, check Request #616 on support. For us, it solved the issue. I would also expect other robots to have the same issue, would be great to have checked official values :)
TomTUM gravatar image TomTUM  ( 2011-07-29 00:59:28 -0600 )edit

answered 2011-07-27 22:09:05 -0600

TomTUM gravatar image

updated 2011-07-27 23:18:50 -0600

Lorenz gravatar image

For the TUM PR2, we had a similar issue, it turned out to be a calibration problem of the spine. I adjusted the urdf file in /etc/ros/distro/urdf/robot.xml to compensate for the error, it works fine now. Looks like this for us:

'<transmission name="torso_lift_trans" type="pr2_mechanism_model/SimpleTransmission"> '<actuator name="torso_lift_motor"/> '<joint name="torso_lift_joint"/> '<!--mechanicalReduction>-52143.33</mechanicalReduction--> '<mechanicalReduction>-47532.66</mechanicalReduction> '</transmission>

So i measured maximum and minimum encoder value via 'rostopic echo /motor_trace/torso_lift_motor' along with actual positions. You can then guess what the actual mechanicalReduction should be.

edit flag offensive delete link more


Hi Tom, Thanks a lot! I followed your advice and noticed a few things: when I move the torso to its limits, the encoder position I get is the same constant no matter where the torso is. When I look at the encoder count in pr2_dashboard, they read -68456 and 2804881. How do I get mechanicalReduction?
liuhuanjim013 gravatar image liuhuanjim013  ( 2011-07-28 07:32:11 -0600 )edit

Question Tools


Asked: 2011-07-27 13:57:50 -0600

Seen: 546 times

Last updated: Jul 28 '11