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

URSIM and RVIZ coordinates does not match #570

Closed
marioesteban11 opened this issue Dec 12, 2022 · 8 comments
Closed

URSIM and RVIZ coordinates does not match #570

marioesteban11 opened this issue Dec 12, 2022 · 8 comments
Assignees
Labels
solution proposed A solution has been proposed

Comments

@marioesteban11
Copy link

Hi everyone,

I'm in ROS2 Humble, Ubuntu 22.04 and using UR3e robot

Im using Moveit and URSIM to move an ur3e robot, but I see that coordinates in both simulators does not match.

coordinates_URSIM

coordinates_RVIZ

Both of them are suposed to be in the same position:
x = 0.12522;
y = 0.13587;
z = 0.51750;

IT seems that X and Y coordinates are denied and Z seems to be correctly.

But my problem comes with orientation. I Know that ROS works with quaternions, but UR works with euler angles, if I'm not wrong.
I was wondering, if there is a missmatch between position coordinate, how can I know if my orientation are well done or I have to do something else to fix orientations. Thanks in advance.

@fmauch
Copy link
Collaborator

fmauch commented Dec 13, 2022

Please note that there are two coordinate frames: base and base_link. According to https://gavanderhoorn.github.io/rep/rep-0199.html#coordinate-frames base is aligned with the robot_controller's base frame, so this is equivalent with what you see on the TP.

I'll add some more elaborate description of how and why in the description (see UniversalRobots/Universal_Robots_ROS2_Description#49), but for now this should explain the discrepancy.

When setting your reference frame in RViz to base instead of world the frame tool0 should line up with the readings from the TP as long as your TCP has no further transformations from your flange.

What you see on the TP is not euler angles, but a rotation vector representation. When you click on one of the fields in the "move" tab, you'll enter the a mask where you can specify a target point. Here, you can select the rotation representation. Set that to "RPY"
image

Now, when we look at the transform in ROS, you'll see that both, position and orientation, do match if we select base as reference (tf2_echo uses a cut precision).

ros2 run tf2_ros tf2_echo base tool0
[INFO] [1670929176.397155576] [tf2_echo]: Waiting for transform base ->  tool0: Invalid frame ID "base" passed to canTransform argument target_frame - frame does not exist
At time 1670929177.348169086
- Translation: [-0.146, -0.328, 0.797]
- Rotation: in Quaternion [-0.713, 0.478, 0.116, 0.500]
- Rotation: in RPY (radian) [-2.236, 0.699, -0.830]
- Rotation: in RPY (degree) [-128.106, 40.052, -47.565]
- Matrix:
  0.516 -0.797  0.313 -0.146
 -0.565 -0.043  0.824 -0.328
 -0.643 -0.602 -0.472  0.797
  0.000  0.000  0.000  1.000

@fmauch fmauch added the solution proposed A solution has been proposed label Dec 13, 2022
@fmauch fmauch self-assigned this Dec 13, 2022
@marioesteban11
Copy link
Author

marioesteban11 commented Dec 14, 2022

Hi @fmauch, I finally understood this:

What you see on the TP is not euler angles, but a rotation vector representation. When you click on one of the fields in the "move" tab, you'll enter the a mask where you can specify a target point. Here, you can select the rotation representation. Set that to "RPY"

And the UR moves to that RPY orientation.

But this:
When setting your reference frame in RViz to base instead of world the frame tool0 should line up with the readings from the TP as long as your TCP has no further transformations from your flange.

I could not solve it, because each time I try to change from world to base, my rviz crashes, it doesn't matter if I change it while RVIZ is open or before open it changing the view_robot.rviz file. So I,m not able to do it correctly yet.

Meanwhile, I have another question. I dont really know to make the robot make "normal moves" because, each time I try to move it It does some crazy moves. I try to change joint limits, but it doesn't seem to work propperly. I dont know if you have any tip to do this. Because I need to do some precise moves like moving a glass of water to two different possitions and I cannot test this until I fix it in the URSIM. The planner that I am always using and it always connect is: geometric::RRTConnect

Thanks in advance

@TZECHIN6
Copy link

hi @marioesteban11, I am also working on URSim with Moveit2, I am using galactic and ubuntu20 for my environment.

I couldn't initial the "pointer" in Rviz to move the manipulator, is it automatically show up when you start Rviz with Moveit?

@marioesteban11
Copy link
Author

What do you mean when you say "pointer in RVIZ? Do you mean the "fixed frame" or anything else?

@TZECHIN6
Copy link

TZECHIN6 commented Jan 2, 2023

sorry, the pointer I am referring to is about the interactive marker, when I follow the commands to launch the Moveit example, no interactive marker shows up, and a warning says that the scene cannot be initialised.

I have created an issue but no help so far #575
Am I the only one who fail to start moveit example?

@yinguoxiangyi
Copy link

set the reference frame by following code

  using moveit::planning_interface::MoveGroupInterface;
  auto move_group_interface = MoveGroupInterface(node, "ur_manipulator");
  move_group_interface.setPoseReferenceFrame("base");

@yinguoxiangyi
Copy link

@marioesteban11 I have a question about how did you get the robot position in Rviz like following?

Both of them are suposed to be in the same position:
x = 0.12522;
y = 0.13587;
z = 0.51750;

IT seems that X and Y coordinates are denied and Z seems to be correctly.

thank you in advance.

@fmauch
Copy link
Collaborator

fmauch commented Apr 10, 2024

As the original question was answered in #570 (comment) I'll close this issue.

@fmauch fmauch closed this as completed Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solution proposed A solution has been proposed
Projects
None yet
Development

No branches or pull requests

4 participants