Rocker-Bogie Suspension System

By: Adolfo Jimenez (Manufacturing)

Verified By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)


Table of Contents

Introduction:

In order to mimic the suspension capabilities of the rovers sent to Mars by NASA, our rover will incorporate the same rocker bogie suspension system utilized by the Mars rovers to traverse an extreme desert-like terrain. This suspension system, introduced with the original Mars Pathfinder project, is the same design preferred by NASA for nearly all the Mars rovers. The main advantage of this type of suspension system is that the load on each wheel is nearly identical and thus allows an equal distribution of force regardless of wheel position. Taking into consideration the harsh terrain found on Mars this type of suspension system provides a better alternative to that of the common 4-wheel drive soft suspensions found on most automobiles.

Figure 1: View of Differential Gearbox System without Box


Design enhancements:

For our project, since we are mainly building upon the design of previous semesters, we can utilize the things they did correctly and build upon things they may have overlooked. The main design difference, as it pertains to the suspension system, is the addition of a differential gear box. Whereas previous semesters utilized a barely functioning differential bar, or no differential at all, this semester we decided to remove the bar entirely and replace it with a much more functional differential gear box. This addition of a differential gear box will offset the wheel assemblies by about .8 Inches on each side and raise the main platform about .38 inches higher from the ground. Upon further research of rover suspension systems our group discovered a helpful blog on a website called Beatty Robotics. The website provides many helpful blogs describing the design and creation process for many custom Mars rovers and other robots. The particular blog post that helped us meet our needs pertained to a differential system used for a custom Spirit II Mars rover. Feedback on the blog pertaining to the parts used lead us to the website McMaster-Carr where we were able to order the parts to assemble our own Differential.


Suspension- Wheel Assembly:

Figure 2: Wheel Assembly

The wheel assemblies contain a total of 6 wheels with a symmetric build for both sides. Each side contains 3 wheels which are connected to each other by two links. The main linkage called the rocker has two joints, one affixed to an axel forming the differential mechanism and the other connected to the remaining two wheels. This linkage from the rocker to the other linkage between the two wheels is known as a bogie (hence the name rocker bogie). To go over an obstacle, the front wheel is forced against the obstacle by the center and rear wheels. The rotation of the front wheel then lifts the front of the vehicle up and over the obstacle. The middle wheel is then pressed and pulled against the obstacle by the rear and front wheels respectively until the wheel is lifted up and over the obstacle. Finally, the rear wheel is pulled over the obstacle by the front two wheels.


Suspension- Differential Gear Box:

Figure 3: Differential Gear Mechanism Close-up

The differential is composed of three identical beveled gears situated 90-degrees from each other at the center of the rover. Each gear is affixed to a 6-inch steel drive shaft that is mounted to the rover body by 2 mounted sleeve bearings. One gear connected to the left, one gear connected to the right, and the last gear assembled onto the main platform. The two rods facing opposite of each other on the left and right of the robot help serve as axels for the wheel assemblies. The axils are connected to the wheel assemblies by 2 parallel aluminum tubes that make up the rocker bogie suspension system. The inclusion of this differential insures that the robot’s body and pitch angle are always adapted even if one side of the rover steps over an obstacle. If one leg goes over an obstacle, an opposite force is applied to the other leg. So, if one leg goes up, the other leg goes down. This downward force onto the opposite leg helps the robot maintain traction in the leg assembly that is still on the ground. The way this works is when one side changes in pitch, say for instance one side begins climbing over an obstacle, this mechanism rotates the main body around the rocker joints by the average rotation angle of the two sides. For this differential mechanism, all gear ratios are the same. That means if the left gear rotates 10 degrees and the right gear rotates 20 degrees, the main platform will rotate 10 + 20 = 30/2 = 15 degrees or the averaged amount. This keeps the main box more level (less tilted) than it normally would be when going over large, uneven obstacles.


References:

  1. https://www.arxterra.com/2016-pathfinder-design-and-manufacturing-rocker-bogie-suspension-system-design/
  2. https://www.arxterra.com/news-and-events/members/pathfinder/pathfinder/pathfinder-generations/pathfinder-generation-4/
  3. https://en.wikipedia.org/wiki/Rocker-bogie
  4. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.538.6955&rep=rep1&type=pdf
  5. http://beatty-robotics.com/differential-for-mars-rover/
  6. https://www.mcmaster.com/

Rules Of The Maze (Robot Avoidance Rules and Strategy)- Part 2

Written by Nornubari Kanabolo MST DM

Special Case 2.3(T-intersection) continued

As Matt explained in the previous post, for 2 robots at a T-intersection:

“In this case the robot that is within the intersection (in the middle of the T – intersection) has the lowest priority and must move out of the way of the other robots (if the other robots are in the path of the low priority robot). The lowest priority robot will step down the hallway that is not blocked and then wait for the other robot to pass.”

As for the case with 3 robots at the intersection, the following method could be used:

Say R2 steps into the intersection and R1 needs to go where R2 is and R2 needs to go where R3 is. One thing that could happen is R3 goes back to the last intersection to wait and R2 waits 5 seconds to move one square to the right.

At this point, 2 possible cases could happen. Case 1 as follows:

R1 waits 5 seconds and sees that there is no one in the intersection now then moves into the intersection, so that it can go to the hallway where R2 was. R2 waits another 7 seconds and goes down to where R1 was. R3 waits 3 seconds and returns back to where it originally was.

Or if R2 needs to go where R3 is then Case 2 is enacted as follows:

Since there are no longer 3 robots at the intersection and it is now just 2 at an intersection, the rules for encounters 2.3 as stated by Matt are used.

Training on Arxterra 3DoT App RC Mode

Written By: Muhannad Al Mohamed (E&C DM)

Table of Contents

Objective

The Arxterra 3DoT App training had a goal of teaching E&C and MST members how to use their phones to communicate with their projects through Remote Control Mode. The ArxRobot Application has two different modes of communication with the Robot’s Microcontroller. The Remote Control Mode (covered in this training) and the Community mode (Covered in the next training session). The user, through the ArxRobot App, should be able to send commands to the microcontroller either through predefined commands or custom made ones.

Introduction

The communication in the RC mode is done wirelessly through Bluetooth with an easy pairing process at the initialization of the RC mode. Commands are sent to the microcontroller as packets that consist of bytes that have specific identifiers to indicates whether the command is a command or telemetry. The packets contain data bytes that can be processed by the pre-coded microcontroller.

User’s Interface

The user interface in the RC mode is user-friendly. The default setting shows the controls of two motors in a strip type command. The strip can be changed to a D-pad looking control. Custom commands can be set to show on the user’s interface when enabled.

During the training session, members were taught how to use the user interface to control motors by giving specific input, moving motors at the same time, and steering trim to maintain desired speeds.

ArxRobot App’s Settings

The commands used in the app can be changed in the settings of the app. To access the predefined and custom commands users needed to be in Developer Mode.

The Phone Configuration window in the setting enables the user to choose the way to connect to 3DoT board, show phone’s battery percentage on Control Panel, and flip Camera’s position.

The predefined commands are commands and telemetry functions defined by the Robot3DoTBoard and saved in the app as default commands to operate a Mar’s Rover. These commands, if needed, can be used by the user by enabling each command in the Robot Capabilities configuration.

The Custom Command & Telemetry Configuration window allows the user to create new commands to be sent the 3DoT Board and receive Telemetry from it.

      

Custom Commands & Telemetry

Options for commands and telemetry is created by adding an option and giving it a specific address from (0x40) to (0x5F). Each option should be chosen to be either for commands to be sent to the 3DoT or Telemetry to be sent by the 3DoT. Commands can be controlled by the ArxRobot App; however, not all telemetry options are shown on the app. Each option should be enabled to show in either RC mode or Community Mode.

   

There are 7 options the user can choose while creating a custom command:

1- Boolean:

This option enables the user to send a byte in the data packet to the 3DoT board with a value of either (0x00) or (0x01). In the user’s interface, it can be seen as a switch that can be changed. The user can choose a default value of either of the previous options. This option can be used to turn an LED on and off for example.

2- Select:

This option enables the user to have multiple outputs to switch to. It is similar to the Boolean switch; however, it can have as many options the user wants to switch into. It sends a 1 byte of data parameter with the packet that is sent to 3DoT board; however, the values sent can be modified by the user. The select option shows in the user’s interface as radio buttons.

3- Byte:

This option can be used to send a byte in the data packet but with a wide range that can be changed by the user. It has a default range from -127 to 128 where the user can control which value sent by moving a strip in the user’s interface. These values can be changed by the user in the Byte settings to the desired range but it would still be a byte range. The steps between each value can be modified as well. This option can be used to move a servo motor for example.

4- Unsigned Byte:

This option is similar to the Byte command. The only difference would be the default range that starts from 0 up to 255.

5- Short:

This option is also similar to the Byte/Unsigned Byte; however, this option sends two bytes in data packet. Because it sends two bytes, the short command has a wider range than Byte/Unsigned Byte. The default value of this options ranges from -32768 to 32767.

6- Unsigned Byte:

This option is similar to the short option; however, the default range for it goes from 0 to 65535.

7- Header/Separator:

This option does not send any data in packets sent to the 3DoT; however, it is used to make the interface more user-friendly. titles to commands can be given using this option and it can be used to as separator if it was used without writing anything to it.

Training document

Arxterra RC Mode training document can found at this link.

Optimizing RC Mode in Projects

Update: 12/5/2017

Room Showing Telemetry Command

By creating custom commands and telemetry, engineers can create commands that can enable them to control their projects through the maze. For example, the path taken by a robot can be sent back to the phone connected to the MCU using telemetry options to show which room the robot is in on the phone’s display using RC mode. By optimizing the translated code from EE346/EE444 written by Mark Huffman (Goliath Project Manager) and Matt Shellhammer (ModWheels E&C Engineer), the variable “room” value can be sent as telemetry to the ArxRobot app. In the ArxRobot app, a telemetry Select command should be created and called room where it shows the byte value on the phone.

Creating Telemetry command called Room

Selec command Room

Assigned options to show the room type as implemented from the maze

Room type is shown in RC mode interface

Phase Selecting Command

The same process can be implemented to apply choosing the phase each robot is taking. In her blog Mission Definition, Elizabeth Nguyen (Pete-Bot Project Manager) explained how there are four planned phases each project can take:

  • Phase 1: Record
  • Phase 2a: individual playback
  • phase 2b: 4 Robots, 1 maze
  • Phase 2c: Individual playback, predefined

This custom command can be applied by also creating a select command with the four options where the user can switch easily between phases.

Phase selection in RC Mode

Recording Phase

Whenever Phase 1: Record is selected, the robot should start saving its path in the EEPROM. The EEPROM library can be very useful to record data when the system shuts down, which is essential in keeping data. The process of saving the path the robot is taking is explained in Write to EEPROM blog written by Matt Shellhammer (ModWheels E&C Engineer).

Generic Color Sensor Hedge follower PCB Layout

Written by Charles Banuelos

 

The PCB design below is for a generic hedge following shield. The PCB is a work in progress with the finalizing of the dimension dependent upon the testing of the color sensors. The LEDs chosen are significantly larger than the previous design and this is due to availability.

 

 

Update 11/30/2017

The PCB design was finalized and sent to OSH Park to be fabricated. The color sensors are placed 5.48 mm away from the edge of the board. The LEDs are placed 5.64 mm horizontally away from the color sensor towards the center of the board. The LEDs were changed due to availability as well as the issues with size. The orginal LED was too large and suitable replacement with similar specs was found. The final board dimensions are 10.87 mm wide by 55 mm long. The color sensors are placed 40.41 mm apart. The final draft of the PCB has the caster wheel cut out for 3DoT chassis as well.  The boards were received on 11/21/2017 and are currently being assembled.

Board 

schematics 

Parts List

Update 12/12/2017

This design was able to work for only one of the color sensors on one of the boards. The other color sensor was intermittent. This lead me to believe that the problem is in the soldering. The fabrication portion of this designed was plagued with many problems. The color sensor pads themselves are extremely small so when placed on the solder paste by hand the sensor would move and create bridges. The only way to mitigate this is to use the pick and place machine to ensure proper placement. The another issue found was that when a board was trying to be fixed with a heat gun the parts would burn before the solder would melt. This to could also be fixed by using the pick and place to ensure proper placement the first time. The last issue was with the stencil. The stencil would get clogged on the color sensor holes due to that fact they were very small. The only option to mitigate this is clean the stencil thoroughly after each use as well as use flux to ensure solder is in the right place.

Generic Color Sensor Schematic

Written by Charles Banuelos  MFG DM-updated 11/29/2017

The schematic below is for a hedge following shield that will connect directly to the 3DoT board. The hedge following shield will connect to the 3DoT board using the same 6 pin header that is used for the 3DoT IR shield. The design follows Thomas Forman’s designs from EE444. The color sensor being used is the BH1745NUC-E2CT-ND color sensor because this color sensor allows for two different I2C addresses to be used.  The hardware is designed to have the I2C addresses (0x038) and (0x39) in HEX. The LEDs chosen were chosen due to the fact that they were able to fulfill the specs needed such as light transmission, package size and current. The LEDs are used to light up the areas for the color sensors to detect the hedges. The mosfet in the schematics is used to control the LEDs which are protected by resistors. There are protection 10k resistors placed at the address pins to ensure protection of the color sensor.

Update 12/7/2017

