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.

Color Sensor Trade Study

/in /by

By: Matt Shellhammer (Electronics & Control Engineer)

Approved By: Lucas Gutierrez (Project Manager)

 

Table of Contents

Introduction

For the Fall 2017 semester of EE 400D, all of the projects at The Robot Company will be using color sensors to navigate a colored 2D-maze, most commonly using TCS34725 1. color sensor.  This color sensor will be mounted onto each of the robots in a particular manner, decided by each project.  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 in reference to the colored 2D-maze.  The sensor should be placed far enough away from the line to avoid only sensing the line all the time; however, it should also be close enough to the line so it will quickly sense the line when the robot veers off the desired route.

Methodology

In this trade study I used two devices, namely 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 (Table 1: Interface Matrix).  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, which is available online on the Adafruit website 2..

 

Table 1: Interface Matrix                       

Arduino Uno pins

 TCS34725 Color sensor pins

Vcc (3.3v)

VIN

GND

GND

SDA (pin18)

SDA
SCL (pin19)

SCL

 

The color sensor was then set up next to a paper with measurement tick marks to measure the distance away from the color sensor (vertical test), and then reconfigured later to measure the distance from either the side of the color sensor (horizontal test), both as shown in the figures below.

 

Figure 1: Color sensor trade study configuration for vertical distance test.

 

Figure 2: Color sensor trade study configuration for horizontal distance test.

 

Next, using strips of vinyl tape (electrical tape) I then tested four different color tape strips. To determine the optimal vertical distance away from color sensor, I tested to see where I got a peak measurement and then called that the optimal distance for that color. The color strips used are shown in the figure below with the results for the vertical test following (Table 2: Optimal vertical distance for color strips).

Figure 3: Color strips used in trade study. From left to right: Black, Red, Green, and Blue.

 

Table 2: Optimal vertical distance for color strips

Color-strip color

 Optimal vertical distance

Black

2 mm

Red

3 mm

Green

2.5 mm
Blue

2 mm

 

After this test was performed, another test was performed to determine the optimal horizontal distance for the color sensor. This optimal distance will be more subjective, since the color should be far enough away from the sensor to not always be detecting the lines, but close enough to reduce the response time of the robot’s reaction to the line. For this test, I measured two distances for each color. One at the point the colored strip was detected as well as at the point at which the amount of detection significantly spiked. The origin (zero) value was set at the middle of the color sensor. I then performed the test, from the left and the right side of the color sensor, as defined in the figure below. The horizontal test results follow (Table 3: Optimal horizontal distance for color strips).

 

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

 

Table 3: Optimal horizontal distance for color strips

Color-strip color Detected horizontal distance (Left) Detected horizontal distance (Right) Detection spike horizontal distance (Left) Detection spike horizontal distance (Right)
Red 9 mm 9 mm 2 mm 2.5 mm
Green 1.5 mm 4 mm 1 mm 1 mm
Blue 4 mm 10 mm 1 mm 2.5 mm
Black 3 mm 3 mm 0 mm 0 mm

 

It can be noted that the range of detection can vary from color to color, and from left to right due to the location of the color detector on the color sensor. In most cases, the range of detection of the color strip was a small but significant distance further from the right than the range when measuring from the left.

 

Conclusion

The first result that can be inferred from this trade study is that a vertical distance from the color sensor to the detected color is optimal within a range of 2 – 3 mm. The second result that can be inferred from this trade study is that a horizontal range of 2.5 – 3 mm away (zero being the center of the color sensor) to the detected color will result in consistent readings, with no significant unintentional readings. However, if trying to ensure no color detection when driving along a path, a horizontal range of 9-10 mm might be better 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.

Source material

  1. https://www.adafruit.com/product/1334
  2. https://github.com/adafruit/Adafruit_TCS34725

Goliath Fall 2017 – Initial Design

/in , /by

After inspecting last year’s final product, I began to redesign the dimensions of the overall body of the tank. While reviewing their SolidWorks’ files, I calculated a maximum possible decrease in width of 8.95 mm. The following changes were made in order to minimize the overall width of the tank and other changes were to […]

Read more

Goliath Fall 2017 – Component Testing

/in , /by

