-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RGBD sensor documentation is unclear/undefined #175
Comments
Some quick answers. Ignition sensors produce data in the robot body frame: x forward, y left, z up. RViz expects camera image data to be in the optical frame: z forward, x right, y down.. We don't have an option to publish sensor data in optical frame right now in ign-sensors. That'll be nice to have. In one of our projects (ROS 1), we wrote an optical frame publisher that republishes data to optical frame through the static TF broadcaster: |
Thanks for the pointers @iche033!
This is true for ROS and real world cameras, why would Ignition make an emulated sensor that does not match a real world one (am I missing something here??)? I think all we need to do is change the name of the frame_id that Ignition is using in its camera_info topic(s) (which is currently some random string of I would like to fix the plugin so you dont need additional static TF broadcasters to make it work. The optical frames are defined in the URDF and that should be enough (depth_optical_frame and color_optical_frame) if we pass the plugin the names of the frames. If I were to add a variable that is read when loading the plugin to update name of the frame_id (FYI, I have not read through the code to see if that's the correct place to fix this) would you guys see any issues merging it? This is how you defined it in ROS1 and Gazebo classic and it worked great! Thanks for your help and suggestions! I just want to make sure I'm on the right track before I make a PR. |
So I have been attempting to fix this issues and have run into some problems. I am having the issue of Ignition collapsing all of my fixed frames (I have always disliked this feature!!) so I cant put the camera in the location that I want. As I said before my goal is to move the rendering and depth measurement to the frame
You can see a few lines above I have also added preserveFixedJoint for the When I inspect the frames in Gazebo I notice a few weird things.
On the plus side I have figure out how to set the frame_id's for |
hmm the errors look like during the urdf -> sdf conversion process, a model with empty content is spawned. Not sure.
Could that be the
the feature has not been implemented yet. I usually just create a small box visual at the origin of the camera help visualize where it is.
The grid has a small pose offset so it gets rendered above the ground plane. I believe there is also an offset in gazebo classic. Here's the pose offset of the grid in Ignition: https://github.com/ignitionrobotics/ign-gazebo/blob/ign-gazebo6/src/rendering/RenderUtil.cc#L2542
nice :) |
So I made a PR against sdfFormat but somehow after getting that ready I have noticed there is now an offset in the point cloud data of 10mm in the Z (I have to manually add an offset to my URDF to remove it). I think when I was originally testing this I had sdf9 installed from binary but after building from source and updating to sdf12 the offset is present. I have not tired to roll back but if you guys have any ideas I would really appreciate the help tracking this offset down. Thanks! If you look at the gif I posed above with the aligned clouds you can see that the point cloud is coincident with the grid and you can see half of the x-axis on the world joint because it intersects the cloud. |
Is it already possible to set the frame_id manually when using the ignition-gazebo-sensors-system plugin as it used to be in ROS1 and Gazebo classic? I would expect to be able to define the frame_id in a tag when declaring the camera sensor. That would look something like:
|
that was added in #195. It reads the frame id by parsing an ignition-specific param, |
@iche033 I've tested it and it works well for Are you going to change the point cloud message code as you did for the image message any time soon (see e.g. #195 DepthCameraSensor.cc line 546)? |
Is there a possibility now to change the |
Environment
binary version: fortress
source packages: ros_ign
Description
I am trying to setup an RGBD sensor for use with my robot (we are using ROS2 Rolling) and the documentation and example configuration of the RGBD camera are unclear how to properly setup the sensor.
I am having problems defining where the camera is located in simulation and the frame that the
camera_info
topic is returning.Here is an example repo that a colleague and I are working on.
Here is an example gazebo.URDF file that I have used many times in ROS1 to emulate the Realsense D series camera.
issues:
${name}_depth_frame
(or${name}_link
, they are in the same location) so that the camera is placed in the same location that Realsense publishes from.camera_info
topic published to ROS comes in with the frame_id set asrgbd_camera/camera_bottom_screw_frame/rgbd_camera
requiring a static frame publisher to view the images.Camera
widget in Rviz and add TF frames (for marker overlay) I can see that Z points out of the camera and X is to the right. Which means that my static transform is obviously not oriented correctly because it thinks the camera is pointed upwards. Is the expectation that this should be tied to anoptical
frame?Steps to reproduce
ros2 launch rgbd_camera_ignition rgbd_ignition.launch.py launch_rviz:=true
Output
Here is what the Ignition world looks like:
The text was updated successfully, but these errors were encountered: