maracatronicsrobotics / suassuna-dummy Goto Github PK

These vision filters are essential due to the dynamics of vision packages:

• Each camera sends a vision package (we usually have at least 4 cameras in the field, where each one is responsible for a quadrant)
• Of course, in some packages sent by a camera, the player will not be seen in the analyzed quadrant and is at risk of being excluded from view.
• As the cameras are subject to real-world problems (luminosity, for example) eventually some false objects can appear and be considered, something that can seriously undermine AI decisions.

For this, it is essential that the vision has the basic noise and loss filters.
The loss filter will prevent objects from being disposed of quickly, that is, it will ensure that the object seen in camera 1 remains even if camera 4 does not see it, for example.
The noise filter will prevent random objects (generated by some camera problem in the real environment) from being considered automatically, that is, they will only be considered after they appear for a certain time.

The actuator will be our module responsible to send commands to the robots (like as wheel speed, dribbling, kick).
As we will be working in two different environments (real and simulated), we have different ways of executing the sending of this data:

• In the real environment, we send via radio commands (usually).
• In the simulated environment we send commands via the network (using protocol buffers).

So, for the creation of the actuator module, it is ideal that we can create a set of virtual functions, so that after inheriting the Actuator class we can fill them properly according to the environment we are going to work with.

The WorldMap will be responsible for capturing, maintaining and distributing the data that comes from the vision module.
In a simple way, it is there that the information about players, ball, goal and field will be made.
It is also ideal that the reception of packages containing such information is done through signal / slot, so that we can make a more direct bridge between the modules.

The world module will be primarily responsible for the maintenance of all other entities in the system. It is there that we will also make the intercommunication between the modules, so that the coach module can send data to the actuator module or even request data from the vision module.
It must maintain a Hash Table whose key will be the priority of the entities, so that we can initialize them formally following the definition we had made in issue #1.

The Constants class will allow us to define parameters for all the code by querying in just one place and also changing a single file (preferably a JSON).

These files are needed because all the communications in the system (either vision or commands for robots) uses protocol buffers in network, so we need to add and compile them in our software for future use.

The Coach module will be responsible for maintaining the team, assigning actions to the players on the field.
Basically, it will be divided into 5 main components:

• Skills
• Behaviors
• Roles
• Playbooks
• Coach

Skills will be the atomic actions of robots, such as walking, rotating, dribbling, kicking.
Behaviors will be complex activities formed by the mixture of skills, such as walking while spinning, ball interceptions, etc.
Roles are formed by this set of behaviors, appropriately forming a soccer role, so this means that Roles will literally define the functionality of each player on the field.
Playbooks will be the sets of these Roles that will form a soccer team, that is, Playbooks will define the formation that players will take on the field.
Finally, the Coach will be responsible for selecting the best formation to be played given certain game situations.

Obtain the field data by the geometry sent through the vision packages or by pre-defined classes that contain these values.
It is vitally important to implement several methods to pick specific locations on the field (such as goal positions, sides, etc.) to execute strategy actions.

The Entity class will be our main class for the upcoming threads (modules) in the project.
It should be thread-safety and contains functions for starting priority (cause some threads need priority above others), loop frequency (the thread will run "x" times for second where "x" is the frequency) and functions to enable/disable the loop() method 'cause some threads (like the enemy players or not active players) maybe don't need to run.

The vision module is totally focused in capturing the upcoming data from cameras (or simulator) and process it.
It may be an Entity in our system and have an UDP Socket that will capture the upcoming data from the network (for default we'll use 224.5.23.2:10002) and will print those data.
In the future, this module will be associated with another one (an "world" module), that will be the one that the coach will make it consults for get players/ball positions and angles.

We need an ExitHandler to wait all entities in the software to close and avoid memory leaks when leaving prematurely.