Spring 2018 3DoT Hexy: Decision on Motor Type Selection

/in , /by

By: Kris Osuna (Electronics and Control Engineer)

Verified by: Eduardo De La Cruz (Project Manager and Manufacturing Engineer)

Approved by: Miguel Garcia (Quality Assurance)

Introduction

The purpose of this blog post is to introduce the different types of motors that are at our disposal. We will compare and contrast each type of motor, and conclude the post with a final decision on which type of motors are best suited for our Spiderbot design.

Brushed DC Motor  

Is used commercially in toys and also in industrial use. Inside are brushes that rub on a copper ring so that current goes through the coils as the motor spins while surrounded by positive and negative magnets.

Pros: Inexpensive and lightweight.

Cons: Very electrically noisy, needs extra circuits and connections for controlling, an difficult programming for small movements.

Figure 1: Brushed DC Motor

 

Brushless DC Motor

These motors are close to the brush motors except that they don’t make as much noise as them. These are use in fans, drones or multicopters.

Pros: Quiet

Cons: Needs extra connection and circuit to control the motor.

Figure 2: Brushless DC Motor 

 

Stepper Motors

Is a motor that moves in steps unlike the brushed and unbrushed DC motors. Since it moves in steps it has precision control. It is used in 3D printers, robotics and printers.

Pros: Precise repeatable positions, speed control, great low-speed torque and great ‘holding torque.’

Cons: Low efficiency, needs encoder for reference and needs extra circuit board to use on Arduino.

Figure 3: Stepper Motor

 

Servo Motors 

Is a motor that uses negative feedback to control motor speed or position. They use very precise motion control. These are the most commonly used in electronics. Used for robotics, animatronics and electronic cars, boats or planes.

Pros: Low cost, variety and simple to control.

Cons: Limited range of motion goes from 0-180 degrees can become jittery if trying to hold a position.

Figure 4: Servo Motors 

 

Continuous Rotation Servos

Are similar to the normal servo motors except that it has more mobility it can go 360 degrees and go in reverse. It contains a built in H bridge so no extra circuits were needed. Used in robot drive trains.

Pros: Inexpensive, small and easy to control

Cons: Not designed for large loads.

Figure 5: Continuous Rotation Servo Motor

 

Final Decision

Micro-motors

Figure 6: Micro-motors 

We decided to use a micro brushed motor  for our design. This is due to 3DoT David using the same type of motor. Their motor trade off study shows we will use the 3.7V 50,000 RPM Small Colorless Motor 716. These motors are extremely cheap at $1.95 each compared to $10-20 for servo motors.

Resources

  1. https://learn.adafruit.com/adafruit-motor-selection-guide/dc-motors
  2. https://learn.adafruit.com/adafruit-motor-selection-guide/brushless-dc-motors
  3. https://learn.adafruit.com/adafruit-motor-selection-guide/rc-servos
  4. https://learn.adafruit.com/adafruit-motor-selection-guide/continuous-rotation-servos
  5. https://www.seeedstudio.com/37V-50000RPM-Small-Coreless-Motor-716-p-1884.html
  6. 3DoT David Motor Trade off
  7. https://learn.adafruit.com/adafruit-motor-selection-guide/stepper-motors

Spring 2018 3DoT Hexy: Work Breakdown Structure

/in , /by

By: Eduardo De La Cruz (Project Manager and Manufacturing Engineer)

Approved by: Miguel Garcia (Quality Assurance)

Introduction

Below is the Work Breakdown Structure (WBS) for our project. The diagram is broken down into task each division engineer will be responsible for in the production of the final product. These assignments are based of the task matrix we developed as a class. Engineers can use this diagram as a reference for what they need to do. For a more detailed explanation of what each task consists of, consult the task matrix.

Figure 1: Work Breakdown Structure

 

Eduardo De La Cruz – Project Manager and Manufacturing Engineer 

Due to having only three members per group, the Manufacturing Engineers of each group was assigned the task of project manager. Therefore Eduardo will be responsible for completing all the manufacturing and managerial task to ensure mission success.

The task shown above are broken down into top level task. All task that fall under each top level task will be the task each engineer will be accountable for. Top level task are organized in the order of priority. Therefore,

Top level task:

As Project Manager Eduardo will have to:

  • Prepare the project planning documentation
  • Prepare all design documentation
  • Project Launch Documentation

As Manufacturing Engineer Eduardo will have to:

  • Create the Mechanical Drawings.
  • PCB layout
  • Design the 3D Models.
  • Manufacture Parts and Assemble final model.

For specific details on what each task contains, see the work breakdown structure chart.

 

Kris Osuna – Electronics and Control Engineer 

Kris Osuna will be responsible for designing, programming, and for doing all research for the hardware we will be using. His top level task are organized in order of priority:

Top level task:

  • Electronic Design
  • Trade Studies/Research
  • Microcontroller and PCB
  • Programming/Control

For specific details on what each task contains, see the work breakdown structure chart.

Raymundo Lopez Santiago – Mission, System, and Testing

Raymundo Lopez Santiago’s top level task will be to work on the system design, software, and hardware testing.

Top level task:

  • System Design
  • Software (for Arxterra interfacing)
  • System Testing

For specific details on what each task contains, see the work breakdown structure chart.

