point cloud height problem

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

liuhuanjim013
152 ●6 ●6 ●12

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

add a comment

2

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

watts
584 ●2 ●7 ●10

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

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 ( 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 ( 2011-07-29 00:59:28 -0500 )edit

add a comment

2

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

TomTUM

481 ●4 ●11 ●15 http://ias.in.tum.de/p...

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

Lorenz

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

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>-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

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 ( 2011-07-28 07:32:11 -0500 )edit

add a comment

point cloud height problem

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

point cloud height problem edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

point cloud height problem