The schematics below do not contain any form of reverse polarity protection. It should be stated then that when inserting the PCB in the 3DoT header that the orientation should be carefully monitored as to not accidentally flip power and ground. This could cause catastrophic damage to the circuit. It should also be noted that future color sensors should include a diode on the power line right after the header to protect from this. This design chose not to go with this at the time due dimension requirements of the PCB.

 

Spring 2017 Final Blog Post – Pick and Place

Belinda Vivas (Project Manager)

Tyler Jones (Manufacturing)

Kevin Ruelas (Electronics)

By: Chastin Realubit (MST)

Table of Contents

Executive Summary

Program Objective

By: Belinda Vivas (Project Manager)

The objective of the Second Generation of the Pick and Place is to:

❖Build up from the First Generation of the Pick and Place machine and create an user friendly design.

❖Create a user friendly manual:

  • Softwares
  • Step by Step
  • Wiring
  • Troubleshooting

❖It shall be built in stages.

❖Make the Pick and Place consistent with the manufacturer of only a few boards per semester.

Mission Profile

By: Belinda Vivas

The mission plan for the Second Generation Pick and Place is to place all components used for the 3Dot Board 4.54 faster than a person. Manufacturing time of a person is 4 hours, so anything less than that is acceptable, with 1 hour being the target time.

The overall goal of this project is to have a working Pick and Place machine for future EE400D students to build their custom PCB. The 3Dot Board that will be constructed is more difficult than any PCB students will make, therefore, this machine can theoretically make any board future students plan to do.

Because this machine is supposed to be used by students, we will include manuals (written and video) so that future generations can operate this machine with ease. We will conduct experiments using Electrical Engineering students to see if they can operate the machine using only the given manuals.

The overall summary for the Mission Profile is:

❖To create a 3-Dot 4_54 PC Board.

❖Ensure precision and calibration through the addition of a camera system (Edge Detection).

❖Create a CSV file to implement a better interface between the user and the machine.

❖Multiple feeder assemblies

❖Incorporate better materials

❖Tape feeder for the following component parts:

  • 0402
  • 0603
  • 0805

Design

Project Features

By: Belinda Vivas (Project Manager)

Figure 1 – Detailed Design of Generation 2

Electronics:

❖Camera System

  • Edge Detection

❖Two Arduinos System

  • Independent from each other

❖Vacuum System

❖Servos System

❖Power Emergency Switch

  • Relay to cut power on the motors

Manufacturing:

❖Higher legs with rubber on the base to provide better stability due that more weight is being added causing for higher vibration.

❖Higher amount of component feeders.

❖IC Chip component holder

❖Power Switch

❖Camera

❖Component Cabinet

❖Electronics Cabinet

❖Tape waste bin

System Design

By: Chastin Realubit (MST)

Figure 2 – System Block Diagram

Testing

Solenoid and Vacuum Test

By: Tyler Jones (Manufacturing)

The vacuum by itself was powerful enough to carry the Atmega chip but experiments show that we need a bigger nozzle to increase airflow.

Figure 3 – Solenoid Circuit

Blog Post: https://www.arxterra.com/pick-and-place-solenoid-valve-design-and-control-2/

Z-Axis Test

By: Chastin Realubit (MST)

Z-Axis Motor: We did an experiment to see the load that the Z-Axis can handle and we found that it will still carry up to 2000 g. This experiment was done so that we can see if the motor can still move up and down even with more load. This was needed because we are adding a camera on the Z-Axis and we needed the system to still function with extra weight.

Figure 4 – Nozzle System

Blog Post: https://www.arxterra.com/pick-and-place-z-axis-and-nozzle-test/

Rubber Vibration Damping Test

By: Tyler Jones (Manufacturing)

-The machine has a basic feature of rubber shoes for legs of the platform stand.

-This will aid in damping vibrational disturbances.

-A 4” x 4” x 1” block of butyl rubber shaped using a bandsaw and miter saw.

-The block was fitted to form shoes that fit over the legs of the machine.

-The blocks have been tested on one leg for stability.

-The use of a milling router machine should be used

Additional Testing

Emergency Power Switch: https://www.arxterra.com/pick-and-place-emergency-power-switch/

By: Tyler Jones (Manufacturing)

3Dot IC Tray:https://www.arxterra.com/pick-and-place-3dot-ic-tray/

By: Tyler Jones (Manufacturing)

12 Servo Mount & Tape Feeder System:https://www.arxterra.com/pick-and-place-12-servo-mount-tape-feeder-system/

By: Tyler Jones (Manufacturing) and Belinda Vivas (Project Manager)

Camera Test: https://www.arxterra.com/pick-and-place-camera-test/

By: Kevin Ruelas (Electronics)

Solenoid Valve Design and Control:

By: Tyler Jones (Manufacturing) and Kevin Ruelas (Electronics)

Servo Driver: https://www.arxterra.com/pick-and-place-servo-driver/

By: Kevin Ruelas (Electronics)

Camera System: https://www.arxterra.com/pick-and-place-trade-off-study-camera-system/

By: Kevin Ruelas (Electronics)

User Interface

GRemote

By: Kevin Ruelas (Electronics)

Though the user can type commands manually in the GRemote, once the machine is running and calibrated, use command G28 to set the origin then send the CNC file and wait for the machine to do the rest.

Figure 7 – GRemote controller

Figure 8 – GCode Commands

Figure 9 – Arduino 1 Interface Definitions

Figure 10 – Eagle CAD to Pick and Place

Camera Fritzing Diagram

By: Kevin Ruelas (Electronics)

Figure 11 – Camera Fritzing Diagram

Recalibration of Origin

By: Kevin Ruelas (Electronics)

Since the 1st Gen. already defined the origin, the edge detection of a “target” will be used to calibrate this location and prompt the user to make this correction via GRemote.

Electronics Design

By: Kevin Ruelas (Electronics)

The overall Pick and Place was composed of various subsystems which were all ran by a common code. The motors, the nozzle, calibration, camera, LCD display, servo driver, and solenoid.

Figure 12 – High Level Software

Blog Post: https://drive.google.com/open?id=0B9iWYCBTJWEEeEFxc1pjU0ZFTjQ

SolidWorks Model

By: Tyler Jones (Manufacturing)

Figure 13 – Side View of SolidWork Design

Figure 14 – SolidWorks Top View Design

Verification and Validation Test

By: Chastin Realubit (MST)

The purpose of this section is to provide a comprehensive Verification and Validation (V&V) Test Plan of the Spring 2017 Pick and Place including the Project ConOps/Mission, Test Methodology, Verification and Validation Matricies, Test Cases, and Exit Criteria.

https://drive.google.com/open?id=0B9iWYCBTJWEEU05NMy1SMUs2ajQ

Resource Allocations

Power Allocation

By: Chastin Realubit (MST)

