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

Published a new message that contains: #1119

Open
wants to merge 3 commits into
base: melodic-devel
Choose a base branch
from

Conversation

michaelblindnology
Copy link

No description provided.

to the goal.

The message is published in context of feedback action.
@michaelblindnology
Copy link
Author

The new message: Path, which contains: current position, goal position, path length, and time left to goal.
The message published in the context of action feedback.

Copy link
Contributor

@mikeferguson mikeferguson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from the paths published by the local/global planners?

@@ -45,6 +45,7 @@
#include <geometry_msgs/Twist.h>

#include <tf2_geometry_msgs/tf2_geometry_msgs.h>
#include <move_base/Path.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should not be adding messages to move_base - there is a move_base_msgs package in a separate repo specifically so that users of nav do not have to build all of nav on remote machines that are monitoring outputs.

There is also a standard path message in nav_msgs, why not use that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
I used my msg instead of nav_msg/Path, since I need

float32 dist_to_goal # Path distance left to goal (m)
float32 time_to_goal # Time left to goal to navigate along path (s)

@pavloblindnology
Copy link
Contributor

@mikeferguson The idea of this message is to publish distance to goal along global plan plus estimated time needed to get to the goal.

@DLu
Copy link
Member

DLu commented May 18, 2021

It also probably makes more sense to make an action that publishes feedback, as opposed to creating a new topic just called feedback.

Also, I did something similar over with locomotor

@mikeferguson
Copy link
Contributor

It also probably makes more sense to make an action that publishes feedback, as opposed to creating a new topic just called feedback.

It seems really late in the ROS1 lifecycle to be adding an entirely new action interface to move_base.

@mikeferguson
Copy link
Contributor

The idea of this message is to publish distance to goal along global plan plus estimated time needed to get to the goal.

So, this looks quite non-generic: the estimate of distance remaining is straight-line (as opposed to the distance along the actual path) and the estimate of time remaining is quite likely inaccurate (it's just using the current speed, it has no idea what the future velocities might be, and the distance it's applied over is kinda wrong too as previously mentioned).

My suggestion would actually be to write a separate node (outside the nav stack) that subscribes to the plan already being published and computes the distance/time remaining and publishes it on a topic for your application.

@pavloblindnology
Copy link
Contributor

The real distance along the path should be just computed instead of a straight line distance. Then, the time estimation based on max speed is the best we can do. Also, action is not suitable as goal can come through move_base_simple and/or 3rd party other than the action caller may need this info.

@pavloblindnology
Copy link
Contributor

pavloblindnology commented May 19, 2021

Also, I did something similar over with locomotor

I heard about robot_navigation, but never tried. Is there any documentation on it?
How does it compares to move_base_flex, which seems to be more documented and maintained?

@pavloblindnology
Copy link
Contributor

It also probably makes more sense to make an action that publishes feedback, as opposed to creating a new topic just called feedback.

What about extending existing action feedback instead of publishing to a new message?

@mikeferguson
Copy link
Contributor

What about extending existing action feedback instead of publishing to a new message?

You can't change the action feedback - that would change the MD5 checksum of the messages, which would break API/ABI.

@pavloblindnology
Copy link
Contributor

pavloblindnology commented May 21, 2021

What about extending existing action feedback instead of publishing to a new message?

You can't change the action feedback - that would change the MD5 checksum of the messages, which would break API/ABI.

@mikeferguson Understood. Is there any chance to have this merged if publishing to a new message?

@DLu
Copy link
Member

DLu commented May 26, 2021

Other than knowing what the current linear velocity is, is there any part of this that you can't derive from other published material? You can get the pose from TF and goal from current_goal.

@pavloblindnology
Copy link
Contributor

Other than knowing what the current linear velocity is, is there any part of this that you can't derive from other published material? You can get the pose from TF and goal from current_goal.

Well, velocity and global plan can also be derived from other published material. But as for me, it's nice to have this functionality integrated. Just drop a goal in RViz and you start getting some important feedback. If this doesn't suit your vision in any way, please let me know, so that my team can plan another solution. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants