ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

How to close a path msg

asked 2020-04-29 06:27:23 -0500

Weasfas gravatar image

updated 2020-04-29 11:01:51 -0500

Hi all,

I was working in a path generation tool and I want to ask a question to see if this is possible since I did not manage to find a confident answer for my question.

The problem is the following: I have a ROS node able to extract nav_msgs/Odometry and convert its poses into a nav_msgs/Path. The path is working fine, and it is displayed correctly in Rviz but here is the deal; since the path have a start and end point, in Rviz it is being shown as a open loop path, while what I want is the path to be closed.

Does someone know a way to just close the path or join/merge the start/end points in order to generate a closed path, like a circle?.

Regards.

UPDATE:

In order to be more clear about how this is intended to work I will add here some important features.

  1. As I said previously, the path is extracted from nav_msgs/Odometry to generate a kind of "path mission". A low level control system of a vehicle is designed to iterate through the path points, computing the desire wheel steer to follow the path.
  2. Since we intend to use this path in a "mission", the path itself is cyclical meaning that the vehicle is designed to continuously traverse the path in a close loop.
  3. As you can see, the approach regarding a change on the msg type is not feasible, since it will suppose a change in all the rest of the control nodes
  4. Finally, I would like to remark a naive solution that consists on not closing the path but generating an additional end point extremely close to the start point. However I would like to know if there is indeed a solution to close the path without adding additional and "artifical" points to the dataset.

Besides this, take into account that the problem is mainly a visual one, since the control node is always traking the nearest point and it does not matter if there is a tiny gap between start and end points. But, what I want is to have a good visual representation of the path.

edit retag flag offensive close merge delete

Comments

Well, I'd say it does not make sense to do, as this is semantically something different. A path is something that has a start and an endpoint.

At least for visualization purposes, you could probably do with taking a geometry_msgs/PolygonStamped.

If this is not what you want, you probably need to explain a bit the background of how you intend to use whatever you create later on...

mgruhler gravatar image mgruhler  ( 2020-04-29 07:43:34 -0500 )edit

Hi @mgruhler,

I updated the post to be more clear and specific. Thanks!.

Weasfas gravatar image Weasfas  ( 2020-04-29 11:02:42 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2020-05-04 02:00:20 -0500

mgruhler gravatar image

Short Answer You cannot "close a path" using the nav_msgs/Path message, except for adding a last point that is identical to the first one.

If you only care about visualization, you could write another rviz plugin for the nav_msgs/Path type that takes the path (without any additional points) and displays it the way you want.

Long Answer

I'd say what you want warrants another approach then directly using the nav_msgs/Path anyways...

A few points to consider:

  • In your current setup, the start and endpoint would always be at the same position. Even though this might be fine for your current use case, this limits flexibility. You'll always only be able to start at that point. What happens, if you experience something on your mission (failure, event to react to, ...) that requires you to stop following the current path, and restart later. How would you find the point to start from your full path?
  • The nav_msgs/Path consists of an array of geometry_msgs/PoseStampeds. See the (expandend) message definition:

    std_msgs/Header header
      uint32 seq
      time stamp
      string frame_id
    geometry_msgs/PoseStamped[] poses
      std_msgs/Header header
        uint32 seq
        time stamp
        string frame_id
      geometry_msgs/Pose pose
        geometry_msgs/Point position
          float64 x
          float64 y
          float64 z
        geometry_msgs/Quaternion orientation
          float64 x
          float64 y
          float64 z
          float64 w
    

    This is 7 floats, a string, a uint32 and a time object per data point. Assuming your mission isn't just a few meters, this will be a lot of data. Except for the position object (three floats), the others are (most probably) unnecessary. (Most probably, because if you want to drive using the same orientation, you'd have to store the orientation as well, obviously. I'm assuming you are not).

  • The way you describe your "recording" of data, seems to be a path (actual path), where start and end points are pretty far apart. Otherwise you probably wouldn't suggest to artificially add another "end point" close to the start point. You should probably check if your end point and start point are sufficiently close to each other. Same holds for all other solutions.

Thus, back to my original suggestion: Use a geometry_msgs/Polygon (you actually don't even need the stamped version) for storing the points that you want to drive. If you care about orientation, go for geometry_msgs/PoseArray. Both of those types have an rviz plugin that you can use directly (though the pose array is shown as multiple arrows, so I'm not sure if you'd be satisfied with that).

Then implement a simple logic that creates the path from the polygon once you need to send it to the navigation. For a start, just take the polygon points in order, and you'd be right where you are now. But this could be easily extended to later start and stop anywhere "in between" by searching for the closest point on the path w.r.t. your current position and creating the new path from there.

edit flag offensive delete link more

Comments

@mgruhler Ok. Thanks for your detailed explanation about the problem. I will mark it as correct since the geometry_msgs/Polygon message type seems to fit very well with what I am trying to achieve. I already try it and it is a good solution for my problem.

Weasfas gravatar image Weasfas  ( 2020-05-04 08:02:32 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2020-04-29 06:27:23 -0500

Seen: 1,050 times

Last updated: May 04 '20