Components Expected Current Draw (A) Uncertainty (%) Margin (±A) Measured Current Draw(A)
Stepper Motor (X-Axis) 1.35 5% .0675 .44
Stepper Motor (Y-Axis) 1.35 5% .0675 .44
Stepper Motor (Z-Axis) 1.35 5% .0675 2.83
Stepper Motor (A-Axis) 1.35 5% .0675 .44
Detection Camera .75 5% .0375 TBA
Solenoid Valve .40 5% .02 .42
Display Screen .75 5% .0375 TBA
Servo fs90r (12) .2 5% .01 .21
Project Allocation 6 A (Calculated knowing that we will be using two Arduinos with separate power supplies)
Total Expected Current 3.45 A (The motors and servos will not run simultaneously)
Total Margin .375 A
Contingency 2.175 A

 

Mass Allocation

By: Chastin Realubit (MST)

Vacuum System Components Preliminary Mass (g) Uncertainty (%) Margin (±g) Expected Mass (g) Actual Mass (g)
Stepper Motor (A-Axis) 245.00 5% 12.25 245.00 247
Stepper Motor (Z-Axis) 245.00 5% 12.25 245.00 246
Vacuum Nozzle 2 5% .1 2 TBA
Z-Axis Actuator 292.00 5% 14.6 300 244.12
Detection Camera 3 5% .15 3 TBA
Project Allocation .Preliminary allocation is 2000g
Total Expected Mass 795 g
Total Margin 39.35 g
Total Actual Mass TBA
Contingency  1165.65 g

Cost Report

By: Belinda Vivas (Project Manager)

For the Second Generation of the Pick and Place, our allotted project budget was of $500, in which a total of $469.04 was spent; it was divided as follow:

Receipt Vendor                Item            Unit Quantity Total Cost (Including Shipping) Purchased By
1 Makeblock RJ25 Adapter $4.98 1 $15.65 Kevin Ruelas
RJ25 cable-20cm (4-pack) 1
2 Amazon 12 Bit PWM Servo Driver $11.99 1 $11.99 Kevin Ruelas
3 Amazon Blue Backlight LCD Module $7.99 1 $7.99 Kevin Ruelas
4 Amazon 3-Pin Extension Lead Wire $6.99 1 $6.99 Kevin Ruelas
5 Amazon Arduino Power Supply Adapter $6.29 1 $6.29 Kevin Ruelas
6 Amazon 120 pcs Dupont Wire $8.86 1 $8.86 Kevin Ruelas
7 This item was removed. Arduino Uno will not be needed for the project anymore and the student requested to keep the board.
8 AdaFruit MicroSD Card $7.50 1 $52.56 Kevin Ruelas
JPEG Camera $35.95 1
9 Pololu Rotation Servo $4.95 9 $49.50 Chastin Realubit
10 GearBest LCD Display Screen $4.53 1 $17.18 Chastin Realubit
11 Amazon PWM Servo Driver $11.99 1 $15.98 Chastin Realubit
12 Ebay Rubber Bench Block $7.48 1 $7.48 Tyler Jones
13 Sewvac LTD Bobbins for Servos $3.29 1 $3.29 Tyler Jones
14 RadioShack Mosfet IRF 510 $1.78 1 $1.78 Tyler Jones
15 ACE Hardware Nuts & Bolts $5.40 1 $5.93 Tyler Jones
16 The Home Depot Wood $29.98 1 $29.98 Tyler Jones
17 The Home Depot Aluminum Plates & Epoxy $35.68 1 $38.45 Tyler Jones
18 MicroCenter 3D Printer Filament $14.99 1 $16.15 Tyler Jones
19 The Home Depot Screws $18.49 1 $18.49 Tyler Jones
20 The Home Depot Plastic Sheet $140.06 1 $140.06 Tyler Jones
21 ACE Hardware Screws $14.44 1 $14.44 Tyler Jones
Total: $469.04  
Name of Individual Position Total Amount Reimbursed
Kevin Ruelas Electronics $110.33
Chastin Realubit MST $82.66
Tyler Jones Manufacturing $276.05
Total** $469.04

Updated Schedule

Top Level Schedule

By: Belinda Vivas (Project Manager)

 

Sub System Schedule

By: Belinda Vivas (Project Manager)

Concluding Thoughts

By: Belinda Vivas (Project Manager) and Tyler Jones (Manufacturing)

We were able to incorporate more extensive and higher technology subsystems into the Second Generation of the Pick and Place; by implementing a more user friendlier systems and introducing a camera system, LCD Display system, redesign of the nozzle, better calibration system, higher servo driver system, and an overall new manufacturing design.

The pick and place was successful in picking and placing parts onto the 3DoT board. The machine when calibrated can place parts into the respective locations where they can be soldered using the IR reflow machine. It is important however to note that the pick and place machine can be improved in the following areas. Its mechanical, and electronic design can be updated with simple solutions that require more time. They are discussed below.

The pick and place mechanical design can be improved in a noticeable and easily recognizable ways with more time for development. The first is the belt system.

1) The belt system does work well, and the X and Y stepper motors move to positions accurately, sometimes during design of the machine the tensioner plates that hold the 3 belts into place were loosened. This is so that parts in the machine can be easily worked on. Therefore it is important to make sure that belts are tight, as well as lubricated. Loose belts cause the machine to make a noticeable sound that is not as fluid as when they are tight. The best solution would be to incorporate threaded drives instead of belts, however this is more costly.

 

2) The pick and place uses a 3DoT board that was 3D printed with more than 6 iterations. This was due to numerous errors in the printing temperature, malfunction, and design limitations. There is a table that corresponds to part sizes and dimensions and adjustments made to account for error of the 3D print. It is found here, 3DoT IC Tray. A decent 3D printer and filament must be used in order to get the precise dimensions necessary. An alternative solution would be to cut a small rectangular piece of plastic that is about 0.5-0.75 inches thick, and have it precisely laser cut. The laser cutter used in the design center was not accessible in this generation later on in the project timeline.
3) The Z-axis is supported by two aluminium slider rods. These slider rods must be spaced as far apart as possible so that the heavier Z-Axis can have a wider more stable base and center of gravity. This design was used in the pick and place and must be incorporated if further design iterations will be made. The camera is mounted on a bracket that allows makes it so that the Z-Axis only can be bolted to two of the aluminium sliders. This must be made able to be bolted into all four of the sliders. It is shown below

4) The pick and place currently uses a locked position origin. This is so that the the machine can be turned off and moved back to the locked position manually. From here the pick and place machine can be moved to the function “L” bracket origin. It would be a much safer design if limit switch can be placed on the X and Y axis so that if the user were to accidentally enter the wrong code in the machine the motors would not grind. This can be accomplished by using the current limit switches and adding the limit switch code to the stepper motor.ino Arduino code. The limit switch acts as an electromechanical disconnect that simply switches off the stepper motors when the machine makes contact with the switches. An image of the switch is shown below.

