By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

This trade study is a follow on study to the color sensor trade study which simply investigated the ranges at which the colors using electrical tape (vinyl) would be detected using the TCS34725 color sensor. In this trade study I borrowed the cloth maze from The Robot Company to run testing on it with the TCS34725 color sensor. The goal of this trade study is to help give the projects an idea of where exactly on their robots the color sensor should be mounted. Or the development team of the color sensor PCB where the color sensors should be mounted on the PCB.

Methodology

In this trade study I used two devices, the Arduino Uno, and the TCS34725 color sensor. I connected the color sensor to the Arduino Uno in the configuration shown in the table below. Additionally, to read the values from the color sensor I2C communication was used. To implement this communication the Adafruit Arduino I2C communication library was used, this library is available online on the Adafruit website.

Table 1: Interface Matrix

This experiment was configured similar to the original color sensor test, however the color sensor was instead this time held above the cloth maze. A piece of paper with measurement tick marks was then placed next to the maze to measure the distance from either the side of the color sensor or the distance away from the color sensor. This piece of paper was used since rulers have a gap between the beginning of the measurements and the end of the ruler, and in this experiment the measurement had to start at the maze (not above it). The paper ruler is shown below.

Figure 1: Paper ruler used to measure vertical and horizontal distance.

Now using the maze I tested the three colors on the maze: white, green, and brown to determine the optimal vertical distance (distance away from color sensor). I did this by determining where I got a peak measurement and then called that the optimal distance for that color. I also measured at what distance there was detection and at what distance there was significant detection. Significant detection is defined as reading a value greater than 1000 for any of the RBG values. The maze used is shown below and the results of the experiment are below the figure.

Figure 2: Section of the maze used showing the white, green, and brown used.

Table 2: Color and Distance Detection (Part 1)

After this test was preformed another test was performed to determine the optimal horizontal distance for the color sensor. This distance is more subjective since you want to be far enough away from the sensor to not always be detecting the lines however you don’t want the response time of your robot to be too slow. For this test I measured two distances for each color, I measured the point the color is detected as well as the point at which the amount of detection significantly spikes. The origin or zero value would be in the middle of the color sensor. I then did this from the left and the right side of the color sensor, the left and right side of the color sensor is defined as follows. In this test the color sensor was placed at 1 cm away from the maze using a stack of post it notes to elevate the sensor above the maze. I did this test only for colors green and brown because white isn’t relevant for our particular applications.

Figure 3: Test setup to show which side would be the right side of the color sensor vs which is the left.

Table 3: Color and Distance Detection (Part 2)

Conclusion

What can be inferred from this trade study is that a vertical distance from the color sensor within a range of 1 cm to 1 mm is a suitable range. Overall, it appeared to be that the closer to the maze (vertically) the stronger your reading would be. Additionally as long as the color sensor is at least a horizontal range of 3 to 5 mm away (zero being the center of the color sensor) from the lines there will not be any significant unintentional readings. However if trying to ensure no detection when driving straight, a distance of 9-10 mm might be desired. Testing with the project specific robot and software will also be an important factor when deciding the layout and placement of the color sensors. This trade study is to be used in supplement with testing to give the engineers a good starting point when designing the color sensor layout.

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

To navigate throughout the maze we must record and update the information about the robots location within the maze. This will be done by using the maze stored in program memory, a two dimensional array to store information about direction and intersections, and a subroutine called “enterRoom”.

Methodology

To update the information about the maze as navigating throughout the maze I have developed a subroutine called “enterRoom”. What this subroutine does is calls three additional subroutines: “turnInMaze”, “stepInMaze”, and “roomInMaze”. I developed all of these subroutines using a structure called robot_inst that includes the following information: direction, turn, row, column, room, and bees. Then when calling these subroutines I simply send an instance of this structure to the subroutine and then store the result of enterRoom within that instance.

The subroutine turnInMaze uses the turn and direction values from the robot_inst structure and return a new direction value within robot_inst.

The subroutine stepInMaze uses the direction, row, and column values from robot_inst to return updated row and column values within robot_inst.

The subroutine roomInMaze uses the current row and column values to update the room and bees values within robot_inst.

Software

Main .ino file

////////////////////////////////////////////////////////////////
//  Name     : Update room                                                 
//
//  Author   : Matt Shellhammer                                                        
//
//  Date     : 18 October, 2017                                           
//
//  Version  : 1.0                                                                                      //
////////////////////////////////////////////////////////////////

#define __PROG_TYPES_COMPAT__ // __PROG_TYPES_COMPAT__
#include <avr/pgmspace.h>
#include "maze.h"

void setup() {
  Serial.begin(9600);
  delay(5000); 
}

