Goliath Fall 2017 – Recommended Custom Telemetry & Custom Commands

/in , /by

The purpose of this document is to define telemetry visuals and custom commands required in Arxterra to control the Goliath during the mission. These definitions will be used in the software design on both the application side and the internal operating code of the Goliath. These commands may be subject to change if some are not possible […]

Read more

Mission Definition

/in /by

Written by Elizabeth Nguyen (Project Manager)

Table of Contents

Objective:

The total time for each phase of the mission set is determined in order to ensure there is enough time allocated for the entire mission set to be completed in 120 min.

This document entails the breakdown of the mission set and how much time is split for each phase based on the maximum speed of each robot as provided in Mission Duration at Maximum Speed.

Phases:

  • Phase 1 – Record
  • Phase 2a – Individual Playback
  • Phase 2b – 4 Robots, 1 Maze
  • Phase 2c – Individual Playback (Pre-defined)*

* Phase 2c is optional and based on the success of Phase 2a

Robot Order: (from fastest to slowest)*

  • Pete-Bot** – 6 min.
  • ModWheels** – 7 min.
  • Sojourner** – 14 min.
  • Goliath – 18 min.

* All times have been rounded up
** Assumes no load

Speeds & Path Durations used:

Path durations were calculated and documented by Railan Oviedo. There are two documents where one addresses the path duration at maximum speed and another at minimum speed.

The bolded texts indicate which numbers I used to determine allocated time.

Types of Path Scenarios:

  • Shortest Path Scenario
  • Average Path Scenario

Speeds:

  • Half Speed – Min Speed
  • Half Speed – Max Speed
  • One-Third Speed – Min Speed
  • One-Third Speed – Max Speed

One-third speed was chosen (and suggested by Mark Huffman) to account for potential decrease in time due to added weight (since all but one robot have provided speeds under no load conditions). Although half-speed would be better to use for worst-case scenarios, it may not be as reasonable either. Also, average path durations were chosen to determine total time allocations at worst.

Breakdown of Mission Set:

  1. Phase 1 – Record
    1. Average Path Scenario at One-Third Speed (Max Speed)
      1. Total Time: 54 min.
        1. Path completion: 45 min.
        2. Rotation: 3 min. x 3 rotations = 9 min.
    2. Concluded Total Time: 60 min.
      1. Rounded up in the case that rotations are not 3 min. each or that some robots end up not performing up to speed due to added weight.
  2. Phase 2a – Individual Playback
    1. Concluded Total Time: 60 min.
      1. Considering that this phase is to test if the robot has properly recorded the maze, it can be assumed that the amount of time it takes to individually playback each robot is the same as Phase 1.
      2. Assuming that there is only one maze available, this means that the amount of time to complete the mission set has been allocated to both Phase 1 and Phase 2a.
    2. Alternative: (has been approved by Hill)
      1. If two mazes are available, then Phase 1 and Phase 2a can occur simultaneously.
      2. Once one robot completes Phase 1, it may proceed to Phase 2a on the second maze.
      3. This would allow Phase 1 || Phase 2a to be completed in 60 min.
  3. Phase 2b – 4 Robots, 1 Maze
    1. Concluded Total Time: 20 min.
      1. Total time is based on the time it takes for the slowest robot (Goliath) to playback its recorded path. At worst, that is 18 minutes; however, including factors such as robots potentially detecting each other and having to avoid each other, 2 minutes has been added in.
        1. Note: At this time, it is unknown how long it will take a robot to execute the Robot Avoidance Code and recover from its detour.
        2. If it takes even longer for a robot to avoid another, maybe a rule should be made where if a robot takes three attempts to correct itself and fails, then it fails Phase 2b and should be removed from the maze.
  4. Phase 2c – Individual Playback with Pre-Defined Maze
    1. This Phase only occurs if a robot fails to complete Phase 2a.
    2. Best Case: 0 min.
      1. All four robots must complete Phase 2a successfully.
    3. Worst Case: 60 min.
      1. All four robots fail to complete Phase 2a.
    4. Duration based on the number of robots at best and at worst in minutes:
      [Mission Set Table]
    5. Disassembly & Reassembly
      1. Total Time: 20 min.
        1. Based on Natalie Arevalo’s conclusion
          1. Disassembly: 10 min.
          2. Reassembly: 10 min.