5) The electronic design can be further enhanced if the 12 channel servo driver can be made to separate the digital power source which carries Arduino logic level signals of +3.7V and +5.0V, and the analog power source which carries +12V signals. The connection is made through the Me Uno RJ25 board. This connects an an RJ 25 communications signal with a 12 V analog signal.
6) The edge detection camera code was functional and the code calculated the position of the origin by comparing picture taken by the camera, and comparing the pixel lengths. The edge detection however was off by about 0.3 which is about 1mm in actual length. In order to improve the accuracy of the machine a higher resolution camera must be used.

Project Resources

Video – https://www.youtube.com/watch?v=2Cn5abf5Arw

Preliminary Design Document – https://www.arxterra.com/pick-and-place-preliminary-design-document/

Preliminary Project Plan – https://www.arxterra.com/pick-and-place-preliminary-project-plan/

PDR: https://drive.google.com/open?id=0B9iWYCBTJWEES1g1emo3NklpTmc

CDR: https://drive.google.com/open?id=1tGSSGGry0n6I4EDJ9IYzM1PXZUMOc_jJTCyYj9YSV1E

Blog Posts: https://drive.google.com/open?id=0B0hJ_mPvve6CRVpqOU1mdUN2aFk

Code Files: https://drive.google.com/open?id=0B0hJ_mPvve6CY0t5SjNuWk1OOEk

3Dot BOM: https://drive.google.com/open?id=1rC5BPWV3KqwXsGQ3CgFeVNoKTumOvdZjCftwd7t0eEU

Servos BOM: https://drive.google.com/open?id=0B7gruONfGRYcUExJeVBxMzNYblU

GCode Commands: https://drive.google.com/open?id=1CKODeCrm8FpmgrmSp363mjAMPNYaCCe5904dLSit4cs

3Dot 3D print File: https://drive.google.com/open?id=0B0hJ_mPvve6CNXVTQVNyVGxCT3c

3Dot Board: https://drive.google.com/open?id=0B0hJ_mPvve6CN25OSU01aEcwWlE

https://drive.google.com/open?id=0B0hJ_mPvve6CN2dIZHZXTzAtSWs

Ace Converter: https://drive.google.com/open?id=0B0hJ_mPvve6CTlI1NzNHX1BTLTQ

Arduino: https://drive.google.com/open?id=0B0hJ_mPvve6Ca1BpM3FGNDYzWVE

GCode: https://drive.google.com/open?id=0B0hJ_mPvve6CM2pNZ2hCWl9ZMXc

Me Uno Shield: https://drive.google.com/open?id=0B0hJ_mPvve6CUmtDcEN5LUxQSjg

Meeting Minutes: https://drive.google.com/open?id=0B0hJ_mPvve6CNXRhRFd5RThkR1k

Research: https://drive.google.com/open?id=0B0hJ_mPvve6CeS1tQmFRQ3hqQ3c

SolidWorks Files: https://drive.google.com/open?id=0B0hJ_mPvve6CaFVoR1RaRl93bkE

XY-Plotter: https://drive.google.com/open?id=0B0hJ_mPvve6CckVuWkJvOU53eEE

All Files: https://drive.google.com/open?id=0B0hJ_mPvve6CNXVTQVNyVGxCT3c

Instructional Manual: https://drive.google.com/open?id=1eXx-_8FduTJi8nRR356R3nj0DHnTqq50er3VYreTGXA

Project Libre Schedule: https://drive.google.com/open?id=0B9iWYCBTJWEET2pLMHVJVVd2am8

Verification and Validation: https://drive.google.com/open?id=0B9iWYCBTJWEEU05NMy1SMUs2ajQ

 

 

 

Fall 2016 Solar Panels: The Solar Panel Sandwich (the “Encapsulation”)

By Ridwan Maassarani (Design and Manufacturing)

Approved by Inna Echual (Project Manager)

Table of Contents

Introduction

In order to secure the cells onto the panel, one must consider the way of “sandwiching” the cells onto place. A rubber substrate was used for insulating the solar cells from the aluminum sheet. Here, I will review the “sandwich” method of encapsulation.

PV Back Sheet [1]

The first substrate considered was PV Back Sheet, which can be bought from aliexpress. This could reduce the thickness of the overall layers and, as explained by Dunmore, a supplier of solar panel material, “the PV back sheet is a photovoltaic laminate that protects the PV module from UV, moisture and weather while acting as an electrical insulator. DUN-SOLAR™ PV back sheets are available in a variety of constructions for both traditional rigid PV modules, like the one shown above, as well as thin film PV modules and solar power concentrators.”

EVA Layer [1][2]

Next, there’s the EVA layer, and according to Dunmore is a “thermoplastic containing ethylene vinyl acetate which is used to encapsulate the photovoltaic cells.” EVA encapsulation might not be the way to go since it needs to be heated which renders the cells inaccessible. And the cells need to be serviceable as part of our project requirement. For our panels, I took a couple of sticker paper and laser cut individual square cut outs to place each cells in its cavity and then when the acrylic is attached, there would be not visual gap between the cells and the acrylic. This did not work since I did not make my sticker paper thick enough. I modeled the shape I needed using Solidworks to ensure every cell in our current design had a cavity to sit in. Then I generated the dxf file that would then be used by the laser machine to cut the sticker paper, as shown in Figure 1.

sticker

Figure 1: Sticker Paper

Then comes the EPE insulations which is an extra layer of insulation, protecting the PV cells from being damaged from additional voltage seeping into the cells and damaging them.

Finally, there’s glass, which was substituted with acrylic in our final product which based on a PDF document written by Arkema, a leading specialty chemicals and advanced materials company says that it transmits 92% of the suns light striking it at the perpendicular.

The entire sandwiching process can be seen in Figure 2.

sandwich

Figure 2: Sandwich Process

References

[1] Solar Back Sheet: http://www.dunmore.com/products/solar-back-sheet.html

[2] Eva Film: http://sinovoltaics.com/learning-center/materials/ethylene-vinyl-acetate-eva-film-composition-and-application/

[3] Plexiglass: http://www.plexiglas.com/export/sites/plexiglas/.content/medias/downloads/sheet-docs/plexiglas-optical-and-transmission-characteristics.pdf

Spring 2016 3DoT Goliath Final Project Document

 

By: Ayman Aljohani ( Project Manager)

Team members:

Ayman Aljohani (Project Manager)

Tae Lee ( Mission and Systems Engineer)

Kevin Moran (Electronics and control Engineer)

Jerry Lui (Manufacturing Engineer)

Table of Contents

Executive Summary

Objective

The objective of the 3DOT Goliath is to design a small-scaled version of the Goliath Tank, as a toy, that meets the following