References

  1. Fall 2017 Goliath preliminary project plan 

Motor-Mock Up

/in /by

By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

One of the requirements of the Pathfinder is to determine whether a no-load condition is present, we needed to define what that condition is. In order to test the characteristics of our motor a simple experiment was conducted. The idea is that we wanted to control the load to the motor under a constant voltage and extract the current from the Arduino.

Setup

Appropriate connections were made to interface the Arduino to the VHN 5019 motor drivers so that we could read the output voltage from the onboard current sensors. To communicate with the Arduino through MATLAB we needed to install an add-on package called, “MATLAB support package for Arduino Hardware”. This add-on is very simple to use and eliminates the need for uploading code through the Arduino IDE. It allows for direct control of the Arduino through the serial port and MATLAB has predefined functions that allow for this.

Software

Figure 1: Code for Plotting Motor Current Draw

The code is very simple, it is a while loop that compares the current time with the limited time. While in the loop it reads the analog voltage from the current sensor and then stores that value in a vector that has a corresponding time stamp. After this you can apply some smoothing features to the plot such as an n-point moving average so that we don’t see all the discontinuities.

Results

Figure 2: Results from Motor Mock Up

 

After applying a 25 point moving average this is the result. I applied a resistance to the wheel with my hand about every 5 seconds or so and as you can see, the spikes are where the load was applied. This is very good information for us since we know that the motor under no-load is about 30 mA. In addition, these motor’s have much less current draw than the previous motors on the Pathfinder. In order to get accurate results when applying this to the final mission, we will need to apply an averaging filter to ensure we don’t turn off the motors when they are actually experiencing a load.

References

  1. https://www.mathworks.com/videos/plotting-live-data-of-a-temperature-sensor-using-arduino-and-matlab-121317.html
  2. https://www.mathworks.com/hardware-support/arduino-matlab.html
  3. https://www.pololu.com/product/2502

Spring 2018 AT-ST Project Specific Requirements and Objective (L1&L2)

/in /by

