Open osrf-migration opened 11 years ago
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
In order to visualize the diff, I copied your multisense.urdf into our repo as multisense_sl.urdf in 32ee6704af84cc44119561f418f96ce3217e3cf1 (drcsim branch issue_386).
It's probably non-controversial to modify some of the
We can use the bitbucket compare feature to track the remaining differences:
https://osrf-migration.github.io/drcsim-gh-pages/#!/osrf/drcsim/compare/issue_386..drcsim_3.1#diff
Original comment by Matt Alvarado (Bitbucket: Matt Alvarado).
Thanks Steven. In the CRL URDF all the
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher).
A tricky part will be the fact that LIDAR to camera calibration in the CR URDF model is performed using 12 joints, for which joint_states have to be continuously published. So this would either have to be done in Gazebo too for full compatibility, or (which makes more sense IMHO) the calibration on Multisense is changed so it is realized by two fixed joints with xyz and rpy set through the calibration procedure.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
@Stefan_Kohlbrecher, I think the goal of this issue is for OSRF and CRL to synchronize the URDF's, while you are proposing a change to the CRL urdf. It looks like crl/multisense_ros doesn't have an issue tracker, though.
What do you think @mattjalvarado? Should we tackle that suggestion now or file it as a new ticket somewhere?
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Does anyone have a bag file of /joint_states I can use for comparison with drcsim? Thanks.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
As I look more closely at the 12 joints used for calibration, I'm appreciating @Stefan_Kohlbrecher 's suggestion more, since gazebo may have trouble solving an additional 12 degrees of freedom to the desired accuracy. The best way to simulate a rigid connection between the calibration frames and the head is through a fixed joint. @hsu does that assessment sound reasonable?
Original comment by Thomas Koletschka (Bitbucket: thomasko).
Issue #359 was marked as a duplicate of this issue.
Original comment by Thomas Koletschka (Bitbucket: thomasko).
Moving over from #359: The sensor specifications are outdated as well - cameras should be 1024x544 and the LIDAR fov should be 270 and not 180.
Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).
I agree that synchronizing urdfs between multisense_ros and drcsim repos is a good idea.
Having a fixed joint should work, but I have a couple of questions:
multisense_ros
? If so, please list the usage so we can help come up with a solution here.Thanks.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
@thomasko See 7c9df8d24a8b8094db4ebb15dc3289e6e05eb034 and 19bea7c88e149c9caca4e10c3b47bef1f0dbf60f
Original comment by Matt Alvarado (Bitbucket: Matt Alvarado).
I would love to tackle this issue now rather than file it as a new ticket.
In terms of the /joint_states topic I can have a bag file for you tomorrow.
I do realize a fixed transform is the proper way to go about this problem but from what I can tell the best mechanism to dynamically modify a tf tree defined in a URDF is using the robot_state_publisher and /joint_states. The only other way I know of is to require the user to run a script to modify the static transforms in the URDF (which seems inelegant and error-prone). If anyone has a suggestion about how to solve this issue we would be more than happy to implement it in the Multisense-Sl driver.
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
Issue #397 was marked as a duplicate of this issue.
Original comment by Matt Alvarado (Bitbucket: Matt Alvarado).
Hi John,
From taking a look at multisense_sl_v4.urdf it appears there are slight differences between the current MultiSense ROS driver URDF. Most of these are in the naming of the links which I think is acceptable. I did find a significant difference regarding the camera resolutions. In the drcsim URDF the resolution is set to 800x800 which is different than the default 1024x544 resolution of the Atlas MultiSense SL units. I imagine this has been brought up in previous issues, but I figured I would point it out just in case.
Overall I have not heard any complaints about this, and imagine most DRC teams have figured out a working solution to bridging between the physical hardware and simulation. I think changing anything at the moment would only add confusion.
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher).
Not sure why this is marked resolved. The Multisense models of CR (https://bitbucket.org/crl/multisense_ros/src/d778bd8ea1fdc4759ef14e57b0022b55d60b9180/multisense_description/urdf/multisenseSL.urdf?at=default) and drcsim (https://github.com/osrf/drcsim/blob/69be941fc16c7958d13222206bd9b43738308d91/multisense_sl_description/urdf/multisense_sl_v4.urdf) differ significantly. I nominate the fact that they have different root links as the most annoying difference, as that makes interchanging the models much harder than it should be.
Original report (archived issue) by Matt Alvarado (Bitbucket: Matt Alvarado).
The Multisense-SL URDF used by drcsim does not match the Multisense-SL URDF shipped with the Carnegie Robotics ROS driver. This make it difficult to update the full Atlas URDF when running on hardware. Would it be possible to use the Multisense URDF (https://bitbucket.org/crl/multisense_ros/src/ed051d65ed9f5c3d01bc9ef48de65759518c212e/multisense_description/urdf/multisense.urdf?at=default)? Or, if that breaks the TF tree, meet somewhere in the middle and agree upon a standard Multisense-SL URDF convention.
Matt Alvarado
Engineer at Carnegie Robotics