requirements: Safe: uses IR transmitter and receiver. Less than 6 hours printing time. Piloted via live cam on an Android phone. Low cost: should not exceed $80 total. Controlled by 3DOT board. Looks cool and inspired by the Goliath Tank. Periscope must be attached to an Android phone laying horizontally zero degree with the x-axis.

 

Mission Profile

The mission profile of this project is to play a “laser-tag” battle with the 3DOT Spider. Every hit will require a 5 second delay in between to avoid multiple tags.  With each hit the buzzer will make a sound to indicate that it got hit.  After receiving the third hit the robot will be disabled and play a short song afterwards.  The game will take place in a 6 ft. x 6ft area on the linoleum floor. The maximum distance for detection from the detector will be 5 ft.

 

Mission Objective Update

1

Level 1 Requirements

  • Laser tag game must be safe for children
    • Uses IR transmitter and  receiver to stimulate a game of tag
  • Less than  6 hours printing time
  • Piloted via live cam on an Android phone
  • Low cost: should not exceed  $80  total
  • Controlled by 3DOT board
  • Looks cool and inspired by the Goliath Tank
  • Periscope on an Android      phone degree with the x-axis

 

Level 2 Requirements

 

  • The rover will be controlled by two individual DC motors (3-5V)
  • Battery duration should last to the whole period of the battle 15 min
  • Controlled via Bluetooth using an Android Device
  • Print parts of rover individually
  • LED will be used for a game of laser tag
  • Laser sensors (on PCB) must be 3 inches

 

Preliminary Project Design Documentation found here

 

System Design

System Block Diagram

1

 

 

The figure below will show how each components on the Goliath will be connected and how they will interact with each other.  

 

Experimental Results

Uploading the Firmware onto the 3Dot Board

 

After assembling the 3Dot Board we need to program the ATMEL 32U4 chip by uploading a firmware.  Without the firmware we will not be able to upload any programs onto the ATMEL 32U4.  A detailed explanation will be provided by the following link:  Upload Firmware

 

Troubleshooting the 3DoT  Board

 

After assembling the 3Dot board I had to make sure that each component was soldered correctly.  In addition, testing the motor driver by uploading a program using the Arduino IDE onto the 3Dot Board.  To know more about the test procedure, check out the following link:  3Dot Board Troubleshooting

 

Arxterra Control Panel Test

 

To be able to use the Arxterra Control Panel from the website we had to perform a couple of tests.  The test is to make sure that the communication between the android Arxterra application communicates with the Arxterra control panel (1) on the computer.  To know how the test was implemented check the link:  Arxterra Control Panel Test  

 

Bluetooth Module Test

 

Before we implement the Bluetooth module onto the Arxterra Firmware we had to perform a simple test to see how the Bluetooth module functions.  The test will allow us to see the information we send from the android device using the BlueStick Control, which will than be displayed on the Arduino serial port.  The link will provide a detailed explanation of the test performed:  Bluetooth Module Test

 

 

3DoT Goliath DC motor trade-off study

In this post, it was my job to narrow down from a few DC motors to just two and do a trade-off study in order to figure out which one would work best. The motors were compared in regards to customer requirements. The motor chosen had to fit all customer requirements, including some requirements needed in order to make the project successful.

Motor trade-off study

Laser vs IR LED trade-off study

In the beginning of the semester, we began comparing two different method for meeting the project requirement of having a laser tag game. We tested both a laser and IR led with their respective receivers.  The benefits of the laser were the range and low power consumption; the problem was the safety with using lasers. The IR LED was very safety to use, unfortunately the range was very low, as the light diffused. At this point we believed the laser would make the perfect candidate for the game.

Laser vs IR trade-off study

Progression of laser tag components

In this post I explain my reasoning in the progression of the different technologies we wanted to use to make the laser tag possible. The laser and IR emitter were giving me trouble in order to design the game. Another idea was to use a visible LED and turn that into brighter light using the same idea of a flashlight. Testing proved successful as I was able to increase the range, and maintain the safety. As it would turn out, the LED light would not a viable option either, yes be ready to have your ideas rejected often, that is life.

 

Progression of Laser tag components

Making laser tag possible: The Schmitt trigger

In this post I discuss why a Schmitt trigger is needed in order to make the laser tag game successful. Since I will be using an IR emitter/receiver, the signal output is analog which is very hard to control. By using the Schmitt trigger I am able to invert this signal and convert it to a single bit digital signal output, which we are able to monitor better.

Making Laser tag possible

Making laser tag possible: The receiver

By recommendation of my division manager, for the receiver we used an infrared transistor SPH 310 (Opto-semiconductor).  In the post I include the analog voltages outputs using both Arduino plotter and monitor. You will find basic code to test the analog voltages as well as my EAGLE CAD drawing.

The Receiver

Making laser tag possible: The emitter

In this post I discuss the IR emitter, which is built by using a few resistors, an IR LED, and a 2n2222 NPN transistor. The calculation for the resistor that I have selected are provided. This emitter will be able to be controlled on/off by controlling the voltage that is sent to the base of the transistor. The EAGLE CAD schematic is also included.

The Emitter

Subsystem Design

Interface Definitions

2

3

3

 

 

 

The following table will provide the pins for the Atmega32u4 Microcontroller 3Dot Board:

Now we will narrow down the number of pins we will be using on the Atmega32u4 Microcontroller:

1

 

CUSTOM PCB DESIGN

3DoT Goliath PCB Testing

Once the PCB was assembled by manufacturing engineer, it was my job to ensure it would work. With the help of the division manager, and systems engineer we were able to determine the problem. The blog post goes through our mistake and how we solved the problem, as well as a recommendation for when you have to design your PCB.

Custom PCB Design Testing

Making Laser Tag Possible: Extending the IR Range

With the PCB working correctly, I realized that the range was around 6-8 inches. That range needed to increase in order to make a more entertaining laser tag game. With the help of a lens and an online formula I tried to concentrate the IR LED in order to increase the range. Here you will find a very helpful formula that will help you with this problem.

Extending the IR range

The PCB Layout

In this blog post you will find the process I had to go through in order to finalize the final PCB layout. From the design on Fritzing, to testing the circuit, and finally designing it on Eagle CAD. All files have been provided by Eagle CAD. Pay attention to the Phoenix 254 connectors, as well as grounding everything to ensure your circuit works.

PCB Layout

 

PCB  physical layout

For the PCB layout blog post I go detail on the methods and a few tips and tricks regarding the layout of the board and the usage of EagleCAD. The main thing to remember is the trace width guide. For boards that aren’t powering much (simple light show, 1 or 2 small motors) the trace width can be fairly thing but for anything that requires more power (over 500mA) one should consult the guide to properly determine the width otherwise it won’t be able to supply enough power.

Remember to manually layout your traces! The auto route is terrible.