Scenarios:

  1. Best Case Scenario – 100 min.
    1. Reasoning:
      1. Phase 2c is not required
      2. Phase 1 || Phase 2a (two mazes are required)
    2. Breakdown:
      1. Phase 1 || Phase 2a – 60 min.
      2. Phase 2b – 20 min.
      3. Phase 2c – 0 min. (if all robots succeed in Phase 2a or if Phase 2c is not included)
    3. Disassembly & Reassembly – 20 min.
    4. This scenario has been selected for the demonstration date on December 13, 2017.
  2. Worst Case Scenario – 160 min.
    1. Reasoning:
      1. Phase 2c is not required
      2. Phase 1 and Phase 2a occur separately
    2. Breakdown:
      1. Phase 1 – 60 min.
      2. Phase 2a – 60 min.
      3. Phase 2b – 20 min.
      4. Phase 2c – 0 min.
    3. Disassembly & Reassembly – 20 min.
  3. Absolute Worst Case Scenario – 220 min.
    1. Reasoning:
      1. Phase 2c occurs with all four robots
      2. Phase 1 and Phase 2a occur separately
    2. Breakdown:
      1. Phase 1 – 60 min.
      2. Phase 2a – 60 min.
      3. Phase 2b – 20 min.
      4. Phase 2c – 60 min.
  4. Disassembly & Reassembly – 20 min.

Mission Duration at Maximum Speed

/in /by

Descriptions, Calculations, and Images by Railan Oviedo (Manufacturing)

Description:

In order to calculate the mission duration, multiple paths were created and averaged in order to have a rough estimate on the time length. These paths were made intentionally long in distance so as to simulate worst-case scenario situations. Based on the given speeds of the robot*, the longest time to complete the average calculated path is 17.69 minutes (Goliath). Further calculations were made for the shortest possible path, and differences in time based on the average speed used by the robot (Either Half-Speed or One-Third Speed).

*P-Bot and ModWheels speeds were calculated assuming the motors are running are 5 V

Updated on 11/17/2017.

Methods of Calculation

First, the shortest path possible will be calculated in order to determine the best case scenario mission duration. Then, 6 long maze paths—which will start and end at the entrance and exit of the maze—will be created (4 of which will be off-shoots of the first 2) and their distance will be averaged in order to simulate any given run through the maze.

To calculate the time that a particular robot will take to navigate the averaged path, their provided speed will be reduced by a third—and another scenario with the speed reduced by a half—due to the fact that it will likely move slowly to maintain contact with the colored line. Furthermore, for every turn, an extra 2 seconds will be added to account for the action; and for every U-turn, an extra 6 seconds will be added to account for the action.

Robot Speeds:

All robot speeds besides Goliath are at no-load based off of calculations from the wheel diameter and the RPM of the robot’s given motor.

Table (1) – Robot Speeds

* These speeds assume a constant 5V supply to the motors, thus resulting in an RPm of 64

** Goliath’s speed is provided under their estimated weight conditions

Maze Calculations

Reference for Maze Dimensions by Zachary de Bruyn

Image of Maze with Dimensions

One strip of brown is approximately 6.61 cm (132.1 cm/20 cm).*

*U-Turns will not be counted as a strip traveled and are only factored into the aformentioned 6 sec./U-Turn condition.

Shortest Possible Path

  • Total Number of Turns: 12
    • Time to be added: 12 * 2 sec. = 24 sec.
  • Total brown strips covered: 52
    • Linear distance: 52 * 6.61 cm = 343.72 cm = 3.4372 m.

Longest Path Option 1a

  • Total Number of Turns: 62
    • Time to be Added: 62 * 2 sec. = 124 sec.
  • Total brown strips covered: 170
    • Linear Distance: 170 * 6.61 cm = 1,123.7 cm = 11.24 m.

