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.

Ultrasonic Field of View Test

/in /by

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

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

In order to develop an object avoidance routine we needed to verify that the ultrasonic sensors would work for detecting objects. To verify the field of view a simple experiment was constructed that would determine the distance to an object. The experiment is as follows.

Parts Required:

  1. HC-SR04 Ultrasonic Sensor
  2. Arduino (Any will do)
  3. Serial Monitor
  4. Ruler or other measuring device
  5. 2 LED’s with CLR’s

Figure 1: Fritzing Diagram for FOV test

Setup:

The ultrasonic sensor has 4 pins: VCC, GND, Trig and Echo. Vcc and GND are for powering the device where as Trig and Echo are the signal pins. Trig is short for trigger, applying a pulse to this pin will emit an ultrasonic ping that travels from the transmitter. The echo pin is where you receive the ping coming off the object of interest. The time delay that takes place between these steps will determine how far away an object is. For our setup, Trig was hooked up to pin 13 and Echo was hooked up to pin 12 but any digital pins will work.

Next upload the code provided to get an output from the Serial Monitor showing the distance to the object.


Figure 2: Code for FOV test

Determining Field of View:

In order to determine the field of view of the object two rulers were set up to determine when we lost sight of the object. The object was recognized directly in front of the sensors at x = 16 cm and then moved up and down in the z-direction. The sensor lost sight of the object at about 6 cm above or below. The same situation took place when the object was moved along the y-direction. From this we can gather that the field of view is about 18 degrees.

Figure 3: Determining Safe Object Detection Distance

              The distance L is the safe object detection distance. If we detect anything closer than that is when we lose overlap between the sensors which means that we could run into trouble if anything gets closer than that. The distance can easily be found as:

Figure 4: Determining Safe Distance L

Conclusion:

The Ultrasonic sensors are actually pretty impressive. I’ve never uploaded code and received immediate results, this was a first for me. I would put my hand in front of the sensor and compare the actual distance to find they were very comparable. With these sensors we can easily detect if an object is too close and from that we can implement some kind of avoidance strategy.

References

http://www.instructables.com/id/Simple-Arduino-and-HC-SR04-Example/

Ultrasonic Sensors – Field of View

BEAR-ings

/in /by

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

Approved By: Miguel Garcia (Quality Assurance)

Probably the coolest part in most mechatronic designs would have to be bearings. They’re simple but confusing and very amusing, at least for me. There are many different types of bearings in all different shapes, sizes, colors, and functionalities. The reason for this blog post is that one of the main issues with the Pathfinder build was the lack of knowledge when it came to constructing the rocker-bogie mechanism. Let me begin by saying that it is in no way previous semester’s fault for not understanding this since we are electrical engineering students.

There are two main types of bearings, thrust and radial, from those branch various specifications about each one in regards to size, forces, and speed. However, the scope of this post is to enlighten those who are concerned about which type of bearing to use.

Figure 1: Different Loads Acting on A Bearing

Thrust bearings are the type of rotary bearing that allow parts to rotate about the other but unlike their radial counterparts they are designed to support axial loads. Axial loads are forces that are applied in the direction of the shaft.

Figure 2: Example of a Thrust Bearing

Radial Bearings are the opposite and they support, wait for it, radial loads! These bearings are common and you have probably used them once or twice whether they were in your skateboard or roller blades.

Figure 3: Example of a Radial Bearing

The issue with the build of the Pathfinder is that the load on the rocker-bogie mechanism is axial and the type of bearing placed on them was a radial bearing. This radial bearing was essentially acting like a spacer between parts since they were making contact with both rotational elements. To improve the design we obtained some inexpensive thrust bearings off Amazon and they have solved the problem.

References

  1. https://www.ggbearings.com/en/faq/what-are-radial-and-axial-bearings
  2. https://qualitybearings.wordpress.com/2010/08/31/bearing-load-type/
  3. http://www.bearingshopuk.co.uk/lt-5-8-thrust-bearing/
  4. https://www.vxb.com/ML-5008-Radial-Bore-Dia-5mm-OD-8mm-Width-2mm-p/ml5008.htm

6 Wheel Electronic Differential

/in /by

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

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