PCB Physical layout

SMD Soldering

The SMD soldering blog is just quick tutorial on how to solder small IC’s and surface mount components. I’ve included a very good video on how to SMD solder using a hot air gun and soldering iron for the larger SMD components (0805 resistors, etc.)

Note: Due to an issue with embedding the video won’t play properly. Open it in another tab and you’ll be able to view it.

SMD Soldering

 

3DoT Board Fabrication:

The 3DoT Board was soldered by project manager and tested by System Engineer.

3DoT Board Fabrication

 

Hardware Design

 

Goliath Body dimensions

           

This blog was created to give a quick overview of our preliminary design and various features within Solidworks (filter types). Although this design was created before one of our manufacturing engineers had to drop the general dimensions remained the same. The body is still designed to house all of the components (3dot board or Arduino nano, battery box, motor cage, phone, etc.).

The filet options are mainly for aesthetic purposes. Instead of rounding off the corners of cutouts a conic rho profile can be used which generates a pointed, yet rounded, corner.

Preliminary Body Dimensions

 

Final body redesign

Since the manufacturing engineer that was originally tasked to create the body had to drop the course, I had to redesign the body to meet the requirements set out from the beginning of the course.

This blog just briefly goes over what to be done and what compromises were made to meet the majority of the requirements (only one requirement was not fully met at 50% -> exact replica of Goliath tank).

Final Body Design

 

SOFTWARE DESIGN

Updated Laser Tag Communication System

The new modified flow chart (shown below) will incorporate the new laser communication system.  New features  will include an automatic turn after receiving a single hit to avoid multiple hits in less than a second.  In addition, to disabling the Goliath and playing a short song after the third hit.  

The finalized flowchart  for the laser communication system for the Goliath is shown below:

 

1

 

 

 

The arduino C++ code that will be implemented in reference to the flowchart on the Goliath will be available by following the link:  Goliath-Arxterra Firmware

 

Making laser tag possible: Putting it all together

The final blog post in the sequence of making laser tag possible. Here you will find the final product of the emitter/ receiver combo. I have also included a flowchart showing exactly how our circuit will work. The circuit is to detect three different hits by an IR LED. After each hit a piezo buzzer will make a tone sound, after the third hit we play a melody and the rover is deactivated. The final code and output results are included.

Putting it all together

Arxterra Firmware Motor Control Modification Test

The 3Dot Board was not given at the time, so we had to use the Arduino Uno and the Arduino Motor Shield.  The Arxterra Firmware that was given to use had the motor controls for the Sparkfun Pro Micro with the Dual Motor Driver.  Hence, we had to make modifications to the firmware to work with the Arduino Uno and the Arduino Motor Shield.  

 

3DoT Goliath IR Emitter/Receiver Code Test

The early stages of development of the laser tag system required research and testing.  To see how IR worked we performed a basic test using IR Mid-Range Proximity Sensor (TSSP4P38) and a remote control (IR Emitter).  Follow the link to see a detailed explanation of the testing procedure for the circuit setup and the code used to test the sensor.

 

Verification and Validation Test Plans

We will perform a verification on the requirements that was discussed by the customer.  Each subsystem engineer will perform a verification test to verify that it meets level 1 and level 2 requirements.  A verification document/verification matrix are given in order to verify each requirements.  

 

In addition, a validation will be required to test the mission profile (rules of the game) by following a similar test plans as the verification.  For validation we will validate the test plans using a validation document on how to perform the test and validation matrix to check off the validated requirement.

 

Project Overview

 

WBS:

The WBS has been updated after resources allocations, one of the manufacturing engineer was assigned to work on PCB layout, and the other one was responsible for chassis design. A link to the WBS is here

 

1

 

 

 

 

Burndown Chart:

This is our final Burndown chart

Here is a link to the Burndown chart

1

 

 

Project Schedule:

The project schedule is divided into two levels, high level requirement under “planning phase”, and level 2 requirements which is broken down to tasks. Project Schedule

Here is a screenshot of the updated project schedule. The project  percent completion is 100% .

The project schedule was created on a very useful tool, Smartsheet. Here is a link to full details blog post. Smartsheet .  

 

1

Capture

 

 

 

 

Project Budgets:

One of level 1 requirements is budget. It is the project manager’s responsibility to keep track of budget, one way to do that is to have a parts request form. Any team member should fill out the request, print it out,  sign it , and get the PM approval before proceeding with any purchase. Our actual project budget is $85

Here is a link to Parts Request Form.

Here is a link to Project Budget.

Mass Budget

Power Budget

 

Concluding Thoughts:

Suggested Practice: 

As a project manager, I had to work closely with each division engineer, especially Systems Engineer. I learned a lot through this experience. In the beginning of the semester, we had to sit with customer, president, and student assistant to define level 1 requirement of the project. That  process, iteration, is a continuous process in which a project manager verifies the customer’s requirements and provides options. The Goliath mission was to battle 3DoT Spider, thus it is important that both team work closely to define game rules and communications means between two robots. Also, another important thing is beam-width of IR, in our project we used IR, should be the same for a laser-tag game to be fun. The customer requirements will be very simple in terms of wording, but project manager and team should critically think of being creative thinking out of the box.

For a project to be completed in a timely manner, the team has to meet at least twice a week, one during regular class time, and another during the week. We had to meet three times a week to complete our project, twice on campus and once online. Communication between team member is highly important, so from the first meeting we decided to use Google Hangout app to communicate with each other.

Lesson Learned: 

Preliminary Design Review, and Critical Design Review should have  detailed information about the project. Project Manager should start preparing for CDR and PDR two weeks before the deadline.

Project video is a useful tool to promote the project, thus it is advised that Project Manager plan the video from the beginning of the semester by recording clips of the engineering method followed toward the final product.  

Smartsheet was a powerful project management tool that helped me easily managed my team. At the same time, it is good platform for communication between team members to have discussions about certain task assignment or requirement clarification. I strongly encourage project managers to use it, here is some information about it.   

Blog post is a good way to pass the knowledge to successors, therefore I encourage all team members to post on Arxterra regularly.  

After all, this was a challenging experience that expanded my understanding of real world engineering problems.

 

Resources

  1. Project Video
  2. CDR Presentation for Goliath  (Prezi)
  3. PDR Presentation for Goliath
  4. Project Schedule on Smartsheet 
    1. Project Burndown
    2. Project Schedule on Google Spreadsheet
  5. Verification and Validation documents
  6. Solidworks Chassis File for Goliath
  7. Fritzing Files for Goliath
  8. EagleCAD Custom PCB Files for Goliath
  9. Burndown Excel File
  10. Arduino and/or C++ Code
  11. BOM
  12. Other Files (Parts Purchase Request) , Team Members Evaluation Rubric 

 

Spring 2016: 3DoT David Software Design