Longest Path Option 1b

  • Total Number of Non U-Turns: 62 + 8 + 8 = 78; Total Number of U-Turns: 3
    • Time to be Added due to Non U-Turns: 78 * 2 sec. = 156 sec.
    • Time to be Added due to U-Turns: 3 * 6 sec. = 18 sec.
  • Total brown strips covered: 170 + 28 + 10 + 6 = 214
    • Linear Distance: 214 * 6.61 cm. = 1,414.54 cm = 14.15 m.

Longest Path Option 1c

  • Total Number of Non U-Turns: 62 + 14 + 8 + 12 = 96; Total Number of U-Turns: 5
    • Time to be Added due to Non U-Turns: 96 * 2 sec. = 192 sec.
    • Time to be Added due to U-Turns: 5 * 6 sec. = 30 sec.
  • Total brown strips covered: 170 + 26 + 30 + 30 = 256
    • Linear Distance: 256 * 6.61 cm. = 1,692.16 cm. = 16.92 m.

Longest Path Option 2a

  • Total Number of Turns: 80
    • Time to be Added: 80 * 2 sec. = 160 sec.
  • Total brown strips covered: 208
    • Linear Distance: 208 * 6.61 cm. = 1,374.88 cm. = 13.75 m.

Longest Path Option 2b

  • Total Number of Non U-Turns: 80 + 2 + 10 + 8 = 100; Total Number of U-Turns: 3
    • Time to be Added due to Non U-Turns: 100 * 2 sec. = 200 sec.
    • Time to be Added due to U-Turns: 3 * 6 sec. = 18 sec.
  • Total brown strips covered: 208 + 24 + 24 + 26 = 282
    • Linear Distance: 282 * 6.61 cm. = 1,864.02 cm. = 18.64 m.

Long Path Option 2c

  • Total Number of Non U-Turns: 80 + 8 + 6 + 4 = 98; Total Number of U-Turns: 3
    • Time to be Added due to Non U-Turns: 98 * 2 sec. = 186 sec.
    • Time to be Added due to U-Turns: 3 * 6 sec. = 18 sec.
  • Total brown strips covered: 208 + 28 + 40 + 22 = 298
    • Linear Distance: 298 * 6.61 cm. = 1,969.78 cm. = 19.70 m.

Results:

After calculating all the numerical values, the following tables have been compiled.

Table (2) – Total Linear Distance, Added Time, and Average Values

Table (3) – Shortest Mission Duration at Half-Speed (Shortest Path Scenario)

Table (4) – Shortest Mission Duration at One-Third Speed (Shortest Path Scenario)

Table (5) – Average Mission Duration at One-Third Speed (Average Path Scenario)

Final Notes

These estimations do not factor into account the time it would take to navigate a path that starts at a random point in the maze. However, since the created paths are incredibly large—in order to simulate a worst-case scenario—it is safe to assume that, in practice, the total time taken to navigate any given path will be less than the calculated values. This also assumes that the processes of turning or U-turning do not require considerably more amount of time to execute than originally assumed.

Maze Dimensions

/in /by

Written by Elizabeth Nguyen (Project Manager)

Measurements taken by Zachary de Bruyn (Electronics & Control)

Dimensions:

  • Total width: 132.1 cm.
  • Total length: 144.2 cm.
  • Brown line to wall (green line) varies from 1.7 cm to 2.9 cm.
  • Distance between walls varies:
    • 4.5 cm to 5.4 cm @ the U-bends
    • 4.5 cm to 5.2 cm @ hallways
  • Thickness of horizontal brown lines is 1 cm.
  • Thickness of vertical brown lines is 1.2 cm.

Scan of Maze with Dimensions

Disassembly and Reassembly Guidelines and Rules

/in /by