This project will be including 4 new peripherals and parts for this iteration of the Goliath. To fulfil the following requirements: Operation Task – Autonomous, L1(13) Operation Task – Recall, L1(14) These parts will be added eventually to the PCB design on the Goliath. The tested components so far are as follows: Color Sensors, LED Matrix, […]

Read more

Fall 2017 – 3DoT Chassis Preliminary Design Document & Preliminary Project Plan

/in /by

By: Elizabeth Nguyen (Project Manager), Melwin Pakpahan (Missions, Systems, and Test Engineer), Yasin Khalil (Electronics & Control Engineer), Zachary de Bruyn (Electronics & Control Engineer), Railan Oviedo (Design & Manufacturing Engineering)

Table of Contents

Preliminary Design Document

Program Objective & Mission Profile

Written by Elizabeth Nguyen

Program Objective

The 3DoT Chassis (the name is expected to be changed) is expected to be 3D-printed as a single assembly, based on the Paperbot. It will be a toy robot with a paper shell that will resemble the mascot of CalState Long Beach (CSULB) Prospector Pete. The robot will be controlled through the arxobot app/control panel. The DC motors (GM6) and the planetary gear system will remain the same as used for Paperbot.

Mission Profile

The 3DoT Chassis will be able to (1) remotely navigate a maze while recording its path (that is determined on the day of demonstration) with its sensor shield and (2) autonomously navigate the same recorded maze path while other autonomous toy robots are present.

Source: Project and Mission Objectives

 

Requirements

Level One Requirements

Written by Elizabeth Nguyen

Program Requirements
  1. The 3DoT Chassis shall be completed by Wednesday, December 13, 2017.
    1. This requirement coincides with the last day of class and this is the projected demonstration date for all toy robots.
  2. The 3DoT Chassis shall cost no more than $200 as projected by the customer.
  3. The 3DoT Chassis will be a toy robot.
    1. This requirement is defined through the customer expectations.
Project Requirements
  1. The 3DoT Chassis shall use a 3DoT Board (based on Project and Mission Objectives).
  2. The 3DoT Chassis shall navigate through a maze with remote control through the ArxRobot App or the Arxterra Control Panel (based on Project and Mission Objectives).
  3. The 3DoT Chassis shall be no larger than 4 x 3.5 x 3 inches.
    1. These measurements were taken at the widest dimensions of the chassis since it tapers at the bottom.
  4. The 3DoT Chassis shall be able to memorize a path through the maze that is taught by the user (based on Project and Mission Objectives).
  5. The 3DoT Chassis shall be able to autonomously travel down the path that was memorized (based on Project and Mission Objectives).
  6. The 3DoT Chassis should be able to navigate the maze and avoid collisions when multiple robots are in the maze.
    1. This requirement is not completely defined because the project managers need to determine a way for the robots to avoid each other during their demos.
  7. The 3DoT Chassis shall have a chassis that is 3D printed.
    1. This is derived from a customer expectation.
  8. The total 3D print time of 3DoT Chassis’ parts shall not exceed 6 hours (based on Project and Mission Objectives).
  9. The main body of the body shall be of one solid piece.
  10. The 3DoT Chassis shall be easy to assemble.
  11. The 3DoT Chassis Paper Shell shall resemble the CSULB mascot, Prospector Pete.
    1. This is a customer expectation.

Level Two Requirements

Written by Melwin Pakpahan

System Requirements
  1. The 3DoT Chassis shall operate for no less than 20 minutes.
  2. The 3DoT Chassis shall have a maximum speed of 19.5 centimeters per second.
  3. The 3DoT Chassis shall have a custom PCB to accommodate for its sensors.
Subsystem Requirements
  1. The 3DoT Chassis shall be powered by a RCR123A Lithium Polymer battery.
  2. The 3DoT Chassis shall use a planetary gear system for mobility.
  3. The 3DoT Chassis shall have a sensor shield on the front.
  4. The 3DoT Chassis shall have a mechanism for counterweight attached to the shield.
  5. The 3DoT Chassis shall utilize two GM6 brushed DC motors.
  6. The 3DoT Chassis shall use a TCS34725 RGB color sensor to navigate the maze.
  7. The 3DoT Chassis shall use a TCS34725 RGB color sensor to detect and avoid other robots in the maze.