BY: Christopher Hirunthanakorn (Missions, Systems and Test Engineer)

Introduction:

The purpose of this blog post is to summarize all of the work that has been done for the software design of the 3DoT David and inform the reader of the final state of the software. It will cover the software flow chart to introduce the tasks the software has to accomplish and then explain the different modules in the software block diagram. Finally, a brief overview of how each module works in the final version of the code will be provided.

Related Level 2 Requirement:

  • The 3DoT David shall be controlled by the Arxterra App used on a smartphone.

Table of Contents

Software Flow Chart


CDR Software Flow Chart

The software flow chart shown here shows what the modified Arxterra firmware that will be programmed to the 3DoT board will do. The program will start by initializing all pins and variables used such as the pins for the Sparkfun Dual Motor Driver TB6612FNG, the IR emitter, IR detector, and speaker. Next, it will check to see if a command is sent via bluetooth from the ArxRobot App. If a command was sent, the commandDecoder and commandHandler functions will be executed and the action related to the command sent will be done. When no command is detected, the program will check if the IR detector has registered a tag from an opposing robot. If it is tagged, a sound will be made and the tag counter will be incremented. When the tag counter reaches three, a song will play, the robot will be disabled for 10 seconds, and the tag counter will reset before the loop continues. If there was no tag detected, the program will send any telemetry data that is required. Currently, there was no requirement for the 3DoT David to send any telemetry back to the ArxRobot App.

Software Block Diagram

CDR Software Block Diagram(1)(1)

The software block diagram shown here explains what the different modules do and the types of inputs/outputs of each module. The modules are the commandDecoder, commandHandler, Move Robot, Motor Phase Control, IR Emitter On, Tag Tracker, Robot Disabled, and Telemetry.

CommandDecoder Module

For the commandDecoder module, the input is the command data that comes from the ArxRobot App through bluetooth. This data is sent one byte at a time and the commandDecoder module saves this data into an array. Once the entire array is received, this module verifies that all of the data was sent correctly using a state machine and that the command ID matches one of the defined commands. It outputs this array for other modules to use.

CommandHandler Module

For the commandHandler module, the input is the data array containing the command information sent from the ArxRobot App. This module will check the command ID from the array and then execute the corresponding functions for that command. Those functions must be defined individually. If there are any custom commands that need to be added, a corresponding if statement is required to modify the commandHandler module to handle that command ID. There are no outputs from this module.

Move Robot Module

For the Move Robot Module, the input is the command data that comes from the ArxRobot App through bluetooth. This module includes all of the functions required to move the 3DoT David and is only executed when the move command is sent from the app. It uses the functions defined in the sparkfun_TB6612FNG.ino file and a custom function that operates the motors based on the direction of the move command that was sent. The outputs of this module are the control signals for the Sparkfun dual motor driver and the PWM values for the motor speed, which are designated as digital pins PB5, PB6, PC6, PD7, PF5, PF6, and PF7.

Motor Phase Control Module

For the Motor Phase Control module, the inputs are the current outputs from the flexible resistor sensors. This module processes those inputs using the code that was provided by the Electronics & Control Division Manager Jeffery Cool. It will compare the two inputs and determine if one of the motors is moving faster than the other. This works because the two inputs will be equal if the motors are in phase. The module will make the two motors in phase by changing the speed of the motors. The output of this module are the PWM values for the motors.

This module was tested and had a slight improvement to the movement of the 3DoT David but it was determined that it was not necessary. It is not implemented in the final version of the firmware because of the limited number of pins that are readily available on the 3DoT Board.

IR Emitter On Module

For the IR Emitter On module, there are no inputs. It will only be called by the commandHandler module when the correct command is received. The purpose of this module is to send the command signal to turn on the IR emitter and attempt to tag the opposing robot. It is not always on and will only be turned on when the correct command is received. The module outputs the control signal to the digital pin PD1.

Tag Tracker Module

For the Tag Tracker module, the input is the current output from the IR detector. If the signal that is being detected at the digital pin PD0 is low, that means a tag has not been detected. When the signal is high, this module will increment the tag counter which starts at zero. After the tag counter reaches three, this module will call the Robot Disabled module and then reset the tag counter to zero. This module will also create a 5 second delay before it checks the output from the IR detector to prevent consecutive tags. There are no outputs from this module.

Robot Disabled Module

For the Robot Disabled module, there are no inputs. When it is called by the tag tracker module, this module will prevent the robot from responding to any commands for 10 seconds and play a short song to indicate that the 3DoT David is disabled. There are no outputs from this module.

Telemetry Module

For the Telemetry module, the inputs will vary depending on what type of telemetry needs to be sent back to the ArxRobot App. This module will collect the current values from the sensors on the robot and send that information back to the app. It should be called at a maximum frequency of 1 Hz in order to prevent data overload. The output of this module will be a data array that is sent via bluetooth. For the 3DoT David, there was no telemetry that was required.

Implementation of modules

For the Move Robot module, the existing code was designed for operating a rover and needed to be modified to fit our robot’s movement system. With the new movement system design, both motors will need to be controlled at the same time in order to move because each motor is driving one set of three legs. Additionally, the smoothest movement of the legs required the PWM value to be set to the maximum of 255. If it was any less, the motion of the 3DoT David would look very slow and feel weird. Because of the way the ArxRobot App is set up, the user has to press and hold the direction button to increase the speed of the motors to move in that direction. The code was changed so that the PWM value would be a constant 255 and that the leg movements would be fluid.

For the IR Emitter On module, it was decided that the IR emitter will be turned on whenever the 3DoT David is moving and is off the rest of the time. This is because the ArxRobot App can only send one command at a time and the alternative method of controlling the IR emitter would be using a slider on the app to turn it on or off. Implementing this in the code was easily done by incorporating the command into section of the commandHandler function that executed the move commands.

For the Tag Tracker and Robot Disabled modules, code was added to the main loop to check the output of the IR detector and if the 3DoT David should be disabled. The code is executed after the commandHandler function is called and checks if the robot has been tagged. If so, a counter would be incremented and if that counter reaches three, the robot will be disabled. When hit, the speaker will make a sound and the robot will not check for tags for 5 seconds. When the robot is disabled, it will not respond to any commands for 10 seconds and play a short song to indicate this change. All of this is done by using a flag variable to keep track of whether or not a tag has occurred. The flag will be cleared after 5 seconds have passed. When this has happened three times, the code will enter a loop that keeps it from responding to commands for 10 seconds.

Additionally, all of the extraneous code that was a part of the latest version of the arxterra firmware was removed. This includes all of the telemetry and sensor definitions that were left over from older projects that are not being used for the 3DoT David. All of the code used for debugging and testing were also removed or commented out to make sure additional processing time was not being used up. Comments were also added to help future students understand how the code functions.

The final version of the Arxterra Firmware (click here)