void loop() {
  // Robot is outside of maze in the bottom left corner
  // Initialization within structure prototype
  static myRobot_t robot_inst;    // create an instance of myRobot_t called robot_inst
  static boolean newRoom = 0;
  static uint8_t room_idx = 0;
  // If we make a turn in the real world then we have to update robot_inst.turn
  // to match the turn exicuted in the real world.
  if (newRoom == 1){
    robot_inst = enterRoom(robot_inst);
    currRow = robot_inst.maze.row;
    currCol = robot_inst.maze.col;
    nextDir[room_idx] = robot_inst.dir;
    room_idx++;
    newRoom = 0;
  }
}

Virtual instructions

myRobot_t enterRoom(myRobot_t current){
  current = turnInMaze(current);
  current = stepInMaze(current);
  current = roomInMaze(current);
}

myRobot_t turnInMaze(myRobot_t current_1){
  // index = 4*turn_val + dir_val
  uint8_t index = (current_1.turn << 2) + current_1.dir;
  current_1.dir = pgm_read_byte_near(turn_table + index);
  return current_1;
}

myRobot_t stepInMaze(myRobot_t current_2){
  // index = 2*current_2.dir
  uint8_t index = (current_2.dir << 1);
  current_2.maze.row += pgm_read_byte_near(map_table + index);      // Add either -1, 0, or 1 to current
// row value.
  current_2.maze.col += pgm_read_byte_near(map_table + index + 1);  // Add either -1, 0, or 1 to current
// column value.
  return current_2;
}

myRobot_t roomInMaze(myRobot_t current_3){
  // index = 21*current_3.maze.row + current_3.maze.col
  uint16_t index = (21*current_3.maze.row) + current_3.maze.col;
  uint8_t maze_val = pgm_read_byte_near(theMaze + index);
  current_3.room = maze_val & 0x0F;                      // clear upper nibble and store as the room value
  uint8_t temp_bees = (maze_val & 0xF0) >> 4;     // clear lower nibble and store as the temp bees value
  current_3.bees += temp_bees;                            // add temp_bees to curret bees value
  return current_3;
}

Header file

// Autonoumous maze arrays
uint8_t currRow;
uint8_t currCol;
uint8_t nextDir[256] = {0};

struct coord_t{
  uint8_t row = 0x13;
  uint8_t col = 0x00;
};

struct myRobot_t{
  uint8_t dir = 0x03;   // Robot is initially facing north
  uint8_t turn = 0x00;  // First action is no turn
  coord_t maze;
  uint8_t room = 0x00;  // Initial room is empty
  uint8_t bees = 0x00;  // No bees present
};

//Compass   S     E     W     N
//dir       00    01    10    11

const uint8_t turn_table[] PROGMEM =
          {0b00, 0b01, 0b10, 0b11, // 00 no turn
           0b10, 0b00, 0b11, 0b01, // 01 turn right
           0b01, 0b11, 0b00, 0b10, // 10 turn left
           0b11, 0b10, 0b01, 0b00  // 11 turn around
           };

//  row   col   dir

const int8_t map_table[] PROGMEM =
    {1  ,  0, // 00
     0  ,  1, // 01
     0  , -1, // 10
    -1  ,  0  // 11
    };

const int maze_length = 399;

const uint8_t theMaze[] PROGMEM =

