-
Notifications
You must be signed in to change notification settings - Fork 1
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
[pose control] Header PoseStamped consideration added #35
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot accept - I set it to move in base_link with identity transform - this should give no movement, however it caused robot movement. It gave unpredictable results when Offset Tag is used.
Here is no tag:
Screencast from 07-25-2024 05:54:33 PM.webm
Here is tag of box entity used:
Screencast from 07-25-2024 05:55:31 PM.webm
Signed-off-by: Krzysztof Rymski <[email protected]> formating add include try/catch tryc catch part2 Resolving conversations Update Gems/ROS2PoseControl/Code/Source/Clients/ROS2PoseControl.cpp Co-authored-by: Piotr Jaroszek <[email protected]> Fixed bad movement Pose consideration Signed-off-by: Krzysztof Rymski <[email protected]> formating add include try/catch tryc catch part2 Resolving conversations Update Gems/ROS2PoseControl/Code/Source/Clients/ROS2PoseControl.cpp Co-authored-by: Piotr Jaroszek <[email protected]> Fixed bad movement
8757cde
to
37c9a1b
Compare
Rebased and tested |
I can't make it work with my example. I put two entities on the scene with ROS 2 frames ( I've added the
It was expected that
and nothing happened. It works when I set the frame to
|
Generally, I have written a more detailed documentation https://github.com/RobotecAI/robotec-o3de-tools/blob/kr/pose-controll-better-documentation/doc/UserGuide/PoseControl.md It will be merged in another pr, but first this needs to be resolved, you are missing transform from map frame to target frame. Therefore If you are saying I want to move this object in front of target frame, component tries to find location in relation to map. This is because this component is generally made to work in ROS 2 tf positions |
I see, in my testing I didn't encountered this as correct values were set when I was using goal position and then they persisted even when they were hidden, now I made thise settings visible once more |
TF tree in my example is a valid ROS 2 TF tree and the proposed system should also work. There is no reason to require |
As for the reference frame, I don't think this should be a requirement as well. We have TF API and we can get any transformation in a tree we want. Why do we need to stick to one, specified reference frame? We can get a transform |
Tldr, this will introduce even more feature creep, currently there are like 4 cases for goal messages now it will be 5 |
I'm not sure what cases you are referring to exactly. Let's make it work for all TF trees and with only the essential configuration needed. If the code is starting to look bloated, then maybe some alternative approaches should be considered. |
Is there a reason not to include the readme update here, in this PR? Why splitting it? |
@michalpelka Can you take a look one more time ? |
Based on #22