Draw Virtual Obstacles

[Mr-Anyone]

Description

Have the ability to draw virtual obstacles. I think this is terrible UI design but it works for now. The way you use this is that you shift click to add points of a polygon. By pressing q, the polygon is saved to the stack, so you can create a new polygon by shift clicking again. Pressing w would remove all the polygon.

I am not sure what the most user friendly way to draw these obstacles, so please give some feedback.

See below for a video of this

Testing Done

I am going to maybe write a sensor fusion test some time later?

Also, I am probably going to field test test to see if it can avoid virtual obstacles in real life.

Resolved Issues

resolves #3367

Added virtual obstacles for testing and visualization purposes.

Length Justification and Key Files to Review

N/A

See the entire video here:
Screencast from 2024-11-11 06:01:02 PM.webm

• Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• Remove all commented out code
• Remove extra print statements: for example, those just used for testing
• Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

[Mr-Anyone]

Also, highly likely that the code is buggy.

[notion-workspace]

New layer to draw obstacles on the field widget

Comments addressed

[github-actions]

This PR is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This PR was closed because it has been stalled for 5 days with no activity.

[GrayHoang]

Small clarifications, maybe some comments would be nice to explain certain actions? but it seems like it works to me

[GrayHoang]

This sends the same list to the fullsystem if the list of obstacles can't be updated. Do we need to send the list of obstacles every time as a proto? Or can we eliminate some of that call and have it not update the list of obstacles?

[Mr-Anyone]

Do we need to send the list of obstacles every time as a proto?

Yes, you need to in the current implementation.

Or can we eliminate some of that call and have it not update the list of obstacles?

We could totally do that. Correct me if I am wrong, but you're suggesting that instead of sending the entire array, we only send the entries that were recently updated by the widget, right?

The main issue with that approach is that it requires implementing a linked list-like ADT and adding more abstraction on top of the VirtualObstacle proto. For example, imagine adding virtual obstacles in this order: A, then B, then C. If you later remove C, handling that on the C++ side becomes a bit tricky. You can use std::erase_if, or something along the line, but personally, I find that approach a bit clunky.

Another complication is that the VirtualObstacle proto itself becomes more complex. You'd need to introduce a new Operation field—probably an enum with values like Create, Destroy, and Modify (which might be covered by Create again)—plus an id field to track objects. Then you have to handle all the edge cases: repeated Destroy operations, modifying a non-existent obstacle, conflicting Destroy and Modify actions, and so on.

In my opinion, the added complexity doesn’t bring much value, since you can likely get away with just sending a relatively small array (like self.obstacles plus self.points). Unless there's a strong reason to go with the other approach?

[Mr-Anyone]

Also, thank you so much for reviewing this. This is been an open PR for around a semester.

[GrayHoang]

Actually, I didn't quite mean that, although I see how that would have been implied.
Right now, from what I understand, this function will always send a proto of the obstacles to the full system. However, we may not actually need to send that proto, because the current list of obstacles may not be in a valid state (for example, the current shape has <3 points).

So then we don't need to send a proto here at all. What I'm saying is, we can move the protobuffer call inside the if statement, so that we don't call it when there is nothing to update within the list of obstacles.

[Mr-Anyone]

As in something like this:

diff --git a/src/software/thunderscope/gl/layers/gl_draw_polygon_obstacle.py b/src/software/thunderscope/gl/layers/gl_draw_polygon_obstacle.py
index da15075f9..28cdcec68 100644
--- a/src/software/thunderscope/gl/layers/gl_draw_polygon_obstacle.py
+++ b/src/software/thunderscope/gl/layers/gl_draw_polygon_obstacle.py
@@ -89,17 +89,17 @@ class GLDrawPolygonObstacleLayer(GLLayer):

     def __send_to_fullsystem(self) -> None:
         """Sending a list of virtual obstacles to full system"""
-        obstacles = self.obstacles.copy()

         # only send to full system when the points form a valid polygon
         if len(self.points) >= 3:
+            obstacles = self.obstacles.copy()
             polygon = Polygon(points=self.points.copy())
             obstacle = Obstacle(polygon=polygon)
             obstacles.append(obstacle)

-        self.friendly_io.send_proto(
-            VirtualObstacles, VirtualObstacles(obstacles=obstacles)
-        )
+            self.friendly_io.send_proto(
+                VirtualObstacles, VirtualObstacles(obstacles=obstacles)
+            )

     def __create_single_click_callback(
         self, event: MouseInSceneEvent

That would kind of make sense as well.

[GrayHoang]

Yeah exactly. Minor adjustment, but it might make a difference if it's updating a lot?

[Mr-Anyone]

done.

[GrayHoang]

Comment addressed.

[Mr-Anyone]

@GrayHoang Could you please approve again. I think William resolved a merge conflict which dismissed the approval.