// 00  01   02   03   04   05   06   07   08   09   0A   0B   0C   0D   0E   0F   10   11   12   13   14
{0x05,0x09,0x09,0x09,0x09,0x09,0x01,0x03,0x05,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x29,0x09,0x09,0x09,0x02,  // 00
 0x0C,0x09,0x09,0x03,0x05,0x09,0x0A,0x06,0x06,0x05,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x03,0x05,0x03,0x06,  // 01
 0x05,0x09,0x0B,0x06,0x06,0x05,0x09,0x0A,0x06,0x0C,0x09,0x09,0x09,0x09,0x09,0x01,0x0B,0x0C,0x0A,0x06,0x06,  // 02
 0x06,0x0D,0x09,0x0A,0x06,0x06,0x05,0x03,0x0C,0x09,0x09,0x03,0x05,0x09,0x09,0x0A,0x05,0x09,0x09,0x08,0x02,  // 03
 0x06,0x05,0x09,0x09,0x0A,0x06,0x06,0x0C,0x09,0x09,0x09,0x0A,0x0C,0x09,0x09,0x03,0x06,0x05,0x09,0x09,0x0A,  // 04
 0x06,0x0C,0x03,0x05,0x09,0x02,0x06,0x05,0x09,0x09,0x09,0x09,0x09,0x09,0x03,0x06,0x06,0x0C,0x03,0x05,0x03,  // 05
 0x06,0x05,0x0A,0x0C,0x03,0x06,0x06,0x06,0x05,0x01,0x03,0x07,0x05,0x03,0x06,0x06,0x06,0x05,0x0A,0x06,0x06,  // 06
 0x06,0x0C,0x09,0x03,0x0E,0x0C,0x04,0x02,0x06,0x06,0x06,0x06,0x06,0x06,0x0C,0x02,0x06,0x0C,0x06,0x02,0x06,  // 07
 0x06,0x05,0x0B,0x0C,0x09,0x09,0x09,0x04,0x02,0x06,0x06,0x06,0x06,0x0C,0x09,0x0A,0x04,0x09,0x0B,0x06,0x06,  // 08
 0x0C,0x08,0x09,0x09,0x09,0x09,0x01,0x01,0x02,0x06,0x0C,0x08,0x08,0x09,0x01,0x09,0x08,0x09,0x03,0x06,0x06,  // 09
 0x05,0x01,0x09,0x09,0x0B,0x07,0x06,0x04,0x02,0x0C,0x09,0x09,0x09,0x03,0x04,0x09,0x03,0x07,0x06,0x06,0x06,  // 0A
 0x06,0x0C,0x09,0x09,0x09,0x02,0x06,0x04,0x02,0x0D,0x09,0x09,0x09,0x0A,0x0C,0x03,0x06,0x06,0x06,0x06,0x06,  // 0B
 0x06,0x05,0x09,0x09,0x09,0x0A,0x06,0x0C,0x0A,0x05,0x09,0x09,0x09,0x09,0x03,0x06,0x06,0x06,0x06,0x06,0x06,  // 0C
 0x06,0x0C,0x09,0x09,0x09,0x03,0x04,0x09,0x09,0x08,0x0B,0x05,0x03,0x05,0x0A,0x06,0x06,0x06,0x06,0x06,0x06,  // 0D
 0x04,0x09,0x09,0x09,0x09,0x08,0x02,0x05,0x01,0x09,0x03,0x06,0x06,0x06,0x05,0x0A,0x0E,0x06,0x06,0x06,0x06,  // 0E
 0x06,0x05,0x09,0x09,0x09,0x09,0x0A,0x0E,0x06,0x07,0x06,0x06,0x06,0x06,0x06,0x05,0x09,0x0A,0x06,0x06,0x06,  // 0F
 0x06,0x0C,0x09,0x09,0x09,0x09,0x09,0x09,0x0A,0x06,0x06,0x06,0x06,0x0E,0x0E,0x06,0x05,0x09,0x0A,0x06,0x06,  // 10
 0x04,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x0A,0x0C,0x0A,0x06,0x05,0x09,0x0A,0x06,0x0D,0x09,0x0A,0x06,  // 11
 0x04,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x09,0x08,0x08,0x09,0x09,0x08,0x09,0x09,0x09,0x0A,  // 12
};

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

To navigate the maze autonomously we will have to store data about the path traveled while in RC mode (direction, row, & column). This data then be used when switching to RC mode to replicate the actions that were taken in RC mode.

Methodology

When navigating the maze in RC mode the robot should store the direction when it detects that it has entered a new room with an intersection and executes a turn. It should store the new direction that the robot is facing after executing the turn. This direction should be stored in a two dimensional array where the intersection number is in one row and the direction traveled for that intersection is stored in the next row. The robot should store the row and column in variables that are constantly being updated to allow for the robot to know where it is at any time. In addition when it completes the maze those variable can be used to verify it truly completed the maze. A subroutine can be executed when the maze was finished and the user exits (or stops) RC mode to store the final row and column value and check that the maze was completed.

Turns should be predefined by each project as a command that executes a right or left turn and then stores the new direction in the two dimensional array. This allows for turns to be executed in a single button push and makes determining when a turn was executed relatively straight forward.

Source Material

Featured Image: https://forums.xilinx.com/t5/Spartan-Family-FPGAs/S6-Multiboot-Golden-Image-Header-Redux/td-p/243836

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

When working with a 3DoT board we need to know the amount of current and power that all peripheral devices will be drawing. This is something that is very important for mission success and if we do not have enough power to complete the mission we will have to come up with alternate solutions to developing a successful power budget.

Methodology

In this motor specific test I will be testing the current draw of the two GM6 motors for the ModWheels car. The way this test was performed was using an Arduino Uno as a power supply for the two GM6 motors as well as a device for recording the voltage drop across a parallel combination of resistors. To measure the current drawn by the two GM6 motors I used the configuration shown in Figure 1 with two GM6 motors in parallel and then four 15 Ω resistors in parallel to create a small resistance (3.75 Ω) to measure the voltage across. To record the voltage across the resistors an analog pin on the Arduino Uno was used to read the voltage and then print that voltage into the Arduino serial monitor. Once the samples were recorded in the serial monitor I then copied those samples into a MATLAB matrix to plot the results. I ran this test for two cases; the first case was with no load (rear wheels removed) shown in Figure 2, and the second case was the full ModWheels load shown in Figure 3. The second case with the full load was performed with the help of another person to assist holding the breadboard while the car is driving straight.