By: Intiser Kabir (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

The Level 1 and Level 2 requirements follow both the S’18 Project and Mission Objectives and EE400D S’18 Project and Mission Objectives documents. Also what our team is hoping to accomplish by the deadline May 15. Level 1 is for general requirements that the AT-ST is hoping to achieve. Level 2 requirements go down to specific requirements for each member hoping to accomplish.

Level 1 Requirements: assigned to all Members

  1. AT-ST shall walk on a level surface
  2. AT-ST shall use Theo Jansen leg design
  3. AT-ST shall look like an AT-ST Walker from Star Wars
  4. AT-ST shall turn left, right or turn around
  5. AT-ST shall support its own weight
  6. AT-ST shall not exceed pass the size of 6’’x 6’’
  7. AT-ST shall not walk through walls
  8. AT-ST should walk backward
  9. AT-ST should have a dynamic walk
  10. AT-ST should jump.

Level 2

Level 2 – MST System/Subsystem Requirements: Assigned to Joseph Cho (MST)

  1. AT-ST shall use Gyro to obtain information for calculating the center of gravity.
  2. The 3DoT Board shall receive commands from the Arxterra app via Bluetooth Transceiver. It will decode and transmit data to servos, PCB and other components of the robot.
  3. The power source shall be able to fit inside our robot and must be integrated into the AT-ST such that it doesn’t conflict with the functionality of the robot.

Level 2 – Electronics & Control Requirements: Assigned to Shweta Hebbalkar (Hardware) and Samuel Yoo (Software)

  1. AT-ST shall use 2 DC Motor to move the legs (1 per leg).
  2. AT-ST shall use a Servo Motor to adjust the center of gravity of the robot so it can turn
  3. The Battery’s duration shall last up to an hour.
  4. AT-ST shall use 2 shaft encoder to keep track of the leg motion
  5. AT-ST shall utilize 2 Lithium Ion Battery – 2Ah for its power supply.
  6. AT-ST shall use an ultrasonic sensor to sense other robots within 0.5-meter radius
  7. AT-ST shall use UV sensor to navigate through the maze.

Level 2 – Manufacturing Requirements: Assigned to Danny Pham (Manufacturing)

  1. AT-ST shall have a total weight of 600 g and weight will be properly distributed to the body and legs to support its own weight while walking.
  2. AT-ST shall not exceed dimensions of 6” x 6” in order to fit in the maze and walk and properly turn without hitting the walls in the maze.
  3. AT-ST shall have its body 3D printed (ABS)
  4. AT-ST shall have legs 3D printed (ABS)

Conclusion

The Specific Requirements and Objectives help incorporate design ideas and ways we can make our robot function. It will also help us understand our restrictions regarding features and objectives the robot can successfully do. We incorporate ideas used in the previous Velociraptor for our AT-ST Walker because they have similar ideas that we want to use. We also try to understand why they didn’t work in the past and want to fix issues regarding the Velociraptors for our design. We are basically like the Velociraptor without the head and tail, and the BiPed without servos to control the leg movements.

 

References

  1. https://docs.google.com/document/d/1cyjXSxK7dr–Xwo8d_XS3zJ5vIeamPyu2YjNbjs5Hzw/edit#heading=h.ieqe41766sxa
  2. https://docs.google.com/document/d/1kwObe9HkGBeCjMYAETA5GiChyxhY1o6bpcmhWKbNFv8/edit
  3. https://www.arxterra.com/spring-2017-velociraptor-preliminary-design-documentation/
  4. https://docs.google.com/spreadsheets/d/1HHaQliwvLYbqErqJi2AVOlqGEzNX7grKOYJ2CBUFQ7M/edit#gid=0

Spring 2018 AT-ST Command and Telemetry (Mobile App.)

/in /by

By: Joseph Cho (Mission, Systems, and Testing)

Verified By: Intiser Kabir (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

 

Table of Contents

Introduction

The AT-ST will be remotely controlled using an Android or Apple mobile device with Bluetooth connection. Once requested to the Arxterra, there will be a mobile app available to download. Using the mobile app, ArxRobot, you will be able to create custom command and telemetry for the connected robot. The mobile device will be connecting with the 3DoT board via Bluetooth. “User” or the person controlling the mobile app will be able to control the prototype robots with their commands.

Main screen of ArxRobot app

Figure 1: Screenshot of the Arxterra App

Description:
On the main screen, you will only see the up-down controls when you first launch the app. The app is currently modified to fit the AT-ST remote controlling. There is a D-pad (directional pad) to control the movements, four selected for the different phases, and one boolean for the run.

Definition

Movement is referring to the AT-ST moving forward, turning left, and turning right. Each command is activated by pressing up, left, and right respectively on the D-pad.

Phases are referring to different stages that AT-ST will go through. “Select” is a command type that returns which phase the user selected back to the 3DoT board to be processed. “Sleep” is a phase that the AT-ST will be resting and wait for further commands. “Learning” is a phase that the AT-ST should navigate through the maze following the user’s command and recording those commands. “Shortest path” is a phase that the AT-ST should navigate the predefined shortest path through the maze. “User define path” is a phase that the AT-ST should navigate the learned user-defined path.

“Boolean” is a command type that returns OFF or ON (false or true) based on the user’s input. The “run” boolean will only affect the “shortest path” and “user-defined path” phases. AT-ST will start moving on its own if “run” is ON and in phases “shortest path” or “user-defined path”.

Flowchart of Arxterra app

Figure 2: Flowchart explaining the how the App works

Description:

The “select” will determine the four phases: Rest, Learning, Shortest Path, or User Defined Path. Based on the phase, AT-ST will act out the following. At “Rest”, AT-ST will do nothing. Durning “Learning” phase, AT-ST will move according to the User’s command and record the movements to learned user-defined path. In “shortest path” phase, AT-ST shall navigate the predefined shortest path only if “Run” is ON. Similarly, in “User Defined Path” phase, AT-ST should navigate the newly learned user-defined path only if “Run” is ON.

Addresses of each command

Figure 3: Screenshot of the Arxterra App that shows trace

Description:
When show trace and trace is on, the address of each custom command can be seen. The list of commands and their address will be shown below.

Custom commands and Addresses

Figure 4: Custom Commands and Addresses

Reference

  1. https://www.arxterra.com/getting-started-with-arxterra/
  2. https://www.arxterra.com/goliath-fall-2017-app-setup-and-remote-control-user-guide/

Spring 2018 AT-ST 3D Print Time

/in /by

By: Joseph Cho (Mission, Systems, and Testing) And Danny Pham (Manufacturing)

Verified By: Initiser Kabir (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

 

Table of Contents

Introduction

This blog post will estimate the time taken for the 3D printing of AT-ST. Our current design is not finalized and will see changes in the near future. With this estimate, our project cost will be more accurately calculated and plans may change to align with the schedule.

Design diagrams

Theo Jansen Leg

Figure 1: Theo Jansen Leg measurements

Description:

The Theo Jansen legs will be 3D printed and made with ABS(Acrylonitrile Butadiene Styrene). Most of these measurements are scaled numbers from the design of the actual Theo Jansen legs. The width/thickness was taken from measuring the previous semester Velociraptor project. There is a slight difference between the width and thickness. Also a thickness of 3.1mm for carbon fiber is thick and efficient enough to support the structure of the legs while saving money. Velociraptor of Spring 2017 had thickness of 3.175 mm, but their design had bigger and heavier parts loaded on to the legs. The main parts to print for the body will be the 4x3x2.5” box, side panels, and some gears.

Figure 2: Makerbot Print Program Diagram

We will be using the Makerbot Print program with the settings below to calculate the print time.

Calculations

(0.5mm nozzle, 50mm/s, 0.2mm layer height, 20% fill) 

Figure 3: Estimate of 3D printing using MakerBot

Description:

According to the Replicator 2 3D printer, it will take 16h and 35 minutes to print our robot. This fails the level one requirement of maximum print time for a single part to be two hours and the total print time for the robot to be less than six hours. The box body is the biggest part of the robot so it will take the longest time to print. In order to fulfill our level one requirement, we should adjust the size and dimensions of the body. The components for each leg piece are already thin and quick to print.

Actual Print Time

Figure 4: Print times

Description:

The Actual print time without the laser printable parts was 5 hours and 56 minutes. This is within the 6 hour project allocation for the 3D printing time.

Reference

  1. http://www.protechcomposites.com/standard-thicknesses/
  2. http://www.makexyz.com/f/estimating-print-time-7ae2fe0cb09b3a8ca4e080a52c66e0b0
  3. https://www.arxterra.com/simulation-and-experiment-of-3d-printing/
  4. https://docs.google.com/spreadsheets/d/180lRo-Qa5YwvbPFjHR9tjkG2ByO9Ti5M52t809bQhYo/edit

No-Load ISR

/in /by

By: Jordan Smallwood (Pathfinder Project Manager and Electronics & Control)

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction:

The idea is that if any of our motors are under a no-load condition we want to cease power to that motor, since it makes no sense to waste power on a freely spinning motor. In order to do this we will need to understand the conditions present when our motor is experiencing no-load. This is determined in the motor-mock up study found HERE. Since current is proportional to the load that the motor is experiencing we can check the current to each motor and compare with the conditions. This will be implemented with an internal timer interrupt.

The robot will not be travelling that fast and we can set a timer interrupt with a period of 100 ms that will check the motor conditions every 0.1 seconds. Also, one of the things to keep in mind is that we need to know when the motor is ready to have power reapplied to it. So whenever we enter this interrupt routine we will check any of the motors that are off to see if a load is present.

Software:

Intro to Timers:

In order to set up the timer based interrupt we need to briefly overview internal interrupts. Internal interrupts make use of the Arduino timers, for the Mega we have 6 timers. Any time you decide to make use of a timer it is paramount that you make sure it is not already in use or that pins associated with that timer are not being used (e.g PWM pins). There are two different size timers on board the Arduino, 8-bit and 16-bit, depending on the resolution needed. Also, all of these timers depend on the internal clock of the Arduino which may be 8 or 16 MHz depending on what board you are using. In my experience always leave timer0 alone, it is used heavily within functions and is best left untouched.

Timer Registers:

Figure 1: Timer/Counter 5 Control Register A

Figure 2: Timer/Counter Control Register B

These 2 registers contain all the bits that describe the function of your timer. The only bits that we will be concerned with are the WGMnX and CSnX bits. The others become more complicated and there is not need for them with what we are trying to do. For our purposes we will have the timer in CTC mode (Clear Timer on Compare Match) and we will load a certain prescaler depending on the desired frequency. Note that this can be done in normal mode in which we preload the timer with a value and set up a timer overflow interrupt. However, we chose to do CTC mode. The tables below describe the various modes and prescalers:


Table 1: Waveform Generation Mode Bit Description/Truth Table

Table 2: Clock Select Bit Description/Truth Table

              If we are using the CTC mode then we can realize that we need the following line of code:

Figure 3: Setting Timer 5 to CTC mode

              The following scheme can be used to determine the value to compare the timer with and the required prescaler.

  1. Find CPU Frequency (16 MHz)
  2. Find Max Counter Value (16-bit Timer -> 65536)
  3. Divide CPU Frequency by Selected Prescaler (16MHz/256 = 62.5kHz)
  4. Divide Result by Desired Frequency (62.5kHz/10Hz = 6,250)
  5. Verify that this is less than max counter value (6,250 < 65536)

Now that we realize a prescaler of 256 will do the trick we can examine the truth table for the prescalers and find that a value of 0b100 corresponds to that prescaler. So then the following line of code can be implemented:

Figure 4: Loading Prescale Value Into Timer Control Register

Figure 5: Output Compare Register 5A

Since we have set up the timer frequency and mode of operation now we need to load the value to compare the timer with. As mentioned earlier we found that the value to compare the timer with was a count of 6,250. So, we will include the following line of code:

Figure 6: Loading Output Compare Register

Now all that’s left to do is enable interrupts within the timer 5 interrupt mask register. Here is what the register description looks like:

Figure 7: Timer/Counter 5 Interrupt Mask Register

Since we are only using channel A on timer 5 we will set the corresponding timer compare interrupt enable with the following line of code:

Figure 8: Enabling Timer 5 Output Compare Interrupt

Finally we have a timer driven interrupt that is capable of checking the motor conditions and will be able to turn on or off power to the motors. This is done every 0.1s and all that’s left to do is write the ISR corresponding to this interrupt.

Interrupt Service Routine:

The original idea behind this interrupt was to check the condition of the motors. The motor drivers have current sensors on them that are mapped to pins on the mega. These current sensors have an output voltage that is approximately 140mV/A passing through the motors. We can determine the current through the motors with an analogRead() function and realizing the current is some factor of that.

Figure 9: Calculating Current From Current Sensors

Since the resolution of the ADC is not that great, at least with respect to our reference voltage, the output of the current sensors will be limited to steps of about 35 mA. Which means that our reading will be off by at most 17.5 mA.

Now that we know how to read the current we need to turn off the motors that are below the no-load current threshold. We can do this with a simple IF statement:

Figure 10: Code to Check if Motor is under No Load Condition

The next thing to realize is that if a motor is already off we need to check if it is experiencing a load. This will be done by setting a flag, that is any time we turn a motor off we will want to turn it back on in the next interrupt and check if it is still in a no-load condition:

Figure 11: Code for Checking if Motor is Still Under No-Load

Note that in order to avoid conflicts with the 6 Wheel Electronic Differential we need to save the last known speed of the motor so that when we turn the wheel back on it doesn’t try to go full speed.

Conclusion:

In order to implement this type of control a timer based interrupt service routine is a good choice. We could have used different methods, but we know that this will not happen that often. Setting a timer to check this condition was a simple but effective solution. Also, utilizing a Finite State Machine in the ISR is a promising idea because we want to be able to determine when the wheel is ready to be turned back on.

References:

  1. http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf
  2. https://www.pololu.com/product/2502
  3. https://www.robotshop.com/letsmakerobots/arduino-101-timers-and-interrupts

Goliath Spring 2018 – Preliminary Design Review

/in /by

Written by Ernie Trujillo (Project Manager), Ryan Nguyen (MST Engineer), Tai Nguyen (E&C Engineer), Milton Ramirez (E&C Engineer), and Daniel Guerrero (M&D Engineer)

Table of Contents

Mission Objectives

Written by Ernie Trujillo (Project Manager)

The main objective of the Goliath Tank is to navigate through a maze, first, controlled by the User and, second, autonomously playback the unique path initially input by the User. Afterwards the Goliath Tank will be tested in terms of avoiding collisions with other robots if they happen to interfere with the path required to be traversed by the Goliath through the maze. As far as mission constraints, the team will be required to use the Arxterra App to program the robot to navigate and playback the unique path through the maze given by the User.

 

For more detailed information of the Customer expectations and Mission Objectives, proceed to the link provided below:

S’18 Project and Mission Objectives

Level 1 & 2 Requirements

Written by Ryan Nguyen (MST Engineer)

Level 1 General Requirements

  1. The robot shall be completed by May 15
  2. The robot that is to be designed shall be done in such a way that it is relatively inexpensive, less than $250, preferably a laser cut model or 3D printable design.
  3. Since robots are to be operating the maze simultaneously, the design should ensure that collisions are to be avoided in all situations.
  4. When printing 3D models for the project, any prototype print shall obey the 2/2/2 rule and shall take no more than 6 hours in sum. Projects may request a waiver with justification.
  5. Robots shall utilize a version 6 3DoT board powered by the 3.7V RCR123A battery. Projects may request a waiver with justification.
  6. The robot will be designed in such a way that there are no dangling or exposed wires. Connectors will used between all electronic and electromechanical components. Jumper wires will not be used, ribbon cables are preferred; gauge of wires should be consistent with current.  
  7. Good construction techniques: all moving and rotating parts shall use bushing or bearings, hinges shall be interlocking and include a latching mechanism. No gaps shall be greater than 1 millimeter, immediate access shall be provided to all external connectors (USB, switches).
  8. The robot shall record the user’s input and be able to repeat the previous route defined by the user. The software algorithm is defined in 400D E&C lab sequence.
  9. During teaching mode, ArxRobot app via mobile devices shall be used to teach the robot to navigate the maze.
  10. During playback mode, the ArxRobot app shall transmit live video feed and telemetry to the Arxterra control panel, including battery level.
  11. The Robot disassembly time shall be 10 minutes. Projects may request a waiver with justification. All 3Dot boards will be clear of electronics, motors will be disconnected, all sensors will be disconnected.
  12. Reassembly time shall be 10 minutes. Projects may request a waiver with justification. All teams will be allowed to use a cable tree as well as an assembly diagram as necessary. All robots will be tested after reassembly to confirm its functionality.

Goliath Level 1 Requirements

Project L1 Requirements

L1 – 1 The Goliath will drive on flat surfaces, such as cloth, paper, linoleum.

L1 – 2 The Goliath shall be operational for 1 hour duration.

L1 – 3 The robot shall be a scale replica of a Goliath 302 Tank. The scale factor will be 1:11.5 with a mean

          square error (MSD) over all three axis (x, y, z) of no greater than 10%.

L1 – 4 The total cost of the goliath shall be no greater than $200.

L1 – 5 The Goliath shall have easy access to charging and programming hookup.

L1 – 6 Goliath shall house a custom PCB and use control telemetry shall to navigate the maze.

Program L1 Requirements

L1 – 7 The Goliath should make tank noises.

L1 – 8 Goliath shall detect and avoid other robots in the maze.

Goliath Level 2 Requirements

System L2 Requirements

L2 – 1 The mass of the goliath shall not exceed 400 grams. Goliath L1-3

L2 – 2 The goliath shall be smaller than 5x4x3 inches. Goliath L1-3

L2 – 3 Goliath shall use IR range finder to detect objects. Goliath L1-7

L2 – 4 Goliath’s final version shall be printed with ABS plastic. General 3

L2 – 5 The Goliath shall be power by a single 3.7v RCR123A battery. General 6

 

Subsystem L2 Requirements

L2 – 6 Main PCB shall have two UV sensors, UV LED, Gyro, and connectors to range finder. Goliath L1-6

L2 – 7 Arx-robot App will have different operating control modes and direction pad to control Goliath’s

          movement. Goliath L1-6

L2 – 8 Goliath shall have 4 x 10 mm cut out on back of goliath to provide access to charging and

          programming hookup. Goliath L1-5

L2 – 9 The Goliath will not have any electrical parts mounted outside. General Level 1-7

L2 – 10 The Goliath should have a latched lid. Interlocking mechanism. General Level 1-8

L2 – 11 The goliath shall detect objects in an 10 inches in front. Goliath L1-8

L2 – 12 Goliath will have all-terrain tracks. Goliath L1-1

L2 – 13 The goliath shall have 10 gears. Goliath L1-1

L2 – 14 The goliath shall have 2 motor(s), located in the back of the chassis. Goliath L1-1

 

System Block Diagram

Written by Ryan Nguyen (MST Engineer)

Figure 1 – System Block Diagram for the Goliath Tank.

The system block diagram illustrates how components of the Goliath communicate and connect with each other; from the control panel that uses Wi-Fi to talk with the mobile app to the wheels and treads. More detailed specific components such as the HM11 Bluetooth model is added, and various parts on the PCB parts are laid out; more items are expected when the E&C engineer completes trade off studies. The 3DoT board houses a rechargeable battery that powers the motor driver and the Atmega32U4, which in turn powers the PCB. Number of pins are listed to demonstrate a rough idea of how many pins are required and create rough layout for the interface matrix.

Work Breakdown Structure

Written by Ernie Trujillo (Project Manager)

Figure 2 – Layout for the Work Breakdown Structure of the team members.

The Work Breakdown Structure (WBS) provides organization for the tasks a team is required to complete for a project. For the Goliath team, the WBS offers a general overview of the objectives that every team member is required to do. The tasks are broken down in terms of the type of engineer (MST, E&C, and M&D) and then within each field it goes into further detail as to what each position’s tasks entail. This diagram offers each engineer a quick overview of the responsibilities that their position takes on.

Product Breakdown Structure

Created by Ryan Nguyen (MST Engineer)

Figure 3 – Diagram of the Product Breakdown Structure.

Like the Work Breakdown Schedule, the product breakdown schedule breaks down the products and the personnel responsible for them. In the spring 2018 project, the Goliath is broken into three products: Electronics, Program and Control, and Manufacturing. All components such as shields and sensors are the responsibility of Milton, as they go on the custom PCB. Tai creates the programs for movement and ultimately completing the mission. Ryan takes care of the communication between the mobile App, control panel, and robot. Lastly, Daniel fabricates the Goliath.

 

Interface Matrix

Written by Ryan Nguyen (MST Engineer)

The interface matrix shows how each subsystem of Goliath connect to the ATmega32U4 microcontroller. The top header consists of the sub-systems, the left column has the name and pin number of the ATmega32U4. The matrix maps out how each pin is connected.

From the ATmega32U4, the version 6x 3 dot board specifies 16 pins that students can use for their robots. The first matrix shows the two PCBS of Goliath that will be connected to the three dot board, the top header shield, and the front sensor shield.

Figure 4 – Interface matrix of ATmega32U4

The second matrix shows how the components on the sensor shield will be connected; Goliath uses two UV sensors, as well as a range finder to navigate the maze.

 

Figure 5 – Interface matrix of front sensor shield

Lastly, Goliath uses a gyro, connected to the top PCB, to determine turning in the maze.

Figure 6 – Interface matrix of top header shield

 

 

Fritzing Diagram

Created by Milton Ramirez (E&C Engineer)

Figure 7 – Fritzing Diagram for the Goliath Tank.

Figure 8 – components used for the Fritzing Diagram.

This a prototype of how we will connect the parts we are going to use and some of these parts might not make the final design. In this prototype our processor will be the pro micro instead of the 3Dot board since Professor Hill is still working on the 3dot board. Also, for that same reason we will have to use Bluetooth circuit for our prototype since the 3dot has Bluetooth implemented in it. We will probably have to use this configuration for most of our testing since we won’t get the 3dot until later in the semester. We also have a motor driver to control our motors. Then we are using a multiplexer for our sensor which are a Gyro sensor and a color sensor. Then we also have a Range finder and this and the color sensor are floating outside on purpose because the color sensor goes in the bottom of the goliath and the range finder we be somewhere in the front. Also the specific part number are not include since that will also change for the last design.

 

Mechanical Drawings

Written by Daniel Guerrero (M&D Engineer)

Figure 9 – Preliminary sketches for the Goliath Tank.

The reason behind this design was to follow the concept of the spring 2016’s design to create a box shell of the tank as a preliminary design and attempt to fit all of the equipment inside. I tried to steer away from just a simple box for this design and tried to follow the generic shape of the German 302 goliath tank. As for the placement of all the gaps in this design, I was aiming to have it accessible enough to configure all of our equipment into the design. For this first edition I kept the size to five inches in length by four inches in width and about three inches in height.

Resource Reports (Power, Mass, Cost)

Written by Ryan Nguyen (MST Engineer)

Power Report

Figure 10 – Spreadsheet for the power consumption of the components.

The power report needs more information in measuring the power draw, this will be done once some sort of system is established for parts such as the 3Dot board and motors. Sensors’ measurements are from data sheets that manufacturer provide. Project allocation comes from the maximum instantaneous current the RCR123A can provide.

Mass Report

Figure 11 – Spreadsheet for the mass of the components.

Much of the mass report are assumptions, based on visual inspection of parts online. Many parts do not list the mass, such as sensors. It is decided to put 10% margins on all parts as they could fluctuate once the product solidify. Project allocation was based on a requirement that the Goliath shall withstand all impact with all robots; thus the chassis must be quite sturdy.

Cost Report

Figure 12 – Spreadsheet for expected expenditures for the Goliath Tank.

The cost report was based from the previous projects, with large uncertainty placed on 3D printing as it is undetermined how many iterations will be printed. Several items are free as they are provided by the class, others are taken from online. Shipping price are considered in uncertainty. Project allocation of $200 dollars was given by the mission objective to make a relatively cheap toy.

Preliminary Budget

Written by Ernie Trujillo (Project Manager)

The customer allotted $200 towards the Goliath Tank project. At this moment, the total expenditure of the project can not be confirmed as the cost for the PCB and the 3D prints designs are unknown. Also, since the definitions of the maze are not complete at this moment, there is a chance that some sensors will be added to the list while others are removed. About 60% of the budget has been established while the remaining funds will be used for the last few parts that will be needed to complete the Goliath Tank.

Figure 13 – Excel spreadsheet for the components needed for the project. (1/2)

 

Figure 14 – Excel spreadsheet for the components needed for the project and totals and general overview of the project budget. (2/2)

The spreadsheet provides most of the parts that will be required for mission success. (Will be updated to include all the parts) Included is useful information to the team such as the quantity, cost, and link to the part.

Planning & Schedule

Written by Ernie Trujillo (Project Manager)

Figure 15 – Gantt Chart , these tasks mainly focus on being prepared for the Preliminary Design Review. (1/3)

 

Figure 16 – Gantt Chart (2/3), tasks that are pertinent to implementing the hardware to the Goliath.

 

Figure 17 – Gantt Chart (3/3), tasks that focus on software implementation and final verification of the Goliath.

Broad Layout of Project Schedule

Phase 1 (Research), Weeks 1-5:

  • Look through blog posts from prior semesters on Arxterra website for useful information that the current team can implement.
  • Begin developing level 1 & 2 requirements to meet mission objectives and customer expectations.
  • Begin layout for all tasks required to reach mission success at the end of the 16th

Phase 2 (Preliminary Design Review), Weeks 6 – 8:

  • Achieve a thorough schedule to lay out all tasks required to be complete by the team to bring the project to fruition.
  • Accomplish preliminary tasks: preliminary 3D model, system block diagram, fritzing diagram, mechanical drawings, resource reports, work and product breakdown structure.

Phase 3 (Rapid Prototyping), Weeks 9 – 12:

  • Design multiple iterations of Goliath Tank to make final product more efficient.
  • Create program that will integrate all systems that are in the system block diagram. Also, ensure that the program will have the robot operate in a manner that meets mission objectives.
  • Have E & C Engineer work on creating and finalizing custom PCB.
  • Have MST Engineer work on Arxterra custom command and telemetry (Application side)

Phase 4 (Final Product & Mission Success), Weeks 13 – 16:

  • Finalize Goliath Tank 3D model and ensure that all systems are working properly.
  • Complete Project Video that shows progression of project and implementation of the Engineering Method.
  • Complete Final Blog Post which displays a comprehensive overview of the Goliath project from start to finish.
  • On the day of the Final, demonstrate that the Goliath can navigate through the maze and meet all the L1 & 2 requirements.

Summary of Experiments done / Rapid Prototyping Completed

E&C Software Summary Progress

Written by Tai Nguyen (E&C Software Engineer)

  • In progress of setting up pins to be compatible for the 3DoT Board, currently only set up to use with Pro Mico 3.3v
  • I have the ToF Range finder code set up and am working on integrating it into the main code and eventually how it will play into the robot avoidance strategy.
  • Using a mixture of previous Goliath Code and my own input from the gyro I worked with EE 444 for turning, has yet to work properly, needs better calibration code and play testing.
  • Line following code for IR sensors is ready to use if desired.
  • Working on learning the UV sensor based on the recent blog post research by morning section
  • Color sensor research has been put on hold until UV sensor has either been chosen or rejected by the team.
  • Have yet to work with motors in terms of applying the code as well as characterization

3D Model Simulink Prototypes

Written by Daniel Guerrero (M&D Engineer)

Figure 16 – Bottom piece of the center console.

The reason for this design is to add a base for the rear motors to sit on while also providing space underneath to fit any other electrical components we might have. For the hole at the bottom, we weren’t sure if we were going to continue the line following maze, so I created a hole at the bottom to accommodate for a line following sensor if needed. Also created a hinge like part to the rear of the bottom piece to connect with the top portion to mimic a closing feature.

Figure 17 – Top piece of the center console.

Like the side pieces i wanted to keep the tank open until we figured out all the components in the tank. also added the connecting hinge to bottom portion of the tank.

Figure 18 – Side piece for the Goliath.

Wanted to maintain an open design to freely move the parts where ever needed. Made the perimeter thicker than the previous model to be sturdier and be able to screw the pieces together if needed.

Resources

  1. www.arxterra.com/goliath-fall-2017-final-blog-post/
  2. www.arxterra.com/preliminary-design-document-2/
  3. http://web.csulb.edu/~hill/ee400d/Lectures/Week%2001%20Company%20and%20Mission/c_Job%20Descriptions.pdf
  4. https://docs.google.com/spreadsheets/d/19V-HOCEmgzXqFk2eOJVdiPhIjCBXNKYeMXI5y_aF87E/edit#gid=0
  5. Pro Micro
  6. I2C Expander
  7. https://www.arxterra.com/initial-design/
  8. https://docs.google.com/spreadsheets/d/15eEC1hPg-atkorm0VIFIhtkroHR1IgFu7A8-NwoKVB0/edit#gid=0
  9. https://docs.google.com/spreadsheets/d/1X2e8fMk9zH4d6ugtWx0KzsvcbpDvAjY_uL_h4tcDotE/edit
  10. https://www.projectlibre.com/
  11. ToF Range Finder 
  12. https://docs.google.com/spreadsheets/d/1F9hwY03QBFUImZ_wKt4pEAWqgT7hq6SKrcHJS8AYq6I/edit#gid=1180904142

Auxiliary Panel Trade-Off Study

/in /by

By: Adolfo Jimenez (Manufacturing)

Verified By: Jordan Smallwood (PM)

Table of Contents

Introduction

Figure 1: Top View of Solar Panel Structure

One of the requirements for the pathfinder project is that the robot should be able to enter and exit a cocoon state via user input in the Arxterra app. This feature is reminiscent of the original Pathfinder Mars Rover which upon contact of the Martian surface, would emerge from its space pod and out of its cocoon state. The benefit this brings to our robot is that it will allow the storage of the rover in a relatively small space such as a cabinet. Currently, the front panels utilize a worm gear attached to stepper motor to articulate the butt and front panels. The Auxiliary back panels however, are attached to the front panels via a hinge and need to be manually opened and closed. Ideally, this process of entering and exiting the cocoon state would be completely autonomous. The following discusses several possible designs that could be implemented to expand/contract the back panels.

Worm Gear:

Figure 2: Illustration of Worm Gear Mechanism

As mentioned before, the side panels work by using a worm gear attached to a stepper motor. The worm gear rotates a spur gear fixed to a rod within the hinge that pivots the side panels around the base panel. This system, we decided, would be too bulky to be implement onto the back panels. Stepper motors work for the movement of the main panels as the motors are fixed to the base panel however, this would add weight to the front panels and thus more strain on our current stepper motors.

Sliding mechanism:

Figure 3: Illustration of Sliding Mechanism

One of our earlier designs involved a sliding mechanism using a rack and pinion gear assembly. This mechanism would have utilized a geared shaft along with a motor to spin and sit under one of the main wings. The system would extend and retract the panels similar to a CD-ROM drive found in a computer. The issue with this design was the amount of space this assembly would have added to the wings.

Linear actuator:

A continuation of the previous design was the use of a linear servo or actuator to push and pull the back panels. The servo/actuator would have been placed underneath the front panels and the rear panels would rest and slide on linear ball bearing side mounts like those found on the sides of cabinets drawers. The issue with this design is the cost, linear servos and actuators are unfortunately quite expensive.

Hinge servo:

Perhaps the simplest and most practical of our ideas was the use of a high torque servo to move a hinge as shown in the video below. The issue with this design is that the back panels would not sit perfectly flush with the front panels. A fix to this might be including a spring to the servo arm to allow the panel to fall by the force of gravity and to pull when needed to be opened.

Pulley and winch design:

Our most exciting design, and perhaps the one with the most “cool factor”, included the use of a winch and pulley system. To achieve the closing of the panels, a constantly closing hinge would have created a closing force that would want to maintain the panel in a shut position. To open the panels, a steel cable running through a series of pullies would be pulled and wrapped around a reel fixed to a motor shaft that would create a pulling force and pry open the panels. The motor would then slowly release tension to re-close the panels. During prototyping of this design, it was discovered that not much actual cable was displaced when pulled to warrant the use of a reel, therefore, a servo and arm attachment could be used to pull and hold the small amount of cable needed to open the panels. It was also discovered that in order to pull the panels open, the force pulling on the rear panel needed to be at an angle. This I because pulling parallel to the panel required a lot more force when compared to pulling at a slight angle. To fix this issue, two pulleys that would lift the cable at slightly an angle would be used on both panels to reduce the force needed to pull back the panel.

Figure 4: Pulley Design

Figure 5: Pulley Design Continued

Spring Hinge:

Figure 6: Spring Hinge Concept

              The most rudimentary and cost effective of all our ideas was the use of a spring hinge to open the panels. Similar to the actual Mars rovers, the spring hinge would provide us with the one-time motion of opening the panels. These hinges would be like the hinges used in the previously mentioned pulley design however, these hinges would exert a force in the opposite direction. In order to maintain the panels closed some sort of latch mechanism needed to be included. Two magnets located on the ends of the panels could be used to maintain the panels closed after having them physically shut manually.

Conclusion:

Unfortunately, due to time and budget constraints, we realized after prototyping and research that we would not be able to afford to autonomously close the back panels. A review of our design requirements however, led us to discover that there was no actual requirement that specifically dictated that the system returning the rover into its cocoon state needed to be entirely autonomous. Because of this, our team decided to go with the solitary opening spring hinge design. We hope that future generations of the project however might find this post and our ideas useful to accomplish a fully automatic articulation of the auxiliary panels.