Regarding OpenVINS frame, how to shift to robot frame, or any other rigid frame?

[Aishkrish18]

Hello, I have been using OpenVINS for quite sometime and it works really nice, thanks for the work. Although, i have a short question regarding the frames: From the screenshot, you can see /imu is the imu frame from the openvins, while /robot_base_link is opposite to it (this is the frame of the mobile robot platform im working on). I have created a new frame called /openvins which is 180 degree opposite to imu frame.

I want to bring the openvins frame OR Imu frame on top of robot_base_link. I also made a static transform publisher to make the global frame and the robots rigid frame the same. Im not sure where to add this offset or why does imu frame opposite to the frames of the camera?

I use ZED2 camera and its placed on the robot. Is it possible to compensate this? Since the camera is placed on the robot i want the imu frame on top of or on same place as robot frame. How can i do this? Is there some parameters that i need to change in openvins code?

In the below screenshot you can see the base_link frame which is the actually frame of the zed2 camera.

Thanks a lot in advance for your reply.

[goldbattle]

You would publish a static frame transform between the IMU to the robot body frame. The IMU to global frame is something that is dynamic as you move so it won't make any sense to have a static frame relative to the global. You can think of a chain of: robot frame -> IMU frame -> global frame will be used when you query the robot -> global transform on TF. Hope this helps.

[Aishkrish18]

Thank you for your reply. I had already implemented your idea earlier but i was not able to achieve the final output. Maybe i can explain the issue a bit more better.

Problem Summary: The issue I am encountering involves the relative positioning of the camera frame from openvins (/imu) and the robot frame in a mobile robot setup. Initially, when the robot starts, both frames appear to be correctly aligned in the same location. However, as the robot rotates, the frames start to shift away from each other while maintaining the same orientation. This behavior is unexpected and is causing localization inaccuracies.

Expected Behavior: I expect that the camera frame and robot frame should remain approximately coincident or maintain the same relative position throughout the robot's motion, including during rotation. They should not shift away from each other.

Although there is a positional offset, even after performing static transform with respect to the robot body frame, the behaviur doesnt seem to change.

The screenshot here is while starting OpenVINS and the robot. The orientation and position is perfect and as long as you move in a straight line without rotation, the frames align correctly. On rotating, the frames have a big and a dynamic changing offset which is also understandable since the camera is placed on one side of the robot and the rotation will make a circular path around the robot frame. But I want both the frames on the robot frame or just with a small positional offset. I have already tried to give positions with respect to robot base frame for /imu to shift them using static transform publisher but it didn't work.

Thank you so much once again for your answers.

[Aishkrish18]

In order to check this offset drift, I did a little experiment by placing the camera on top of a turtlebot. While testing its performance, even though the camera is on the robot, the positional offset is significantly big, which got me into thinking if the rate at which imu / images being published matter in anyway?

On merely testing only using the camera, the camera and imu also have an offset in position although i created a static transform for them to be same. Is it somethingto do with my calibration parameters?

[goldbattle]

Can you provide more detail on how you publish the static transformation, for example the launch file you are using that causes the problem. Are you able to reproduce the problem on the eurocmav dataset?

On Tue, Oct 10, 2023 at 8:33 AM Tetrix @.***> wrote:

In order to check this offset drift, I did a little experiment by placing the camera on top of a turtlebot. While testing its performance, even though the camera is on the robot, the positional offset is significantly big, which got me into thinking if the rate at which imu / images being published matter in anyway?

On merely testing only using the camera, the camera and imu also have an offset in position although i created a static transform for them to be same. [image: Screenshot from 2023-10-10 17-31-35] https://user-images.githubusercontent.com/47241581/273972028-f5ef9baf-0aeb-4805-912a-aa0fecca6a75.png

— Reply to this email directly, view it on GitHub https://github.com/rpng/open_vins/issues/386#issuecomment-1755700413, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ6TYURXKISCRVRD7WEHT3X6VTDXAVCNFSM6AAAAAA5S2IFWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJVG4YDANBRGM . You are receiving this because you commented.Message ID: @.***>

[Aishkrish18]

Sure, at the moment, as soon as i launch the robot and the camera, i just make a static publisher using : rosrun tf2_ros static_transform_publisher 0 0 0 0 0 0 robot_odom odom (this is to make the static frames of camera and the robot the same) After launching the ov_msckf subscribe.launch and initialising openvins , i establish a static transform with rosrun tf2_ros static_transform_publisher 0 0 0 3.14 0 0 robot_odom global (since imu's parent frame is global and on turning it 180 degrees with robot frame, imu faces the same direction as the robot) these are the two transforms i do.

No i did not try it with the eurocmav dataset.

[goldbattle]

This transformation shouldn't be correct. You need to attach a rigid transform to the IMU frame, not the global frame.

[goldbattle]

I believe you will need to do

rosrun tf2_ros static_transform_publisher 0 0 0 3.14 0 0 robot_odom global 
rosrun tf2_ros static_transform_publisher 0 0 0 0 0 0 imu robot_base_link

Where the imu to robot_base_link will need to hand measured or calibrated. This is a rigid body transform on the physical robot to the center of its chassis or center of gravity. The first publisher is just shifting your global frame, so I am not sure if this is useful other than helping with visualization.