-
Notifications
You must be signed in to change notification settings - Fork 55
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
Cartesian control #178
Comments
no worries @vopsi99 and thank you for raising this issue. In principle yes, in practise users have to put in some effort to do this right now. I can pinpoint you to some examples and try to improve the demos. What are you trying to achieve:
|
I managed to move the end-effector incrementally but it is really unstable, so I need to move to an absolute pose with a certain velocity. I supposed this kind of motion would be the best to further integrate a stereo camera to position the robot in correlation to some markers in the workspace. |
so there is a demo here: https://lbr-stack.readthedocs.io/en/latest/lbr_fri_ros2_stack/lbr_demos/lbr_demos_advanced_cpp/doc/lbr_demos_advanced_cpp.html#pose-controller You'd have to add a node that sends your desired pose. This can be done in Python, similar to this e.g. https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_demos/lbr_demos_advanced_cpp/src/pose_planning_node.cpp |
So I should only send from another node my desired pose to this demo? This is the demo that I modified to send incremental values for x,y,z on position and orientation, but on Y orientation, for example, it always went crazy even if I was doing really small movement increments. |
okay I'll have to double check this demo, as it was community contributed. But this demo sends an absolute pose. You will have to make sure you:
|
I think this demo needs an update and should really allow users to control a velocity rather than absolute poses maybe |
Yes, I realised that a really small increment (0.001) would make the movement smoother.For positioning on x,y and z everything seems fine, but when I am trying to orient it, it just breaks everything. After sending the increment on Y for longer it tends to jump into a position and i get the inverse kinematics failed error. I think velocity control would be really useful for everyone. |
thank you for the feedback. Let's add support for this then. |
Hello, I am back. I am the contributor for "pose control". The initial pose and position in this demo is singular to some extent, so that it can only support the movement in z axis. However, if we want to orient it, the inverse kinematics would be calculated in a wrong way.
Another suggestion is, when you are not sure whether the position and pose is a singular one, please run it in Gazebo or other simulation environment first instead of real robot and print the inverse kinematics solution in "pose control node". Comparing it with the current joint position, it is wrong when these two values differ a lot. Hope it is helpful and please contact me if any other problems. Thank you. |
I checked all answers, but I didn't find any information related to velocity control (maybe I missed something). Could you please give me a demo of how to achieve the velocity control of the end joint of the robotic arm? |
hi @TalentLeshen-DLUT. Currently the quickest means of controlling the twist is to run ros2 launch lbr_bringup hardware.launch.py \
ctrl:=twist_controller this creates a topic under
|
@mhubii Maybe I'm too stupid! I tried running twist_controller and sent linear_msgs and angular_msgs to /lbr/command/twist_controller, which you'll see in the code below. I found that the movements of the robotic arms were not the same as I expected, they were about 10 times different (10 times different in the y direction, with a small error in the xz plane).
Next, I tried to make the arm go in a straight line. You can see the code below. I wanted the arm to move 100mm in the y direction, but in fact it only moved about 10mm.
I guess this error has something to do with the fact that I didn't set the acceleration, because when I set the acceleration of y to 1, the arm started to move sideways at a fairly fast speed, but this movement was obviously incorrect. : ( |
everything is fine on your end @TalentLeshen-DLUT (please bear in mind
Configurable here:
You can set |
@mhubii Based on my tests, joint position tau does not appear to be a control parameter for the smoothing command. We guess this is a receiving parameter on a frequency. Because when we increase it, the robotic arm can't receive all the information, and when we decrease it will vibrate. So I adjusted this parameter to 0.01, which is consistent with the message frequency. I'm trying to adjust the Cartesian gain in the twist controller.
I changed its value to (1.6, 1.35, 3.5, 1.0, 1.0, 1.0), and the accuracy of the robot arm was improved to some extent. At present, in the y and z directions, its accuracy has reached about 0.02mm, but in the x direction, its accuracy is about 1.1mm. I want to improve the accuracy of the x direction, but I am at my wits' end. Can you give me some suggestions? |
Also, I ran the ros2 topic echo /lbr/joint states and it shows the following:
I'm not sure if the order of the joints will make a difference to the result. |
you could add some form of PID. I.e., specify a target trajectory, then compute a
Yes, so this is the default
|
Hello, I tried using this repository but my knowledge in ros is rather mediocre. I am curious if this stack has cartesian control implementation or not.
It may be a stupid question, but I am stuck for quite some time and I could really use some help..
The text was updated successfully, but these errors were encountered: