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

Harcoded IMU frame and unpublished IMU TF #2617

Closed
arslogavitabrevis opened this issue Feb 8, 2023 · 6 comments
Closed

Harcoded IMU frame and unpublished IMU TF #2617

arslogavitabrevis opened this issue Feb 8, 2023 · 6 comments
Labels

Comments

@arslogavitabrevis
Copy link

arslogavitabrevis commented Feb 8, 2023

ROS Version: Humble

Actual behavior:
The imu optical frame does not include the "camera_name" parameter and it seam to include the default camera_name "camera". Also, the TF for the IMU frame is not published as we can see using tf2 view_frames.

Additional remark:
The IMU_OPTICAL_FRAME_ID is defined at the line 64 of the file base_realsense_node.h and used at the line 920 of base_realsense_node.cpp. It seam that contrary to the other frames ID defined at the beginning of base_realsense_node.h the IMU_OPTICAL_FRAME_ID does not take the sip parameter.

@MartyG-RealSense
Copy link
Collaborator

Hi @arslogavitabrevis It sounds as though your query may be similar to another issue from a few weeks ago at #2602

@arslogavitabrevis
Copy link
Author

Hi @MartyG-RealSense , thank you for following up with me on this issue. I thinks as you this issue is similar to #2602 , but it has some differences. From my understanding here are those differences:

The #2602 is noting discordance between the Readme file and the the real behavior of the robot as the parameter "base_frame_id" is supposed to drive the odom frame from what is wroten in the readme, but in reality this is the "camera_parameter" that is used to build the odom frames.

This issue is about the "camera_name" parameter kept to default value specifically for the IMU_FRAME_ID and IMU_OPTICAL_FRAME_ID. From the code, it seem that this was not the intended behavior and it sound more like a bug that a enhancement as the #2602 was tagged.

Here is some line from the lines 61-65 "base_realsense_node.h" that I think may be related to the bug:

#define FRAME_ID(sip) (static_cast<std::ostringstream&&>(std::ostringstream() << _camera_name << "_" << STREAM_NAME(sip) << "_frame")).str()
#define IMU_FRAME_ID (static_cast<std::ostringstream&&>(std::ostringstream() << _camera_name << "_imu_frame")).str()
#define IMU_OPTICAL_FRAME_ID (static_cast<std::ostringstream&&>(std::ostringstream() << _camera_name << "_imu_optical_frame")).str()
#define OPTICAL_FRAME_ID(sip) (static_cast<std::ostringstream&&>(std::ostringstream() << _camera_name << "_" << STREAM_NAME(sip) << "_optical_frame")).str()
#define ALIGNED_DEPTH_TO_FRAME_ID(sip) (static_cast<std::ostringstream&&>(std::ostringstream() << _camera_name << "_" << "aligned_depth_to_" << STREAM_NAME(sip) << "_frame")).str()

We can see that the other frame definition have this "(sip)" parameter, but not the IMU_FRAME_ID and IMU_OPTICAL_FRAME_ID.

Here is the output of "ros2 topic echo /front_camera/imu"

header:
  stamp:
    sec: 1676469793
    nanosec: 484447232
  frame_id: camera_imu_optical_frame
orientation:
  x: 0.0
  y: 0.0
  z: 0.0
  w: 0.0

Here is the output of "ros2 param get /front_camera/front_camera camera_name"
String value is: front_camera

(this may be in an other issue) Also, I noticed that the "{name}_imu optical_frame" is not published in the tf tree as we can see using tf2 tools.

Screenshot from 2023-02-15 09-09-22

@arslogavitabrevis
Copy link
Author

See pull request #2627

@MartyG-RealSense
Copy link
Collaborator

MartyG-RealSense commented Feb 15, 2023

Thanks very much @arslogavitabrevis for the PR! The RealSense ROS developer team member Niz-Az who is commenting on your PR will be the best person to direct questions about this issue to.

As you have created a PR, I have added an Enhancement label to this issue to indicate that it should be kept open whilst your PR is active.

@arslogavitabrevis
Copy link
Author

It seem that the problem was already corrected in the source. I was previously doing my test with the binary version 4.51.1. Thank you for following with me on this issue.

@MartyG-RealSense
Copy link
Collaborator

You are very welcome, @arslogavitabrevis - thanks very much for the update!

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

No branches or pull requests

2 participants