Design Innovation

Written by Elizabeth Nguyen

Caster Wheel

During the creativity exercise, our team determined that the caster wheel required a more innovative solution. There was a need to compensate for the uneven weight distribution caused by the smartphone resting in the front. Previous designs have used a simple castor wheel.

Based on the solutions developed from the suggested techniques (Duncker diagrams, different point of views, forced relationships, etc.), we decided not to implement them. Some were not feasible and there were other tasks that required more attention such as the custom PCB for the SAMB11 and the planetary gear system, which will be addressed.

Gear System

In continuation to the mentioned task that is considered urgent, the implementation planetary gear system is a customer expectation and a potential challenge for the team. It is aesthetically pleasing, which is why the gear system must specifically be planetary; however, this design did not work with a wooden chassis due to friction.

What has changed was allowing COTS gears since they cannot be 3D-printed concisely nor have a strong structure to work. Instead, the focus for the team is to determine an innovative design for the gear system while appearing planetary.

The challenge also discovered was for a true planetary gear system, torque comes from the middle gear, which then rotates the smaller planetary gears, allowing the wheel to turn. However, with the current chassis design, torque comes from the top gear, which will turn the rest of the gears.

Gear studies will be performed.

Custom PCB to replace 3DoT Board

A challenge provided for the team is to design and assemble a custom PCB that will replace the 3DoT Board that is used to power and control the robot. The ATMega32U4 will be replaced with the SAMB11 and there will be an implementation of the IFA on the SAMB11 Board as discussed below.

ATMega32U4 replaced with SAMB11

The current 3DoT Board v454 has components that are incorporated separately on the PCB as opposed to the SAMB11 where those components are built-in [1]. Benefits from replacing the chip would include less power for the SAMB11 because less components would be required ont he PCB and would not require the HM10 to be implemented onto the board because bluetooth is also integrated.

Implementation of IFA on SAMB11 board

Because of the replacement of the ATMetga32U4 with the SAMB11, an antenna is required for communication purposes between the users (our team) and the board itself. An Inverted-F Antenna was chosen and will communicate with the board using 2.4 GHz.

References:

[1] Design Guide of SAMB11

 

Systems/Subsystem Design

Product Breakdown Structure

Created by Melwin Pakpahan

 

Electronic System Design

System Block Diagrams

Created by Zachary de Bruyn

System Block Diagram for 3DoT Board

 

System Block Diagram for SAMB11 Board

 

Interface Definitions

3DoT Interface Definition

SAMB11 Interface Definition

Mechanical Design

Written by Railan Oviedo

For this version of the 3DoT Chassis, the customer’s biggest requirement is to have it 3D-printed as a singular piece. This varies from the previous iterations, as they had each required an assembly of the chassis first. In order to realize this, I will have to adjust the previously made 3D modeled parts and combine them in such a way that the entire chassis can printed at once.

To avoid long print times—and thus a higher chance of an error while printing—the chassis’ front and back will have to be perforated so as to avoid printing unnecessary space. To comply with the boundaries made by the Prospector Pete paper structure, the Chassis size will not exceed measurements of 4 x 3.5 x 3 inches. Furthermore, the primary method of movement will be realized through the use of a planetary gear system. The inner workings of the Chassis will remain relatively the same from the previous plastic design. That is, there will be grooves to hold in the 2 DC motors and the 3DoT board, which will have a battery and circuitry for the robot placed onto it. The final aspect of the 3DoT Chassis will involve a shield placed in the front in order to allow for placement of sensors and navigation along with a castor wheel for counter-balance purposes. This shield will also serve as a stand for a phone that can be placed on the chassis.

The following images show what the general shape of the chassis looks like from a diagonal view, side view, and front view:

3DoT Chassis Diagonal View

3DoT Chassis Side View

 

3DoT Chassis Front View

 

Design and Unique Task Descriptions

Manufacturing

3D Printed Chassis

Written by Railan Oviedo

As previously stated, a singular design of the chassis can be modeled through referencing the previous models made by prior teams that worked on the 3DoT. The major goal for the completed 3D chassis design is to be able to be printed in less than 6 hours, so as to ensure that the printed chassis will not experience structural failures.

