Closed airballking closed 5 years ago
Hmm, what are the frames? raw_ft, ft?
If that's the case then it's always assumed that the raw_ft is the one directly from the sensor and not ready for measurements yet.
After robot start
on the PR2, I enter rostopic echo /ft/l_gripper_motor
for the f/t sensor installed on the left arm of the robot. Messages like this one are going over the topic:
header:
seq: 210285
stamp:
secs: 1402902576
nsecs: 560354396
frame_id: ''
wrench:
force:
x: 0.351951055023
y: -14.4350184399
z: 24.7228982002
torque:
x: -0.807430490576
y: -0.73970471998
z: -0.0113289632462
On the URDF on our robot, which was presumably patched by pr2_ft
, the frame of the force-torque sensor is "r_force_torque_link". To be consistent with how the accelerometer is published, it should perhaps be called "r_gripper_motor_force_torque_link". After that, it's a matter of modifying WG06::unpackFT
so that ft_publisher_->msg_.header.frame_id
is set to string(actuator_info_.name_) + "_force_torque_link"
. Probably that expression should be evaluated outside the realtime loop (since my guess is that it allocates memory), but unpackAccel
shows that it works to do it within the realtime loop.
All people I met that have a PR2 with the FT sensor complain about this. I'll try to summarize
rostopic echo /ft/l_gripper_motor
, as @airballking mentioned, does not contain the frame_id
. However, the frame_id
is needed for basically everything. Sure, there are ways around it (republishing with the frame_id, hardcoding the frame_id in the packages that use the FT data), but the frame_id
should be set properly!
@goretkin basically fixed the issue on the controller side. His changes set the frame_id
in the realtime_loop.
If I understand correctly, there is a second step: the URDF must be changed as well. The pr2-ft-config
tool which is run when one installs the FT sensor patches the URDF. The pr2-ft-config
is part of the pr2debs
which are still hosted in the svn at code.ros.org. Here is the package and here are patch files which are applied.
@goretkin would you be willing to create a pull request? Split the commit into two, one for the cosmetig changes, one for the meat. Maybe extract the string
if it allocates memory.
@TheDash the pr2debs
issue was discussed (earlier)[https://github.com/PR2/pr2_ft/issues/1] and is a bit tricky. But the (approach)[https://github.com/PR2/pr2_ft/issues/1#issuecomment-50415140] suggested by @trainman419 seems reasonable. Can you create a git repo from the svn repo so that we can create a pull request for the URDF patch.
Let me know what you think!
At the moment, this is what is being used to create the debs https://github.com/pr2-debs. Although, I haven't copied over any SVN history as of now. The pr2-ft-config file is found here: https://github.com/pr2-debs/pr2-precise/blob/master/pr2-ft/pr2-ft-config
Once a PR is made for the pr2-ft package, I can re-create and re-release the deb so it is available via apt-get.
On Mon, Mar 23, 2015 at 11:22 AM, Stefan Otte notifications@github.com wrote:
All people I met that have a PR2 with the FT sensor complain about this. I'll try to summarize
rostopic echo /ft/l_gripper_motor, as @airballking https://github.com/airballking mentioned, does not contain the frame_id. However, the frame_id is needed for basically everything. Sure, there are ways around it (republishing with the frame_id, hardcoding the frame_id in the packages that use the FT data), but the frame_id should be set properly!
@goretkin https://github.com/goretkin basically fixed the issue https://github.com/goretkin/pr2_ethercat_drivers/commit/47c7c1f5a227fe805ad62cd11ae0848fd385a820 on the controller side. His changes set the frame_id in the realtime_loop.
If I understand correctly, there is a second step: the URDF must be changed as well. The pr2-ft-config tool which is run when one installs the FT sensor patches the URDF. The pr2-ft-config is part of the pr2debs which are still hosted in the svn at code.ros.org https://code.ros.org/svn/pr2debs/trunk/. Here https://code.ros.org/svn/pr2debs/trunk/packages/pr2-precise/pr2-ft/ is the package and here https://code.ros.org/svn/pr2debs/trunk/packages/pr2-precise/pr2-core-groovy/root/usr/share/pr2-ft/ are patch files which are applied.
@goretkin https://github.com/goretkin would you be willing to create a pull request? Split the commit into two, one for the cosmetig changes, one for the meat. Maybe extract the string if it allocates memory.
@TheDash https://github.com/TheDash the pr2debs issue was discussed (earlier)[PR2/pr2_ft#1 https://github.com/PR2/pr2_ft/issues/1] and is a bit tricky. But the (approach)[PR2/pr2_ft#1 (comment) https://github.com/PR2/pr2_ft/issues/1#issuecomment-50415140] suggested by @trainman419 https://github.com/trainman419 seems reasonable. Can you create a git repo from the svn repo so that we can create a pull request for the URDF patch.
Let me know what you think!
— Reply to this email directly or view it on GitHub https://github.com/PR2/pr2_ethercat_drivers/issues/66#issuecomment-85074475 .
Devon Ash <a href="http://ca.linkedin.com/pub/devon-ash/48/478/981" style="text-decoration:none;"><img src=" https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png" width="20" height="15" alt="View Devon Ash's LinkedIn profile" style="vertical-align:middle" border="0">View Devon Ash's profile
@TheDash thanks! I was just looking at https://github.com/pr2/ and didn't find the pr2debs there.
I don't know it it's planned, but getting the history is not too hard.
# get the authors from svn
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
# manually fix the email in authors-transform.txt
# svn 2 git
git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout new_repo_name
Here are the patches I think. @goretkin can you confirm that you changed this part?
I didn't do anything with the pr2-ft tool. The URDF on our PR2 was patched by the tool a few years ago now, which I believe created an error in the wrist orientation calibration (off by perhaps 15 degrees). Then someone probably manually fixed this, I don't know when. And I manually changed that URDF to have the frame name consistent with the accelerometer frame name.
I will clean up that commit shortly.
This makes it difficult to visualize the f/t measurements in rviz.
Also, the urdf has two frames related to the f/t sensor after updating the pr2 urdf (with the scripts from pr2_ft). It feels like an educated-guessing game to chose the right frame w.r.t. which calculations should interpret the measurements. A clarification should help avoid mistakes for all users.
Would it break the real-time loop to have this added to the header of the published messages?