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

Add target waypoint to Rviz dynamic waypoint publisher #43

Open
JMoore5353 opened this issue Jun 10, 2024 · 4 comments
Open

Add target waypoint to Rviz dynamic waypoint publisher #43

JMoore5353 opened this issue Jun 10, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@JMoore5353
Copy link
Contributor

JMoore5353 commented Jun 10, 2024

The visualization currently plots all waypoints and numbers them. Sometimes it is hard to know what the target waypoint is. Add something to the visualizer to know what the next waypoint is.

Also maybe plot the orbit?

@JMoore5353 JMoore5353 self-assigned this Jun 10, 2024
@JMoore5353 JMoore5353 added the enhancement New feature or request label Jun 10, 2024
@iandareid iandareid moved this to Do Later in v2.0 Release Jun 12, 2024
@JMoore5353 JMoore5353 moved this from Do Later to In Progress in v2.0 Release Jun 12, 2024
@JMoore5353
Copy link
Contributor Author

The visualization now has an arrow marker pointing to the target waypoint.

A TODO still left is to plot the orbit path when flying an orbit.

@JMoore5353
Copy link
Contributor Author

JMoore5353 commented Jun 14, 2024

@iandareid I have some thoughts about how to implement plotting the orbit.

  1. We could have the path_manager call a service in the rviz_waypoint_publisher whenever the orbit_last parameter is changed.
    • Pros:
      • The orbit will be plotted or removed immediately following the parameter change. Low latency.
      • Only the exact number of parameter changes or service calls are made. No excess calls.
    • Cons:
      • Path manager will have to query to make sure GCS is running
      • Less separation in the code between GCS visualizer and path manager
  2. rviz_waypoint_publisher queries path_manager's orbit_last param at a certain interval, or whenever waypoint indices are incremented.
    • Pros:
      • Separation of code. No dependence on the GCS visualizer in the path_manager
    • Cons:
      • Orbit marker won't update immediately following a orbit_last parameter change
      • Orbit marker won't appear at all sometimes (if the orbit_last parameter is changed at just the wrong time)
      • Many unnecessary parameter queries or service calls.

What are your thoughts?

It is also worth noting that the path_manager already has some "contamination", meaning that it has to publish a target waypoint for the visualizer. However, this doesn't rely on or look for a specific node in order to call a service.

@iandareid
Copy link
Collaborator

@JMoore5353 I think that having them as separate as possible is better. Another factor that may influence your decision:

  • It would be useful to see the orbit that it is following through the fillets as well.
  • Whenever the aircraft follows an orbit, /current_path publishes the center of the orbit and the radius.
    • We could just extract this data and only plot the orbit as it is following it. This would include orbit last.
      • This would have the downside of not visualizing the paths before or after they are actively being followed, but it would be simple and give us the behavior we would like.

So in short maybe there is a third option? I think either of the things you propose would be great, but I would suggest that the less decoupled version may be better.

@JMoore5353
Copy link
Contributor Author

That's great, I like that option better. We would only see the orbit / fillet when the aircraft is following that part of the path, but I think that is acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

When branches are created from issues, their pull requests are automatically linked.

3 participants