By: Natalie Arevalo (Design & Manufacturing Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Table of Contents

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

Fall 2017: ModWheels 3D Model

/in /by

By: Natalie Arevalo (Design & Manufacturing Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Table of Contents

Introduction

As part of the ModWheels team, I was asked to make various modifications to the existing model of the KidStuff’s car. Additionally, a new part was designed and integrated into the modified model. More parts will be designed in the future as holders for additional components. However, the following blog post expands on the modifications mentioned above as well as the newly designed part. The blog post ends with the full assembly of the ModWheels model.  

Model Designs

Top and Bottom Panels

Both the top and bottom parts of the chassis were altered to accommodate 3DoT 5.03. The main changes involved moving the opening for the battery holder as well as the access points for the pin headers on the top part of the chassis. For the bottom of the chassis, the accesses points for the bluetooth module and the color shield were also moved. Additionally, holes were made in which dawls would be placed to put a platform on top of them to hold a phone. Lastly, holes were made on the top and bottom of the chassis to place zip ties which will hold wires out of the way of any moving parts. All of these changes can be seen below.

Figure 1: Bottom Panel

Figure 2: Top Panel

Front Axle

The front axle is composed of three major components: a front pivot axle, a connector from the front pivot axle to the wheel axle, and the wheel axle. Two different versions of the front pivot axle were initially rendered by the Design & Manufacturing Engineer for P-Bot, Railan. One of these two models was used for the front pivot axle after making the part thinner. After this modification was completed, the connector and wheel axle were modeled in SolidWorks from the given .stl file. All of these parts can be seen in the following figures.

Figure 3: Front Pivot Axle

Figure 4: Front Pivot Axle to Wheel Axle Connector

Figure 5: Wheel Axle

 

Servo Holder

Some additional modifications were made to the servo holder as well. The height of the holder was decreased and the motor heads on it were also made hollow. Hooks on one side of the holder were also added to place the wires of the proximity sensor in the front away from any moving parts. The modifications for this part of the design can be seen here:

Figure 6: Servo Holder

 

Wheels

A minor change was made to the back wheels of the car. The hole where they are inserted into the GM6 motors were changed into D shaped to be able to be fit into the motor shaft.  The changes can be seen in the following picture.

Tire treads were designed, modeled, and provided by Jeff Gomes.  

Figure 7: Wheel

Figure 8: Wheel Tread (Designed, modeled, and provided by Jeff Gomes)

Full 3D Model

With all the changes and additions mentioned before, a new full 3-D model of our robot was assembled. The full model also includes the IR shield which was missing before. The 3-D model of the ModWheels car can seen be here.

Figure 9: Full 3D Model

 

2D to 3D Mechanical Design

/in /by

By: Vanessa Enriquez (Design & Manufacturing Engineer for Goliath)

Approved by: Lucas Gutierrez (Project Manager for ModWheels)

Table of Contents

Introduction

After PDR, I was temporarily reassigned to the ModWheels project to begin recreating the existing 2D design onto a 3D design in Solidworks.

 

Preliminary design

To begin with, the current design was provided to me by the project manager, Lucas. Figure 1 includes the instructions and features that will be present in the first design of the 3D model. The 2D .dxf file was converted into solidworks and was separated into four parts.  

Figure 1 – 2D design includes top and bottom panels, wheel, and latch.    

2D to 3D

The cut out instructions mentioned in figure 1 were implemented in sSolidworks. All parts were extruded to 3.429 millimeters.

Figure 2 – Solidworks assembly for current design includes top and bottom panels, wheel, and latch.   

Conclusion

The files and designs were then sent over to the new Design & Manufacturing Engineer for ModWheels, Natalie, to look over and finalize before laser cutting. Natalie will be in charge of any future design changes and assembly of the model.

Goliath Fall 2017 – Color Sensor Line Following

/in , /by

The theory behind line following with color sensors is the same reasoning used when using IR sensors. A sensor is placed on each side of the centerline and both sensors are constantly read back to adjust heading direction as based on which sensor is detecting. Both Sensors White: On-the-line, continue forward straight line. Right Sensor Black: Off-the-line, veer to […]

Read more

Rules Of The Maze (Robot Avoidance Rules and Strategy)

/in /by

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Table of Contents

Introduction

When traveling through the maze, robots have the possibility to encounter other robots. To ensure the robots will be able to successfully navigate the maze and complete the mission objectives, we need to have general rules of the maze. These rules should be followed by all projects to guarantee that all robots are following the same rules for navigating the maze.

Possible encounter cases:

2.1.  Face-to-Face in hallway (North/South & East/West)

2.2.  Face-to-Back in hallway (North/South & East/West)

2.3.  T – Intersection

 

Rules for robots that occupy more than one room

Some projects have robots that are larger than one room size which if not addressed can cause issues with the rules of the maze. For projects that will take up more than one room size, the excess robot space should be in the previous room. This is to ensure that robots will not be seen as within the intersection when they have not yet stepped into the intersection. This will mean that robots that take up more than one room will be occupying their current room and part of the previous room, which should not cause any problems for the rules of the maze. If the robot has just stepped through the intersection and is partially within the intersection, it will be cleared once they step into the next room.

Rules for detection

To detect robots within intersections and in face-to-face or face-to-back encounters, detection should be continuous since robots will not be moving in synchronization and a robot can step into a new room at any time. Robots should be able to detect a robot in the next room ahead since all decisions will be made within a one room range.

Rules for encounters 2.1 (Face-to-Face) & 2.2 (Face-to-Back)

For encounters 2.1 & 2.2 the rules will be defined as follows:

A robot that is in a hallway (vertical/horizontal) that encounters another robot, either face-to-face (case 2.1) or face-to-back (case 2.2) will immediately pause movement for three seconds. If this robot still detects the other robot after these three seconds, the robots must be in case 2.1. If the robot no longer detects the other robot after these three seconds, the robot then must be in case 2.2.

If the robots are in case 2.1 and they are in a vertical hallway (north/south) the robot facing north has the highest priority. If the robots are in case 2.1 and they are in a horizontal hallway (east/west) the robot facing east has the highest priority. In case 2.1 robots facing either south or west have the lowest priority and are therefore left with the burden of clearing the path. The robot with lower priority should turn around and retrace its path until the robot with highest priority is able to pass. When the robot is retracing its path it should retrace its path until its last decision point (last intersection) and wait for the robot to pass. If the higher priority robot tries to go down the hallway that the lower priority robot is waiting in, the robots are now in either case 2.3 or 2.4. In this case the robot within the intersection is now at lower priority and follows the rules explained in Section 4.

If the robots are in case 2.2 they will then continue on with the desired path.

Rules for encounters 2.3 (T – Intersection)

For encounter 2.3 the rules will be defined as follows:

When a robot comes to an intersection it will attempt to step into the intersection and either turn or move straight along its path. If a robot steps into an intersection and sees another robot as it tries to make its maneuver, then these robots will be in case 2.3. In this case the robot that is within the intersection (in the middle of the T – intersection) has the lowest priority and must move out of the way of the other robots (if the other robots are in the path of the low priority robot). The lowest priority robot will step down the hallway that is not blocked and then wait for the other robot to pass. The robot may try to step down the hallway that the waiting robot is in and this will mean that this robot is now at lower priority and has to move for the previously waiting robot. A robot waiting at an intersection for another robot to pass should timeout after waiting ten seconds for a robot to pass. After timing out the robot should then make a second attempt to continue along its path. This timeout is used for when a robot in an intersection detects another robot in its path, as long as the detected robot was not traveling through the intersection (e.g. waiting to enter another intersection).

 

Recovery strategy

If a lower priority robot is required to clear the path of a higher priority robot then there must be a recovery strategy for that lower priority robot. The recovery strategy for case 2.1 should have the robot only travel forwards and backwards along its designated path to allow for the robot to easily repeat the steps taken clear the path. This then allows the robot to either step forward or backward along the recorded path, and requires no modification to the robot’s path. And for cases 2.3 and 2.4, the robots should only move off the designated path to move out of the way for other robots when required, and then continue back on the designated path.

 

Special Cases to consider

Three robots at T – Intersection (special case of 2.3)

Rules for three robots within a T – Intersection

If a robot is thought to be in case 2.3, then attempts to move down the other hallway, and then again encounters another robot, then there must be three robots within this intersection. I don’t know we should deal with this case… What if another robot comes up behind this robot, it is now boxed in… Additionally, the other robots do not know that there is three robots (four if you include the additional robot) at the intersection.

Other things to consider

Detection of robots multiple rooms away, so when there’s an intersection with three robots, there is an open space for the robot within the intersection to move into to allow the other robot to move by.