Add Balls.msg

[ijnek]

Up for discussion, which msgs should we use a Header for and which should we not?

[Flova]

I suggest that we call the array messages *Array.msg similar to e.g. the naming scheme in the humanoid_leage_msgs or the vision_msgs

[ijnek]

@Flova

In the case of SPL, there are two cameras, top and bottom. Do you reckon they should be transmitted from vision in one msg or two consecutive msgs on the same topic?

Also, if there was no ball detected in the image, would you expect an empty BallArray to be sent out or not?

[Flova]

In the case of SPL, there are two cameras, top and bottom. Do you reckon they should be transmitted from vision in one msg or two consecutive msgs on the same topic?

I would expect them to be on two topics in different messages. This is more flexible and doesn't enforce a synchronization between both cameras. It also allows for an empty array in case no objects were detected, this array has the same timestamp as the raw image message, so it is easy to transmit information regarding the absence of obstacles.

Also, if there was no ball detected in the image, would you expect an empty BallArray to be sent out or not?

As described above, I would prefer an empty message to show the absence of detections for this image.

[ijnek]

I agree with the idea of sending an empty array, in case there are no balls detected.

I would expect them to be on two topics in different messages

If vision msgs are on different topics for the two cameras, we'd have to write the localization and ball tracking modules to have one or more subscribers. My suggestion would be to transmit the vision info from both cameras on the same topic, but have different frame_id for the two cameras in the msg header. Make it the subscription's responsibility to make sure they check the frame_id of the camera.

[ijnek]

LGTM.

Also, a quick reminder, that has_confidence in the ball.msg should also be adapted to whatever we decide.

Nice spotting, I've made a new PR #7