Have you ever considered how a train makes a turn? Really try and think about it, it has two wheels on a track separated by a distance but when it turns it doesn’t fly off the track. It’s not very intuitive but if a train was making a right turn, going along a curve to the right, the left wheel is traveling a greater distance since it’s on the outer curve. However, the two wheels traveling along the track are joined by a steel shaft that doesn’t break. So, what is the explanation for this phenomenon?

Figure 1: Differential Explanation

              Trains have conical wheels that allow for this freedom of motion at the track, they slide back and forth along the track allowing the train to tilt one way or the other. Now, the Pathfinder is not a train and will not be riding along tracks, but the same concept applies.

Encoders

The Pathfinder has 6 motors all connected to the same power source and in a perfect world if we supplied each of these motors with the same PWM command they would all go the same speed. However, this is not a perfect world and many factors can come into play when it comes to how fast the motor spins. First off, the whole premise behind the Pathfinder is that it can climb objects asymmetrically, that is each motor can be experiencing a different load which is one of the major reasons behind needing an electronic differential. Secondly, when we make turns we want to make sure the wheels are going at the speed we want them to account for the difference in distance traveled. And finally, due to natural mismatch in motor build we need to examine the difference in speed of the motors.

Herein lies the problem we have faced and have tried to come up with a solution for the past month or so. The motors on the Pathfinder currently do not have any encoders. We have looked at every possible type of encoder such as magnetic, optical, and any other possible type but we have finally realized that the only way of getting a truly good output from the encoder is by purchasing motors that already have encoders installed. The reason behind this is simply to achieve the greatest possible resolution with your encoders is to get your output prior to the gearbox. I can not stress that enough. If you ever have a project that you need encoders on make sure you either buy motors with an extended shaft or motors that have encoders included otherwise you might find yourself in the same situation. $200 later we now have our encoders.

Hall Effect Sensors

Now that we have motors with encoders connected prior to the gear-box we need to understand how they work.

Figure 2: Diagram of Hall Effect Sensor

              In the presence of a changing magnetic field, a charged semiconductor plate will deflect the flow of electrons from one side or the other. Consequently, one side of the plate will become more negative while the other becomes more positive. This is the basic principle of how a hall effect sensor works. A magnet is placed perpendicularly to the sensor plate and the Hall Voltage on the plate is observed. This is typically found in many encoding applications. There are two different types of Hall Effect sensors available, one that is a measure of flux density and the other is compared against some threshold voltage. We will be utilizing the latter since we are only concerned with the count and not the distance to the magnet. Another great feature of hall-effect sensors is their ability to toggle between states which means that bouncing is not an issue.

The encoders that we have paired with our motors have 6 pins associated with them, they are as follows:

  1. M1 (Motor Power Supply 1)
  2. GND (Encoder Ground)
  3. C1 (Encoder Channel 1)
  4. C2 (Encoder Channel 2)
  5. VCC (Encoder VCC)
  6. M2 (Motor Power Supply 1)

 

For each revolution of the motor we will receive 11 counts per channel which results in 22 CPR overall. Depending on the gear-box reduction ratio, which in our case is 280 (14 RPM), we can calculate the resolution as follows:

Figure 3: Determining the Resolution of Shaft Encoders

Note that this is the maximum resolution and there is an included error from the motor manufacturers data sheet. Depending on the amount of precision you need you can always use both channels, also if you need to determine direction of the motors then you will need to use both channels. For our purposes though we will only need to occupy one channel since pin allocation has become something of an issue for us.

Implementation

To accurately and efficiently read the encoders we will be using interrupts. By using interrupts we can allow the code to progress as normal and minimize the amount of time outside of the main loop. In order to make this 6 wheel differential work we have two options.

  1. We can set a desired speed that the robot travels and make all 6 wheels track that speed, or try to stay within a certain margin of that speed.
  2. We can set one of the motors to a certain PWM value that we are comfortable with and force the other 5 motors to follow that speed.

The issue with the second option is that even though we are sending a constant speed to one motor, it could fluctuate about some speed and that can cause issues with our control scheme. There is much less error when tracking a step input rather than a varying signal. Therefore the plan of action will be to set a desired speed, within capable limits of the motors, and make each motor follow that desired state.

In order to realize this we are going to need to design a controller that can follow this input. In my experience one of the easiest types of controllers to implement would be a proportional controller. Proportional control is relatively simple and comes at a low cost to the memory of our MC.

