Objective

The purpose of this blog post is to summarize the work that has been done for the software design of the 3DoT PaperBot. The main objective was to code in Arduino C++ with the intention of having the 3DoT robot enter a room, detect the room it is in, find treasures, find equipment, kill monsters, and exit into a room given by the instructor. However, we eventually had to do a descoped mission of the robot entering the maze, finding a key, and exiting the maze.

Software Flow Chart

In the beginning of the semester, we created the flow chart of how the robot will be navigating throughout the maze. Ideally, we wanted our sensors to detect the ‘walls’ throughout the maze. As it is mapping the maze, it will record the memory of the wall in each tile and proceed forward. 

Mapping Phase

Given the maze encoding map:

The mapping phase would involve the robot scanning left to right. The robot would then update the rooms using a loop. Lastly, the robot has to keep track of the current room within.

We find out that each value is in hexadecimal. In addition, each hexadecimal gives the direction of the wall. 

The format of the bits would be as the following:

0000 = North, East, West, and South; It’s important to note that it is in that order

From here, we find out the location of the walls from the hexadecimal values. 

Based on the initial mission, we had to take into account what type of monsters there were, the types of equipment, and whether or not there is a treasure in that room. We had initially planned on having the data of the room as:

0x0A where the left bit will signify the treasures, type of equipment, or monsters and the right bit will signify the room type.

Example: 0x1A = Treasure and North & West Walls

                0x51 = Tier 4 Weapon and South Walls

Initially, I thought about the coding of the mapping phase where I could implement creating the array of the map. This would be accounted for as the ‘virtual map’ where the robot would be able to reference it to know where it is on the map. I would then create the code for the ‘real world’ where it would be in the SRAM memory of the robot. As the robot is mapping, if there is change in the real world compared to the virtual world, it would then update the room it is in. It may seem redundant to have both maps in the robot; however, initially I thought that the robot would know where it is on the map because it had the ‘virtual world’ map to reference off of. If there was any change between the ‘real world’ and the ‘virtual world’ it will update the new data into the ‘real world’. The problem with executing this mapping phase was the fact that I’m not very fluent in C++ programming. I believe the idea was heading in the right direction; however, the problem was producing the code that would make the robot do what I wanted it to do.

Given the help of the professor, we were to construct header/prototypes files to help in creating the code for the robots. Some of the header files would include making the map, calibrating the robot so it knows where it is within the maze, making a plan on how the robot will solve the maze, and executing the plan. In addition, we were grouped into a group where all the game software engineers would team up and try to combine forces to get the robot to do what we wanted it to do. These headers included:

game.ino

void setup(){
  Serial.begin(9600);
  initGame();     // Game Developer
  initNav();      // Nav Engineer
  initCard();     // Card Engineer
  initControl();  // Control Engineer
  delay(5000);         // 5 seconds
}

void loop(){
  updateGame();     // Game Developer
  updateNav();      // Nav Engineer
  updateCard();     // Card Engineer
  updateControl();  // Control Engineer
}

initGame(){
}

updateGame(){
  const int number_of_rows = 12;
  const int number_of_columns = 16;
  static uint8_t map[192];  // 12 x 16
  static uint8_t state = 0;
  switch(state) {
    bool done;
    case 0:
      done = Make_map(map[]);
      if done state = 1;
      break;
    case 1:
      done = Calibrate(&robot_t);
      if done state = 1;
      break;
    case 2:
      thePlan = Make_the_plan();
      state = 3;
      break;
    case 3:
      done = Execute(thePlan);  
      if done state = 4;
      break;
   case 4:
     VictoryDance();
     break;

   default:
     serial.println(“Help! I am lost.”);

At first each person in the group were designated a role. For example, an individual would be responsible for mapping the map while another person would be responsible in making the robot figure out where it is in the maze. Ideally this would have worked; however, I believe that the lack of expertise in C++ programming made it difficult to make what we wanted the robot to do into reality. There were other method that could have been used such as the pop/push method where we would find the exit first and record the data. From there, we would ‘push’ where it records every tile it goes through until it finds the key. When the robot occurs, it would ‘pop’ every data by reading it and then retrace its step until it finds the exit. This method would be more of a brute force method to completing the mission objective; however, due to time constraint and lack of fluency in C++ programming, we were unable to make this method go into reality.

Conclusion: The Final Project

The mission was later descoped for some groups, including the group I am in. This is because of the time constraint that we had as well as the professor deeming that we would not be able to complete the project on time. Instead of doing the original mission, the new mission will consist of the robot finding a key in a set spot, and starting from a certain tile and exiting the maze at a certain exit. For our project, we ended up using the fallback solution of the IR sensor. In addition, the robot was able to go through the maze from the correct starting point, navigate to the key, and correctly exit the maze. In our situation, we were able to get to the key and exit the maze through a deterministic path rather than having the robot find the key and exit on its own.