Skip to content
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

Camera frames confusion #45

Closed
raultron opened this issue Aug 16, 2016 · 5 comments
Closed

Camera frames confusion #45

raultron opened this issue Aug 16, 2016 · 5 comments

Comments

@raultron
Copy link

Hi,

I am completely confused with the static transformations required to make Viso2 work with my setup, any help will be greatly appreciated.

In the wiki says: "The coordinate frame of the camera is expected to be the optical frame, which means x is pointing right, y downwards and z from the camera into the scene.".

I have a ground robot (robotino), the base_link X axis points forward, the base_link Y axis left and the base_link Z axis points upwards and I have a stereo camera installed on the robot looking exactly to the front.

I configured a static transformation between my camera (stereo_cam) and the base_link of my robot (base_link) using only a rotation so the Z axis of the camera frame points forward, the X axis right and the Y axis downwards. I also enabled in the Viso2 parameters the publishing of the /odom to base_link transformation.

However, with this configuration the base_link doesn't move in the x-y plane of the odom frame as I expected but instead is floating around.

Now, watching the youtube video in viso2_ros wiki I noticed that the X axis (the red one) on the /stereo_dow frame is pointing down... shouldn't it be oriented with the Z axis (the blue one) looking down instead?.

Thanks in advance.

@raultron
Copy link
Author

raultron commented Aug 17, 2016

I already found the problem thanks anyway. Here I leave my launch file in case it is usefull for somebody else:

<launch>
   <!-- Arguments -->
  <arg name="camera" default="vrmagic"/>

  <!-- Transform from base_link to camera frame -->
  <node pkg="tf2_ros" type="static_transform_publisher" name="camera_frame_tf"
    args="0.1 0 0 -0.5, 0.5, -0.5, 0.5 base_link $(arg camera)" />

  <node name="vrmagic" pkg="vrmagic_camera" type="vrmagic_camera_node" output="screen">
        <param name="enable_logging" value="false" />
        <param name="left/port" value="1" />
        <param name="right/port" value="2" />
    </node>

  <!-- Run the stereo image proc -->
  <node ns="$(arg camera)" pkg="stereo_image_proc" type="stereo_image_proc" name="stereo_image_proc" />

  <!-- Viso2 -->
  <node pkg="viso2_ros" type="stereo_odometer" name="stereo_odometer">
    <remap from="stereo" to="$(arg camera)"/>
    <remap from="image" to="image_rect"/>
    <param name="odom_frame_id" value="/viso_odom"/>
    <param name="base_link_frame_id" value="base_link"/>
    <param name="sensor_frame_id" value="$(arg camera)"/>
  </node>

</launch>

I only have one problem though. When the robot is not moving I have a continuous drift upwards, any idea which parameters should I modify for best performance?. My robot is an omnidirectional robotino with a maximum forward speed of 1m/s. Thanks!

@miquelmassot
Copy link
Contributor

Hi @raultron,

you probably had the transformations swapped. The camera frame must be a child tf from base_link.
Regarding your upwards drift, try enabling ~ref_frame_change_method and see if it improves. Also maybe check if ~refinement set to 2 stabilizes a little bit more the output.

@raultron
Copy link
Author

Hi @miquelmassot,

With this settings I don't have any drift anymore :-) :
~ref_frame_change_method = 2
~refinement = 2

By any chance do you have any other tips for better parameters when using robots in indoor environments?. I am doing a comparison with a ground truth and I want to make the comparison as fair as possible.

Thank you very much for your input.

@miquelmassot
Copy link
Contributor

There is no clear answer.
Depending on how is your scene (lots of texture / textureless / featureless walls / corridors) I would probably try to see if the bucketing is enhancing or limiting the results. Try to reduce the width and height of the bucketing window to have more features evenly spaced in the image (if it is your case). If not, increase the window size and the max number of features to compensate textureless areas in the image with richer & textured objects that may not get as many features as they could.

I'll close the issue since the problem has been solved. Feel free to open it again if you need.

@raultron
Copy link
Author

Thank you @miquelmassot, the info that you gave me will be useful.

cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants