Ask Your Question
0

point cloud height problem

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

liuhuanjim013 gravatar image

Hi,

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:

<launch>
  <node pkg="pr2_mechanism_controllers" type="send_periodic_cmd_srv.py"
        name="laser_cmd"
    args="laser_tilt_controller linear 10 1 .35" />

  <node type="laser_scan_assembler" pkg="laser_assembler"
    name="tilt_scan_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>

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

Thanks for your help!

Huan

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
2

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

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

Comments

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 -0500 )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 -0500 )edit
2

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

TomTUM gravatar image

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

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

Comments

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 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

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

Seen: 440 times

Last updated: Jul 28 '11