-
Notifications
You must be signed in to change notification settings - Fork 23
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
Dock target pose offset sign #47
Comments
First, I'm not sure we actually support the case where you have the sensor in front and then need to back into the dock. That's what ros-navigation/navigation2#4403 covers the need to add. So I'm wondering a bit if some of the issue you have is w.r.t. that. How are you doing your 180 turn now or is the smooth control law doing the swing around?
I think this is pointing to the fact that your dock orientation is incorrect or at least unexpected from the output of your detector (or using non-detection based semantic labels?). If using the simple charging dock, we have some fields that help with applying rotations from the detected-frame to the dock-frame for the Apriltags case by default ( opennav_docking/nova_carter_docking/params/nova_carter_docking.yaml Lines 29 to 31 in a3b14ff
Since we're applying the backward projection distance to the pose at the |
Sounds like we're done here then :-) Definitely having the setting for "observe forward -> rotate 180 -> dock backward" is a useful feature and discussed in ros-navigation/navigation2#4403 for that reason! |
It's not what I meant. The camera on the robot is facing backwards (in the direction of the docking station and in the direction of movement). The marker pose is pointing forward (from the docking station torwards the robot).
I have tried this before opening the issue, but for some reason the controller fails to lead the robot to the target pose. I have recorded the behavior of the robot failing with the intended settings (e.g. detected pose pointing in the direction of movement)... original.mp4...and also the opposite (with the diff above) which does succeed. fixed.mp4(Arrow colors legend: light blue: staging pose, light green: detected pose, orange: dock pose, darker green: actual target pose, which is the dock pose plus 0.25 m offset) |
Ah ok! Then not a problem for you. Did you set Its possible that there's a bug here... But it seems to me that
Can you explain why you made that change to The |
I checked again and I found the problem. The equations for the smooth control law weren't originally designed for backward motion. So, we had to 'reverse' them to allow this kind of motion.
I said this thinking in the graceful controller, where the backward motion works, as it shown in the picture: I looked at the code and found where the backwards motion is used: And... yes, both the coordinates inside the equations and the motion target are flipped so that the trajectory is generated in the right way. This flipping behaviour is inside the graceful controller instead of the I've found another minor bug in checking this, so give me a few of days to fix it. |
OK, sounds good to me! Thanks for the investigation, always good to find and understand root cause so that we know the solution won't mask other more subtle issues. I look forward to it! |
So @ajtudela's fix will probably solve this, but for the sake of being complete I'll answer the questions.
Yes, I didn't touch it.
I guess you could say the orientation was right and I "made it wrong" in the second video. What happens without the "fix" is that the actual target pose is placed closer to the robot, so the dock pose is never reached and the tolerance checker never triggers. Here's a video to show this. third.mp4 |
That looks familiar - that's the end of the curve (the reason we added that additional 0.25m in the first place to avoid that behavior right up against the dock!). OK looking forward to the PR! Also, reopening this, I didn't mean to leave it closed and sounds like actions are coming of it that we should track! |
Hi @redvinaa I've fixed the backward motion for the graceful controller here: ros-navigation/navigation2#4527 Because I don't have a robot with sensors in the back, could you try this branch: https://github.com/grupo-avispa/opennav_docking/tree/fix_backward when the PR is merged? Thanks a lot! |
I cherry-picked these to my humble branch, and it works now! |
@ajtudela that looks good to me, can you open a PR for that against the 2x repositories? Should be easy for me to merge! |
Hi Checking with you guys, do i only need to get the latest graceful controller fix, will solve the backward docking issue? As my hardware setup is that camera on robot is also facing backward. Any amendment needed to do on
Best, |
Hi @HappySamuel |
@HappySamuel I just backported #51 to humble: 5a3883d. I checked and I didn't backport the graceful changes to humble yet, so I'll do that now ros-navigation/navigation2#4566. Sorry, juggling the 2 repos with 3 distros left Humble in a state of musical chairs. That should put rolling, jazzy, and humble all back in good states. I think we're all set now! |
I noticed that when docking backwards (the plug is on the back of the robot, with the detected maker pose of the docking station pointing forward towards the robot), the target pose offset is applied in the wrong direction. Here is the change that solves it for me, but I'm not sure if it's a real bug or a problem with my setup.
The text was updated successfully, but these errors were encountered: