Move ball sense to evaluation and add quick disabling on a per robot basis.

[liquidmetal9015]

Description

Ball sensors in the form of break beams in the mouths of our robots detect if the ball is in position to be kicked. This hardware often has issues from damage or misalignment and so last year we had to use the global camera system instead. #1373 was a quick fix to re-enable ball sense but we would like a more permanent and flexible solution. We want a way to very quickly enable and disable ball sense ideally on a per-robot basis and to unify ball possession determination.

(slightly unrelated note: evaluation in situation analysis needs to be unified too but that will come later as more flexibility may be required)

Requirements

• All ball possession based calls are made through evaluation functions (evaluation.ball.robot_has_ball)
• There is a way to specify which of our robots have ball sense functional by number (probably a dict with a default value)
• The evaluation function has a parameter to determine if we want to use ball sensor data in determining possession (for the sake of consistency between our team and theirs when needed)

Design

The design should be pretty straight forward. This PR should also remove all OurRobot.has_ball() calls in plays code, since the point is to use the evaluation function. I could also imagine an argument for making another function outside of robot_has_ball or using another solution to this problem, feel free to propose one.

An extension would be to add ball sense disabling to the soccer UI, possibly on a right click drop-down or check box on each robot. I would prefer this as I despise changing code close to a match but I understand if we decide it's not worth our time.

Since this doesn't have a design document and it was awhile ago that we talked about it, @JNeiger @kylestach @tjones320 @chachmu (I think we talked about it in September) does this check out with how we would want this done?

[JNeiger]

When I always was planning this, I went the other way and wanted to implement all this in the OurRobot/Robot class. Where the Robot class would have the triangle method to figure out if they have the ball while OurRobot will override that. There used to be some fancy stuff on firmware to see if the ball sense even worked so we knew whether it was a false positive or not. If we detected a failure, we could revert to the Robot implementation instead of using ball sense.

This way will work as well, it's just where we want this stuff. I always felt that UI stuff interacted cleaner with C++ personally. I think it also fits better in C++ on the architecture side since, in my mind, the python is only there for autonomy code.

[liquidmetal9015]

Going along with what @JNeiger is saying, @kylestach is looking at re-configuring the C++ side per-robot configuration, which includes per robot ball sense configuration that currently doesn't do anything. The solution to this should probably be integrated with whatever we choose there going forward and integrating that into the python layer for checking possession for strategic code. (Although a short term measure may still be desired)