search

thien94 / orb_slam3_ros_wrapper

A ROS wrapper for ORB-SLAM3. Focus on portability and flexibility.
166 stars 76 forks source link

"unwarranted transformations?" #32

Closed torkle89 closed 1 year ago

torkle89 commented 1 year ago

I'm new to ROS and everything but I got this working. Only problem is the world orientation seems off by 90 deg in rviz. "Forward" for the camera and the world is "up" in rviz which makes the camera controls in rviz very awkward, it also makes orb3 interact awkwardly with other programs like octomap.

So I tried the previous version that had "unwarranted transformations" and with that version things seems to behave as expected. Up is up and down is down etc. Is this something I'm doing wrong?

thien94 commented 1 year ago

Thank you for the question.

It is true that previously the "unwarranted transformations" were added precisely to interact with other ROS packages. However, some users prefer the world orientation in the "SLAM" definition (the world orientation is the first KF orientation). Others might prefer something else.

So this time I decided to not alter the world orientation in any way (the way it is now) and people can add another transformation on top as they see fit. Perhaps the transformation can be available as an optional parameter in the launch file?

torkle89 commented 1 year ago

I see. The previous transformations seems to make things more beginner friendly so making it a launch option seems like a good compromise to me. I've actually had a lot of trouble getting orb2 or orb3 to integrate with ROS, trying a variety of packages and ROS distributions. This one was the first that worked for me without issues and just following the instructions (using ubuntu 20 and ROS1 Noetic). Your wrapper will totally save my bachelor thesis so thanks for that.

thien94 commented 1 year ago

I have added the params to rotate the world frame in the latest commit. Use the params world_roll, pitch and yaw to reorient the world frame to your liking. The euroc_mono.launch contains the example that works just as before.

Hope this helps.

javier99nl commented 1 year ago

Hi, I have been using this package for a while and I was using the version from 28 september (the one that removes the unwarranted transformations). So I as i am using the package with octomap aswell I assume that I should use these params (world_roll, world_pitch and world_yaw) of the newest version in order to work correctly with octomap and other ros packages as rviz.

What I have noted for a while is that the pointcloud's values and the camera/pose's are usually less than one or close to 1, but the thing is that i dont know if that is in meters or in other unit. For instance I do not really know if I should use Twc o Tcw, because as i understand Tcw is the transformation from the world to the camera, so if i want to publish the tf transformation where the parent is the world and the child_frame is the camera I should use Tcw, but in practice it works better and makes more sense Twc(the inverse), so maybe you dont use the same nomenclature as in Denavit Hartenberg transformation matrix. Regards, thanks in advance.

thien94 commented 1 year ago

Hi @javier99nl , thanks for your questions.

What I have noted for a while is that the pointcloud's values and the camera/pose's are usually less than one or close to 1, but the thing is that i dont know if that is in meters or in other unit.

If you are using monocular camera, then the unit is definitely not in meters. It is because monocular slam can only determine the pose up to a certain scale without any relation to metric unit. In general, the other cases (stereo, mono-imu, stereo-imu) should produce results in meters. But I have notice that sometimes the scale can be off a bit.

For instance I do not really know if I should use Twc o Tcw, because as i understand Tcw is the transformation from the world to the camera, so if i want to publish the tf transformation where the parent is the world and the child_frame is the camera I should use Tcw, but in practice it works better and makes more sense Twc(the inverse), so maybe you dont use the same nomenclature as in Denavit Hartenberg transformation matrix.

I also agree that using Twc is (transformation from camera to world) is the better choice, both in meaning and in actual values that we need. The problem is that we can only obtain Tcw, because that's always the return value from ORB-SLAM3's API (see the TrackMono/Stereo functions). Hence, in all of the nodes I have to start with Tcw, make the necessary changes before publishing the data. It is not ideal but unless the ORB-SLAM3 library is updated, that's what we have to work with. For the nomenclature, I also try to match all the notations with ORB-SLAM3 as much as possible (Tcw/Twc/Twb etc.).