DragonBot Spring 2021
The game System File
Author/s: Charlie Alfaro
Table of Contents
The game System File
This file was design as an arrangement of functions that would accomplish the mission, by merging hardware and software logistics together. Due to different iterations and constantly updating functions, the game system file had several temporary variables that would be used to either store information or perform mathematical operations to them if necessary. Also, the game system contained information such as the maze matrix size, and temporary row and column information for constant initial position change.
Mapping the maze
Hardware constrains.
The logic behind this phase of the mission was free choice, it was also dependent on sensor utilization, shield position, and software approach. For our team there were many hardware aspects we had to dealt with inside the mapping function. One instance was the location of the RFID sensor. Given hardware positioning constrains, our robot had its RFID sensor positioned in the back of the as follows.
Thus, when exploring the maze, the robot would not sense the current room card but the card in the room ahead.
To deal with this constrain, depending on the direction the robot was facing, it would store the card information in the next room, for instance, if the robot were facing east when detecting a card, it would sum 1 iteration to the column, so the actual room where the card is located would be the next to the right.
Figure shows line of code dealing with the storing of the card info looking east.
The mapping
As far as the rest of the mapping the robot would sense the current room information and return it as a function provided by the navigation engineer, using Boolean operations the room and card info then would be stored in that specific matrix position. Then, it would go to the next room after collecting the necessary information.
Mapping sequence
As far as the mapping sequence, we followed a zigzagging pattern to cover each possible room. However, due to the constrains before we were obliged to specify certain steps before an actual linear mapping, such as reading a Card ahead and, obtaining the previous room information to determine if there was a wall or not behind the robot. The checklist for the mapping and sequencing went as follows. (Note that this sequencing only applies to our robot and its constraints).
For first and second square the robot would turn around to get the room information and card information, then it would map the rest of the lines sequentially and using a function would obtain the previous room wall and would add it to the current visited room. The purple ellipse represents the wall inserted in the new room.
The code for mapping a row east wise would go as follows.
To map it to the west, an inverted logic was utilized.
Aiding functions
As mentioned before there were several functions that aided the robot along the phases, for this, the game software created another C file to deal with every Boolean operation, or any other mathematical or iterations necessary unconnected to the main gaming function. Let us take as an example the function that return if a wall was behind the robot or not.
First, we obtain the previous room information, then, since we are looking it from a backwards perspective, we invert the bits, then we filter any unwanted walls, for this example we were looking at the West wall, and finally we would return that wall to be integrated to the new room information. This is one instance of the aiding functions used for the gaming system, yet it is integrated in the main .ino file, which means can be called by other team members if needed.
Calibrating the robot
Calibrating the robot required the team positioning the robot in a random spot in the maze, then the robot would wander the maze and determine its initial position. Fortunately for our team the tags used for the card reading had a specific and unique ID that differentiate them individually. Thus, for the calibration, the game software created two functions, one of them would store the ID with their respective column and row position, and the other one would read the ID and obtain that specific row and column where is stored. That way, the robot roaming the maze would encounter a Card and instantly know its position in the maze.
Given robot constraints, getting the location would require a code that checks for the direction and tells the robot that the room the card is in, is not its current but the room in front, thus, if the card is in front, the robot current location would add or subtract that column or row to determine initial position given a direction. Also, given that functions would not return more than one integer, this function would use pointers to return the column and row initial position values.
Conclusion
The Game Software Engineer was able to encode the first two phases of the mission, however, due to time constraints and a developing o a pathfinding algorithm, the team opted to change the mission to a more simplistic one.