Because this version cannot be disassembled, the issue of placing the motors in comes into play. To circumvent this problem, I am planning on creating rectangular holes on the front and back of the chassis in order to easily insert the motors onto their slots. This solution would not only resolve the motor placement issue, but also reduce the necessary printing time for the chassis.    

In regards to the planetary gear system, it is imperative to make sure the gears can fit within the primary wheel’s 5.5 cm diameter. The current plan is to create a triangular gear train with 3 large gears that are each attached to a smaller gear that serves as the center focal point. This setup should result in little to no loss of rpm between the large gears, as they are the ones that will be connected to the primary wheel.

An expected completion date for a 3D model design is October 25, 2017.

 

Electronics & Control

Inverted-F Antenna

Written by Zachary de Bruyn

The 3DoT Chassis team will be implementing two varieties of “3DoT” boards. One board will consist of the heritage 3DoT ver. 4-54 board which utilizes the ATMega32U4. In order for the heritage 3DoT to communicate with peripheral devices, an additional component, the HM10, is needed to provide a 2.4GHz link between a transmitter (XMT) and the HM10. The second board, however, utilizes a SAMB11 SoC. Within the SAMB11 is the BLE device necessary to communicate at 2.4GHz, but requires the design and implementation of an antenna external to the SAMB11.

Implementation of an antenna design is dependent on the frequency at which it is to receive. Therefore, in order to implement a PCB antenna which utilizes the 2.4GHz, which bluetooth is dependent on, we are limited to only a couple of antenna varieties [1]. In short, the Inverted-F Antenna (IFA) was chosen for a couple of reasons: 1) It is similar to the design of the antenna on the HM10, which is a proven concept; 2) the IFA is isotropic allowing for reception from a wide range of three-dimensional locations, and 3) it allows for 2.4GHz reception. The expected completion date is November 1, 2017.

References:

[1] http://www.ti.com/lit/an/swra161b/swra161b.pdf

[2] http://www.ti.com/lit/an/swru120c/swru120c.pdf

 

Color Sensors (TCS34725)

Written by Zachary de Bruyn

It is the goal of the 3DoT team to implement the Light-to-Digital Converted (RGB Sensor) in order to read the different colors that are imposed on the maze/roadway in order to navigate the maze autonomously. The benefit of using the color sensor is that it will allow the toy robot to use the color values it evaluates to maintain the direction on the maze. We can then implement a controlled response that will allow the toy robot to correct its direction based on interference from other undesirable colors. There is an expected completion date of November 15, 2017.

References:

[1] https://cdn-shop.adafruit.com/datasheets/TCS34725.pdf

 

SAMB11

Written by Yasin Khalil

The SAMB11 will be implemented in custom PCB to replace the heritage 3DoT ver. 454 board that utilizes an ATMega32U4.

The SAMB11 will provide all of the base features as the ATMega32U4 in the original 3DoT board. These features include a dual H-Bridge, sensors, power management (battery, usb, etc.), servo’s, and DC motors. There will also be correlating headers to that of the 3DoT to allow for seamless integration with past projects.

An expected completion date will be November 15th, 2017.

SAMB11 Reference Design Schematic

Preliminary Project Plan

Work Breakdown Structure

Created by Elizabeth Nguyen

Project Schedule

Created by Elizabeth Nguyen

Top Level Schedule

System/Subsystem Level Tasks

Project Burndown

The current graph shows a burndown from a top level view; however, it is difficult to ascertain the ideal burndown. It will be updated with the correct dates as well.

System Resource Reports

Created by Melwin Pakpahan

Project Cost Estimates

Written by Elizabeth Nguyen

A budget of $200.00 was projected by the customer. It is difficult to ascertain an estimated budget due to variances in services such as 3D printing and PCB board assembly. However, at least 50% of the budget is estimated to go towards physical parts and the rest of the budget will be allocated towards services.

Goliath Fall 2017 – Preliminary Project Plan

/in , /by

This is the Work Breakdown Structure (WBS) for this project. The diagram breaks the tasks among each of the three engineering areas. Then further lists specific tasks for each part of the project. In this way, the document shows clearly what each person’s responsibilities are. These assignments were based on the system block diagram created by the Mission […]

Read more