After running some experiments and playing with the gain we can figure out exactly how to implement this type of controller. For our purposes we will have 6 controllers, one for each of the motors. The input will be a constant velocity and the output from the encoders will be fed back to the summing junction to compare with the set point.

Software

Reading the Encoders

To efficiently read the encoders we will need to set up some interrupt service routines, specifically one for each motors encoder channel. This will be done similar to the following code:

Figure 4: Code for reading the encoders

              To get more information on how to set up interrupts like this please refer to the blog post regarding them HERE.

To verify that the output from the ISR was correct I applied a test voltage from a power source and found that the elapsed time between pulses was about 1450 microseconds for the 14RPM motors. After playing with the values and factoring in the gear ratio and CPR values the no-load speed of the 14 RPM motor was approximately 13.4 RPM which verified that these encoders are providing good feedback.

Control

              Knowing the limitations of your control is important when it comes to implementing a design. For example, we know that these motors can spin without any load at a maximum of about 14 RPM. So, we want to travel at a speed that will allow for the system to adjust for disturbances such as changing loads, error in sensor readings, and anything else that might present itself. Therefore, we will set the desired speed to a comfortable 10 RPM, this will allow the system to adjust in both directions.

We can include different equations in our ISR to calculate the speed but it would be easier if we just returned the delay between pulses and let the control track that instead. For a speed of 10 RPM it can be shown that the delay is about 1,950 micro seconds. If the actual speed of the motor is greater than 10 RPM then the delay would be less and if the motor was traveling slower the delay would be greater. Also, if we wanted to apply a gain to the controller we would need to come up with something that makes sense. If one of the motors was traveling faster than the set point by 1 RPM then that would translate to about 100 microseconds so if we wanted to allow the controller to respond aggressively to large errors a gain of about 4 would do the trick. With all of that in mind we can construct the controller as follows:

Figure 5: Code for Speed Controller

References

  1. https://www.arxterra.com/pin-change-interrupts/
  2. https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/
  3. https://www.arduino.cc/en/Tutorial/BlinkWithoutDelay
  4. https://sciworthy.com/why-trains-dont-fall-off-the-track-when-turning/
  5. https://www.electronics-tutorials.ws/electromagnetism/hall-effect.html

 

Spring 2018 3DoT Hexy: Prototype Fritzing Diagram

/in , /by

By: Kris Osuna (Electronics and Controls Engineer)

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

Approved by: Miguel Garcia (Quality Assurance)

Introduction

We used the open source fritzing software to create a prototype that will show all connections to an Arduino Leonardo. The Leonardo is used because it uses the same processor as the 3DoT board. The Leonardo provides 3.3V to the pins which is less than the 3DoT board provides, so if it works on the Leonardo it will work on the 3DoT board. The prototype will be able to move with motors connected to a dual motor driver to control the motors. Three UV sensors will be connected with three UV LEDs. The UV sensors and LEDs will help the robot navigate the maze. An I2C multiplier for the serial data is needed. An ultrasonic sensor is needed with two digital pins. The ultrasonic sensor will detect other obstacles.

 

Related Requirements

Level 1 Requirements

  • The robot will need to navigate remotely through a custom-built maze (built by AoSa image), memorize the path it took, start over, and autonomously travel through the path it took.
  • The robot shall avoid collisions if it encounters other robots while navigating through the maze. This involves detecting the robot, retracing steps back, and moving to a room that allows the other robot to have a safe passage.
  • The robot shall use a v6.43 3DoT board.
  • The robot shall demonstrate the capabilities of the 3DoT micro-controller for DIY hobbyists.

Level 2 Requirements

  • The robot shall use a single RCR123A 3.7 V, 650mA rechargeable Li-ion battery to power the 3DoT board, which will power the drivetrain and all attached peripherals.
  • The robot shall use 2 UV sensors connected to a custom PCB.
  • The robot shall use a HC-SR04 ultrasonic sensor to handle robot avoidance.
  • Ultrasonic sensor shall have a range of 0.5-meter radius to detect and respond accordingly to other robots.

Preliminary Design Fritzing Diagram (March 08,2018)

Figure 1: Preliminary Design Fritzing Diagram 

Resources

  1. Fritzing Tutorial
  2. Sparkfun Fritzing Library