Figure 1. ModWheels motor current draw test setup

Figure 2. ModWheels motor current draw test setup for no load

Figure 3. ModWheels motor current draw test setup for full load

Results

Both tests were ran for thirty seconds recording approximately 6500 samples each. The results were plotted in MATLAB shown in Figures 4 & 5. The average current in case one with no load was 182.43 mA and the average current in case two with full load was 190.74 mA.

Figure 4. ModWheels unloaded current draw MATLAB plot

Figure 5. ModWheels loaded current draw MATLAB plot

Software

To convert the digital input from a quantized value to an analog value the following equation was used:

The reference voltage was 3.3 volts using the AREF external reference voltage pin on the Arduino Uno. The samples were then divided by the parallel resistance to obtain the current drawn by the two GM6 motors and plotted in MATLAB.

Arduino:

////////////////////////////////////////////////////////////////
//  Name     : Motor Test using Arduino Uno                   //
//  Author   : Matt Shellhammer                               //
//  Date     : 28 November, 2017                              //
//  Version  : 1.0                                            //
////////////////////////////////////////////////////////////////

void setup(){
  Serial.begin(9600);
  // Set the PIN Mode
  pinMode(A0, INPUT);
  // Set Analog reference to AREF
  analogReference(EXTERNAL);
  delay(5000);
}

void loop(){
  float V = 3.3*analogRead(A0)/1023;
  Serial.print(V);Serial.print("\t");
}

MATLAB:

%% Motor Test Plots
clear,clc,close all
%%% Resistance: Four 15 Ohms resistors in parallel = 3.75 Ohms (Measured:
%%% 4.7 Ohms)
R = 4.7;
load('motortestdata.mat')
% Unloaded current (recoreded over 30 second interval)
unloaded_I = (unloaded_V./R)*1000; % Result is in mA
AvgUnloaded_I = smooth(unloaded_I, 0.1,'loess')';
avg_unloadedI = mean(unloaded_I);
figure(1)
plot(unloaded_I,'o','MarkerSize',5)
grid on;hold on
plot(AvgUnloaded_I,'r','linewidth',4)
title('ModWheels unloaded current draw')
ylabel('Current (mA)')
xlabel('Sample')
axis([1 6353 0 300])

loaded_I = (loaded_V./R)*1000; % Result is in mA
AvgLoaded_I = smooth(loaded_I, 0.1,'loess')';
avg_loadedI = mean(loaded_I);
figure(2)
plot(loaded_I,'o','MarkerSize',5)
grid on;hold on
plot(AvgLoaded_I,'r','linewidth',4)
title('ModWheels loaded current draw')
ylabel('Current (mA)')
xlabel('Sample')
axis([1 6543 0 300])

References

https://cdn.solarbotics.com/products/photos/a845e1c2e8a762bd5ef059938ba799aa/gm6-front-img_3140.JPG?w=800

By: Natalie Arevalo (Design & Manufacturing Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

The customer requested for there to be specific rules and guidelines for the disassembly and reassembly portion during the day of Mission Launch. In order to compile a comprehensive list of rules and guidelines, a set of questions were sent to the project managers in regards to disassembly and reassembly. With the initial input from the project manager, an initial document was composed outlining the intended rules and guidelines. After a brief review of this document by the project managers, minor adjustment were made to the list. The current list of the rules and guidelines for disassembly and reassembly are listed below.

Guidelines and Rules

Time Allotted

• Disassembly: 10 minutes
• Reassembly: 10 minutes

Rules for Dissassembly

1. All robot will be disassembled by the E&C and Manufacturing engineers – 2 engineers in total.
2. All teams will disconnect all electronics connected to the 3Dot board.
   1. All 3Dot boards will be clear of electronics
3. All teams will disconnect motors
4. Project specific disassembly guidelines:
   1. Sojourner
      1. Disassemble rover body
      2. Disassemble suspension system
      3. Disconnect all sensors
   2. Goliath
      1. Remove panels
      2. Remove tracks
      3. Disconnect all sensors
   3. P-Bot
      1. Disassemble robot body
      2. Disconnect wheels
      3. Disconnect all sensors
   4. ModWheels
      1. Disconnect wheels and front axle
      2. Disassemble chassis
      3. Disconnect all sensors

Rules for Assembly

1. All robots will be reassembled by the E&C and Manufacturing engineers – 2 engineers total.
2. All teams will be allowed to use a cable tree as well as an assembly diagram as necessary.
3. All robots will be tested after reassembly to confirm its functionality.
   1. Test will be conducted using the Arxterra App
      1. Robot should be able to go forwards
      2. Robot should be able to go backwards
      3. Robot should be able to do a right turn

Source Material:

Feature Picture: https://www.assemblymag.com/blogs/14-assembly-blog/post/91291-taking-stuff-apart