Kick Decider - northern-bites/nbites GitHub Wiki

The kick decider is the system that is responsible for choosing the kick for the chaser to perform. It is written in Python and is made up of a KickDecider.py file, a KickInformation.py file, a kicks.py file, and (of course) the Constants file.

The decider deals with the calls from outside the system and has many functions, some that only it calls. The information class is supposed to contain all the information that must be reset or redetermined when the kick is redecided. The object based information lets us reset all of the object's variables etc. The kicks file houses everything that a kick is, including the "sweet spot" (relative coordinates from the center of the robot on the floor to where the ball should be), the sweet move, name of the kick, distance, heading, etc. Each kick is stored as a constant and individual parameters can be modified.

Currently, the decision is done based on localization. We decide an array of kicks for different purposes, such as scoring, passing, clearing, etc. And then decide on the best one (currently just the first non-null entry). Much of this code is still to be written, but this system requires the accuracy and precision of both vision and localization to function properly. Before expanding or reworking this significantly, we need to have better, more reliable low level systems. We need to build from the ground up because we have dependent systems of Vision --> Localization --> Behaviors. You can throw Comm in there too. Accurate, intelligent motions are dependent on the behaviors, but you can develop motions independently of good in-game behavior.

We switched to a localization approach because our kicking strategy is to see the ball and kick it as fast as possible. We don't orbit to get a better angle or even approach at an optimal angle at the moment. Panning the head up to look around once we are close to the ball was a previous strategy that led to a lot of success. However, it was often too slow and involves the kick decision system to essentially emulate the localization system for that brief period. This was deemed bad and with localization considerably more reliable than it was, the new strategy was employed. However, loc is still not good enough in many situations. There are still lots of bugs to be worked out, although the decision process is unit tested and proven to work. The problem lies in inaccurate localization estimates because of bugs in loc and inaccurate vision estimates. With the new robots, it may be possible to have an even better localization, simply from being able to see the ball and important landmarks even from close range. It may be better to approach the ball, then orbit to a good angle, then make a good kick. This would probably be much more vision based, but could rely on loc as well, in theory. Testing is needed. Also this is a system that would do very well in C++

Mexico 2012

Due to problems with the older system, the kick deciding system was hacked for Mexico City. The pre-kick pan was reintroduced, just before final positioning for the kick. The entire system is contained in HackKickInformation, including gathering information during the pre-kick pan, determining via heuristics which goal is which, and deciding which kick to execute. There is a flag to shortcut the pan and make all kick decisions via localization, but the particle filter is not currently reliable enough (especially after a couple minutes of play).