Closed ijnek closed 2 years ago
I kind of liked the bounding boxes in there, but it seems a bit duplicated in some of the messages. But e.g. a diameter alone is less descriptive. What should be sent if e.g. a YOLO detects a bounding box that is not exactly square?
Also regarding the goal post. I would actually prefer to drop the top and bottom points as well as the width because an angled bounding box is able to describe it sufficiently and the standard bounding box has a theta angle for this case.
Similarly, the center ellipse can be fully described by a bounding box. Doing it with a center point + width and height seems unnecessary to me.
I would like to keep the primitives similar instead of using a top and bottom point for one and center + with and height for another. Especially of they are equivalent. This helps later on with further processing in the pipeline as well as more general drawing functions for debugging purposes.
We should discuss whether we should have a:
If we go with the former, we must decide on using boundingbox or something else, this conversation will continue. If we go with the latter, then we can include both in the msg.
My instinct says that the former is what we want. Let's discuss tonight over a call if you have time. I think we should make clear where these messages are intended to be used in a regular soccer robot architecture.
Hi! I'm sorry, I've lost track on how the message discussion progressed. Could someone provide a short overview, please? Thanks.
I think the changes in this PR aren't desired anymore so I'm closing this one off.
In regards to the conversation that was taking place, we want a minimal representation, where the receiver must convert the data into what they want to use. I think we didn't come to a consensus on what the fields of the messages should be.
I had Bounding Box information initially so that it's easy to visualize the detections, but I think such attributes that seem to almost be purely for "debugging", can be published on a separate topic with a BoundingBox2d array msg.
For example, with Ball.msg, I expect having the diameter is more useful than having the bounding box, for modules that would be listening to the msg.