Spring 2016 Velociraptor: Critical Design Review Debrief

By: Khoi Vu (Project Manager)

 

The Critical Design Review (CDR) purpose is to present data and progress of the project to the President and the Customers. The CDR presents the executive summary, system and software design, experimental results, interface definition, and the custom PCB design that will be used on the final product.

 

For full PPT of CDR click on the link below:

https://www.dropbox.com/s/c61ju4onj17a5zi/CDR.pdf?dl=0

 

Debrief:

  1. In the executive summary, there should be an exploded view of the 3D model of the product that contains the name of the person responsible for each slide.
  2. Executive summary should always be short, summarizing the project design and design features.
  3. System design should not show the PCB.
  4. Servos tests in the experimental result were done incorrectly; a stick lever arm was used as lever length changes during rotation. A circular lever arm will give a more accurate result because it will have a consistent radius.
  5. Incline testings did not show how the robot will respond to the incline when it is walking sideways on the incline instead of walking up the incline.
  6. Power test did not give a accurate result of power consumption by the servos, a ammeter should be used to connect in series to find the actual power consumed by the robot since the robot has been completely assembled.
  7. PCB schematic was not presented clearly; a white background with black lines would be much easier to see.
  8. Since the robot is taking in a lot of Current (5 Amp), a fuse is recommended to protect the components of the robot.
  9. Active Control Circuit is missing for the dynamic walking requirement. The team should still acknowledge all requirements that have been listed.
  10. The team should consider how the robot’s foot should always be parallel to the ground and not always the x-axis. This may cause failure when walking over obstacles and inclines.
  11. Verification and Validation tests needs to show more results.
  12. Resource report values that were measured should not contain any uncertainty since the values were measured and not estimated.
  13. Cost Budget should also contain the cost of parts that were donated to show a more accurate cost of the whole project.
  14. Final printing should not start when PCB size is not known yet.

Note:

Number 5 was tested and the results were shown in CDR PPT,  however, the team may have not discussed the results in depth.

Number 14 printing only consist of parts such as the legs that have been enclosure, the team have not finalize the design for the PCB container, therefore, we have not printed the PCB case.

 

 

 

 

Spring 2016 Pathfinder Design and Manufacturing – Tilt System Finalized Design

 

17

by:

Lindsay Levanas (Design and Manufacturing)

Table of Contents

Introduction

As previously detailed in the Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design blog post, the tilt system will contain a base that will hold the tablet, phone, and tilt servo.1 While a prototype of this base has already been designed, it was around the measurements of the pan servo as the tilt servo had not yet been acquired. This report will serve to document the new tilt system base as designed around the measurements of the new tilt servo. Also mentioned will be the addition of cord holes in the previous design. Note that the final product will be constructed of 3D printed, ABS plastic parts.

Google Tango Tablet Encasement Improvement

In view of one of Pathfinder’s Level 1 requirements, an enclosed environment for a Google Tango tablet was designed.2 However, this design did not take into account the fact that the tablet will need to be continuously charging, as it has a shorter battery life then our Project’s required duration.3 Therefore, the position of the charging port was documented, and a cut-out was added to the previously designed tablet box.

1

 

Tilt Servo Measurement Process

In order to redesign the tilt system for the new servo, the servo first had to be measured and modeled. To begin with, the tilt servo’s basic dimensions (height, width and depth) were measured. Below illustrates the depth measurement as an example.

2

Note that with the servo horn, the depth is 1.744in (illustrated below), and with the fan attachment, it is 1.881in.

3

Similarily, multiple height and width measurements were taken as needed from varing reference points.

Next, the diameter of the servo horn was measured and found to be .236in.

4

The placement of the servo horn was based on the midpoint of the circle it is located on. Note that this circle has the same diameter as the width of the servo.

5

To assist in the tilt servo mounting design, the position of the screw flaps were also measured. These included the distance from the edge of the screw flaps to the other side of the screw holes, the thickness of the screw flaps (illustrated below) and the distance of the screw flaps from the back of the servo.

6

Lastly, the position of the power and controlling cord was documented to allow for a cord hole to be added to the previous design.

Following a similar process to the one demonstrated above, combined with a few calculations where needed, the servo fan was dimensioned as well.

Completed Tilt Servo and Fan 3D Model

For size and position reference, the above parts were modeled in Solidworks.
78

 

Tilt Servo Base Measurement Process

Combining the modeling process of the tilt servo detailed above, with the previous design of the tilt system base1 the previous base was modified to accommodate the new tilt servo. While a variety of measurement calculations were performed, only the main few will be detailed below.

To start with the tilt servo’s total depth of 1.881in meant that the tilt system base width changed from its original width of 10.98in to 11.19in.

9

The position of the servo horn changed the height of the servo encasement box supports from 4.29in to 4.98in.

10

To allow for proper mounting of the tilt servo, the original base design was modified to give room for the servo’s mounting screws. This was done by thinning the front of the servo support strut and servo encasement lid in alignment of the servo’s mounting flaps, as dimensioned above, so that screw holes can be drilled there later.
11

Next the position of the tilt servo’s cord was noted and a hole was added to the bottom of the servo encasement box.

12

Note that in view of the final selection of LED headlights,4 the previous tilt system base’s headlight holder design was removed. A safe adhesive method will be used for the future design.

13

Lastly, to accommodate the size of the 3D printer Spring 2016’s Pathfinder will be using, the design of the tilt system base was cut in half and a square connector bracket was added to connect the two pieces.

14

Conclusion and Future Plans

In conclusion, Spring 2016 Pathfinder’s new tilt system has been modified to fit the new tilt servo and to account for charging cords that are required by components of the system. LED mounting will be detailed after the new tilt system has been fabricated.

1516

17

Sources:

  1. Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design, Tilt Base, 3/9/16 http://arxterra.com/pathfinder-design-and-manufacturing-tilt-system-design/
  2. Spring 2016 Pathfinder Preliminary Design Documentation, Level 1 Requirement, 2/19/16 http://arxterra.com/spring-2016-pathfinder-preliminary-design-documentation/
  3. Spring 2016 Pathfinder: Project Tango Preliminary Research                             http://arxterra.com/spring-2016-pathfinder-project-tango-preliminary-research/
  4. Spring 2016 Pathfinder: LED Headlights                                                             http://arxterra.com/spring-2016-pathfinder-led-headlights/

Spring 2016 Pathfinder: LED Headlights

1

by:

Juan Acosta (Electronics & Control – MCU Subsystem & Firmware)

Table of Contents

Introduction:

One of our requirements is to have the Pathfinder explore the CSULB campus at night. In order for us to accomplish this objective, we will need a way of maintaining a visible line of sight for the Tango Tablet and Android Phone. So we decided that we would give the Pathfinder bright headlights that would allow us to see a maximum of 4 meters or about 12 feet ahead of the pathfinder.

 

Materials:

  • HC-06 bluetooth Module
  • Ar 2560 or Arduino UNO
  • Jumper Wirduino MEGAes (4)
  • 6 Piranha 5V Led Light Panel Board White Night Lights Lamp Super Bright (2)
  • Laptop with Coolterm application

 

Fritzing Schematic and Steps:

2

 

  • Wire GND of the HC-06 to GND on the arduino
  • Wire VCC of the HC-06 to 5V on the arduino
  • Wire RXD of the HC-06 to TX0 on the arduino
  • Wire TXD of the HC-06 to RX0 on the arduino
  • Wire 5V of the LEDS to PIN52 on the arduino
  • Wire GND of the LEDS to GND on the arduino
  • Upload arduino code provided. (Notice: Be aware that the HC-06 must be unplugged while uploading code to the arduino, otherwise you may run into functionality issues.)
  • Initially you will have to pair the HC-06 with the laptop through bluetooth (Password for HC-06: 0000 or 1234)
  • Manually control the LEDS through Coolterm by sending a ‘0’ for off, or ‘1’ for on.

 

Arduino Code:

// The following code was written, tested and debugged by Juan Acosta for

// testing the LED Headlights operation using the HC-06 to implement commands

// being sent from the COOLTERM application from a laptop or phone to the arduino.

// Group: Pathfinder Spring 2016

// Electronics and Control:  Juan Acosta (MCU Subsystem and Control Firmware)

///////////////////////////////////////////////////////////////////////////////

// following are connections required for HC06 module:

// connect BT module TX to RX0

// connect BT module RX to TX0

// connect BT Vcc to 5V, GND to GND

///////////////////////////////////////////////////////////////////////////////

// following are connections required for LED Headlights:

// connect 5V to Pin 52 of the arduino MEGA

// connect GND to GND

///////////////////////////////////////////////////////////////////////////////

void setup() {

pinMode(52,OUTPUT);       // initialize pin 52 as output for LED Headlights

Serial.begin(9600);       // set the data rate for the Serial Port

}

char a; // stores incoming character from other device (phone, tablet, or laptop)

void loop() {

if (Serial.available()){        // if text arrived in from hardware serial…

a=(Serial.read());

if (a==’1′){

digitalWrite(52,HIGH);     // turn the LED Headlights on (HIGH is the voltage level)

}

if (a==’0′){

digitalWrite(52,LOW);      // turn the LED Headlights off

}

if (a==’?’){

Serial.println(“Send ‘0’ to turn LED Headlights on”);

Serial.println(“Send ‘1’ to turn LED Headlights off”);

}

// you can add more “if” statements with other characters to add more commands

}

}

Video Demonstration

Conclusion:

We were able to meet the requirement of having a distance of at most 4 meters or 12 feet lit up. These LED lights will definitely help illuminate the path for the pathfinder as it traverses through CSULB at night. Even though these LED lights are super bright, they should not be relied on as the primary source of lighting aid, we are using these in conjunction with the lighting from all the lamp posts around campus. After we confirmed that the LED Headlights were working through bluetooth, we can then transfer what we applied over to arxterra so we can control the LED Headlights through the arxterra control panel through custom commands.

Sources:

LEDs:

http://www.ebay.com/itm/181941929073?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Coolterm:

http://freeware.the-meiers.org

 

UFO Spring 2016 – EDF Area Coverage With Flap Length Calculations

Written and posted by: Luis Valdivia (Project Manager)

Table of contents:
Introduction
Approach
Formulas
Conclusion
Possible Solution

 

Introduction:
When attempting to angle the thrust coming from the Electric Ducted Fan (EDF), there is a risk of covering the ducted fan area to prevent vertical flight. This post will explain our research done to determine the maximum area allowed to control the aircraft without losing vertical thrust.

 

Approach:
Using middle school math, we can figure out the area of the flap size and the area of the duct.

Figure 1.1 demonstrates the area of the duct being covered by the flap, along with formulas for area. 

areamiddleschoolmath123

Because of the size of the EDFs, we will assume the length of the flap is fixed at 55mm. The Width of the flap will depend on the area of the opened duct, aka the area of the circle. For a fully opened duct (meaning no coverage of the circle) we can produce a maximum thrust of 650g with a flap of length 0mm. With a partially opened duct (meaning half of the circle is covered) we can produce half the thrust of 324.99g with a flap length of 27.5mm. Finally, for a fully closed fan duct we will produce 0g of thrust with a flap of length 55mm.
Inputting our 3 sets of values into excel, we can fit a linear line into our data plot to obtain the equation of our line. This equation will help us calculate more values to get a better understanding of the range between flap length and available output thrust.

Figure 1.2 Linear fit plot of Duct Area vs. Thrust (with equation of line)

AreavThrust123

Figure 1.3 Linear fit plot of Duct Area vs. Flap Length (with equation of line)

ductvflaplength123

 

Formulas

Area of duct = 2*π*(radius*percentage of opened duct)

Length of flap = 55mm(100 – percentage of opened duct)

Area of flap = length of flap * 55mm

Thrust (g) Area of duct Length (mm) area of flap (mm^2) % of open fan
650 345.4 0 0 100.00%
643.48137 341.946 0.55 30.25 99.00%
636.9815581 338.492 1.1 60.5 98.00%
630.4817463 335.038 1.65 90.75 97.00%
623.9819345 331.584 2.2 121 96.00%
617.4821227 328.13 2.75 151.25 95.00%
610.9823109 324.676 3.3 181.5 94.00%
604.4824991 321.222 3.85 211.75 93.00%
597.9826872 317.768 4.4 242 92.00%
591.4828754 314.314 4.95 272.25 91.00%
584.9830636 310.86 5.5 302.5 90.00%

 

Conclusion:

As you can see, the thrust output from the EDFs will beginning to decrease if we cover the duct. Although, from a previous blog post we mentioned the necessary thrust to lift the weight of the aircraft. The necessary thrust to lift a quadcopter weighing in at 1291g is 645.5g thrust for each EDF. From our table above, it seems like covering the duct at anything greater than 0.55mm will prevent our UFO from lifting off the ground.

 

Possible solution:

In order to continue the project with thrust vectoring, the EDFs will have to be swapped with fans of thrust greater than 650g. Another solution is to reduce as much weight as possible to lift the UFO and vector the thrust we a reasonably sized flap.  

Spring 2016 3D SMD: X-Axis, Y-Axis, Z-Axis, A-Axis, and Origin Brackets

 

By Henry Nguyen (Electronics and Control)

Table of Contents

Introduction

For our 3D SMD pick and place machine, we were able to get most of our software for controlling our stepper motors done. The only thing left to do is to design and manufacture proper brackets for each of our stepper motors since we purchased 2 new geared stepper motors from Makeblock. The Makeblock geared stepper motors has different screw holes to hold the motor therefore we had to design new brackets and modify our existing brackets in order for it to work. I will be discussing our X,Y,Z, and A axis brackets as well as our origin placement bracket.

 

X-Axis

Figure 1. X-Axis Measurements

Figure 1. X-Axis Measurements

In order to manufacture our X-Axis bracket, I had to consider the dimensions of our geared stepper motors screw hole. I also considered the placement where our X-Axis bracket will need to be placed and design screw holes for its proper location. The diameter of the hole in which our stepper motor will be fitted is approximately .849 inches. Figure 1. shows a more descriptive measurement for everything that needs to be bend and drilled for our X-Axis braacket.

Figure 2. X-Axis Bracket

Figure 2. X-Axis Bracket

I was able to find a local metal shop nearby that was able to manufacture our desired X-Axis design. There are four screw holes placed around the the larger circle above. These measurements had to be exact in order for us to screw in our geared stepper motor properly.

Figure 3. X-Axis Bracket Installed And Coupler Design

Figure 3. X-Axis Bracket Installed And Coupler Design

Figure 3 shows that I was able to successfully install our X-Axis brackets. The two screws on the top was able to attach properly our X-Axis. As we move our Y-Axis, our X-Axis geared stepper motor will be moving along with the machine.

Y-Axis

Figure 4. Y-Axis Measurements

Figure 4. Y-Axis Measurements Figure 5. Y-Axis Bracket

For our Y-Axis geared stepper motor, I found that we could reuse our old X-Axis brackets from Makeblock that was meant for our non-geared stepper motors. This bracket is able to attach properly to our machine. The only problem is that we needed to drill holes to match our new geared stepper motors as shown in Figure 4 and Figure 5. I found that these holes were too close to the large circle therefore I had it professionally drilled in order to prevent any mistakes.

Figure 6. Y-Axis Bracket Installed

Figure 6. Y-Axis Bracket Installed

Figure 6 shows our Y-Axis geared stepper motor attached to our pick and place machine using the old brackets for our X-Axis. As we can see, there are 4 new screws that are screwed into our geared stepper motor. The coupler being used is a 8mm x 4mm coupler in order for these stepper motors to properly spin the 4mm rod on our Y-Axis.

Z-Axis

Figure 7. Z-Axis Measurements

Figure 7. Z-Axis Measurements

Figure 8. Z-Axis Bracket

Figure 8. Z-Axis Bracket

Figure 7 is the design and measurements that I made for our Z-Axis. This time, we will be reusing our old stepper motors originally for our X and Y axis in order to control our Z-Axis thread drive. A unique design I added to this is that the bracket will extend our and bend 90 degrees. The purpose of this is shown in the image below.

Figure 9. Z-Axis Cable Hiding

Figure 9. Z-Axis Cable Hiding

The reason for our Z-Axis bracket to extend is with 2 screws holes is to hide all the wires from our Z and A-axis stepper motors. As a result, I was able to hide the wires underneath this bracket and zip tie it in order to prevent these wires from being exposed. This is done for aesthetics of our machine as well as preventing any wires from being snagged or caught while our machine is running.

A-Axis 

Figure 10. A-Axis Measurements

Figure 10. A-Axis Measurements

Figure 11. A-Axis Bracket

Figure 11. A-Axis Bracket

Figure 10 is my A-Axis design and measurement. This design should be able to allow our stepper motors to properly fit through the center hole as well as being screwed into the four screw holes. The proper measurements are shown in Figure 10. This bracket will also require 2 90 degree bends. In Figure 11, you can see the two screw holes on top. This will allow us to attach this bracket to our Z-Axis thread drive beam. This will allow our A-Axis stepper motor and bracket to move up and down when our Z-Axis is running. The importance of these 90 degree bends is to allow our stepper motor to be parallel with our machine which is crucial when picking and placing components accurately.

Figure 12. A-Axis Bracket Installed

Figure 12. A-Axis Bracket Installed

Figure 12 shows our A-Axis stepper motor being installed onto our thread drive beam. The importance of this stepper motor is to allow rotation for our components in 45, 90, 135, and 180 degrees. Not all boards are created with the components being the same orientation every time therefore this stepper motor and bracket is crucial for the success and completion of a 3D SMD pick and place machine.

Origin Placement

      

    Figure 13. Origin Placement Measurement

Figure 13. Origin Placement Measurement

 Figure 14. Origin Placement Bracket

Figure 14. Origin Placement Bracket

Figure 13 is my design for our origin placement bracket. The dimensions of this is the same as the maximum size of free Eagle PCB of 4.0”x3.2”. Figure 14 is the actual bracket manufactured out of aluminum. The purpose of this bracket is so we will know where our origin is for our machine at all this. Another important use of this bracket is to ensure that when we place a PCB against this bracket, the PCB will be straight and oriented properly for the accuracy of our machine.

Conclusion

Overall, I was able to complete all the necessary brackets for our X, Y, Z, and A-Axis as well as the origin placement bracket. It is extremely important to note that getting proper measurements for all of these brackets is crucial. I had to design brackets that are specific to an exact item (stepper motors). If I did not get the measurements as accurate as possible, we would lose time and money.  All of these brackets is extremely important to get designed and manufactured as soon as possible considering we are getting close to the end of the semester. Without these brackets we will not be able to properly run our machine, perform accuracy tests, and proceed with any progress.

Bluetooth Module Update Spring 2016

Written by: Anthony Becerril (Mission, Systems, and Test Engineer)

Posted by: Luis Valdivia (Project Manager)

Table of contents:

  • Introduction
  • Previous work
  • Current Progress
  • Additional Resources

 

Introduction:

The current UFO Quadcopter is being modified to communicate via bluetooth in addition to the already existing RC communication. The following will discuss previous work and current progress on bluetooth communication implemented with the quadcopter.

 

Previous Work:

Previously the bluetooth module HC-06 was used in combination with the HK MultiWiii flight controller to monitor and control the quadcopter. A GUI is also provided alongside with the MultiWii controller and can be used to display information from the MultiWii from the following: triple axis gyro, accelerometer, barometer, magnetometer. Show below is the GUI’s display.

Figure 1.1 Multiwii Flight Telemetry GUI:

coolgui

The software can be found via the internet or the latest version found at this time can be downloaded here. Beyond that, in the past the Arxterra application has been used to sync up the phone to the desktop version of Arxterra and demonstrating the camera function. Further details on how bluetooth works can be found in the previous post on bluetooth from Fall 2015.

 

Current Progress:

Rather than pick up where previous work left off, discussion on whether a new approach was needed had happened. The results were using a new bluetooth module and researching for a phone application to help monitor and control the quadcopter.

 

The bluetooth module we decided to use what the HC-02 android compatible module. Buying it from Hobby King also provided easier to use wires to connect it with the MultiWii board. When attaching to the quadcopter this module is easier to attach due to not having to deal with pins on a breadboard like you would with other modules.

Figure 1.2 Bluetooth Module and Connector:

bluetooth

For setup, we followed the quick overview video as reference and first wire the module to the MultiWii controller. The wire connect as follows:

Figure 1.3 Wiring Diagram for Multiwii 328p:

bluetoothpinout

After setting it up, we power the MultiWii board to turn on the bluetooth module. When syncing up the module, it initially blinks due to not being paired to any device yet. When seeking to pair it is highly recommended to use an android device. When pairing look for the device, “HC-02” of the devices available. Then there is a prompt to input the pairing code which by default is 1234. This code can be changed with some research online. If pairing was successful then the bluetooth module should now be a solid light rather than be blinking. Now the module is paired and ready to be used with android applications.

 

This is a big step in communications due to the final goal of being able to control the quadcopter via phone application. Further research is going to be done to implement a third party application. This will then lead to being able to do the same with the Arxterra android application.

 

Additional Resources:

Previous Blog Post: Learning To Use a Bluetooth Module (Fall 2015)

Previous Blog Post: Bluetooth Interface to Arxterra Application (Spring 2015)

Multiwii MWC FC Bluetooth Module (HC-02)

Multiwii Software

MultiWii 328P + Bluetooth Module Quick Overview

Spring 2016 3D SMD: Software

By Christine Vu (Missions, Systems, and Tests) and Henry Nguyen (Electronics and Control)

Table of Contents

Purpose

This is a summary of all Arduino code modifications for the pick and place machine to work with our needs.

Modifications for Java can be found here.

Our files can be found here: https://github.com/cvuchristine/MakeblockPlotter.git

Required Arduino Code modifications

  1. Pinout Reassignment
  2. Z-Axis Arduino Code Modification
    • The original Makeblock X-Y Plotter Robot Kit controls the Z-axis using a microservo and pen to control. However, we decided to use a stepper motor to control the Z-axis so it can be suspended on a threaded drive.
  3. Addition of A-Axis (rotation of IC Chips)
    • This concept requires an addition of another stepper motor to be able to self-automate and correct the orientation of the IC Chip.
  4. Limiting Switch Feedback (notifies that we’ve gone too far)
    • The addition of the limiting switch needed to be added to the Z-control here.
  5. Microservo control (reel feeders)
    • The microservos will control the reel feeders’ cut-tape, which could help keep the cut-tape away from the vacuum nozzle.
  6. Solenoid Valve Control (vacuum suction)
    • Solenoid valve will be able to close off the vacuum suction since the vacuum pump does not have its own controllable switch.

Updated Me UNO Shield

Using the Me UNO Shield, we were able to select the following ports as shown below. It is important to note that not all ports hold 2 digital I/O or analog pins. Port 5 was also unable to be used because it holds TX and RX pins, and our G-Code lines are sent serially.

The pinouts are shown below:

StepperMotor

Figure 1. Stepper Motor Pinouts and Variables.

SwitchesReels

Figure 2. Limiting Switches and Reel Feeder Pinouts.

Code Processing

Makeblock is an open-source company and provided code for the X-Y Plotter Robot Kit.

URL: https://github.com/Makeblock-official/XY-Plotter-2.0/tree/master/software/GCodeParser

The Makeblock code was originally meant for 2 stepper motors (X-Axis and Y-Axis) and 1 microservo motor (Z-Axis) and two sets of minimum and maximum limiting switches, which was a safety factor used in case the motor moves the axes beyond the X-Y Plotter frame.

Summary of Makeblock X-Y Plotter Arduino Code

The Arduino code provided includes three Arduino files — GCodeParser.ino, process_string.ino, and stepper_control.ino.

GCodeParser.ino

This is the main loop to initiate pinouts and variables. The GCode interfaces with Java by receiving GCode serially line-by-line.

Process_string.ino

The line of G-Code sent through the serial monitor processed here. It search for specific lines such as $ and G-Code. The commands are placed in the table shown below. Often times, the G-Code is followed by a specific X-Y-Z-coordinate.

Standard G’s Definition
G0 Nothing
G1 Move stepper motors at full speed
G2 Create clockwise arc
G3 Create counter-clockwise arc, declare values first, then calculates how many steps
G4 Delays GCode Commands using ‘P’ command (i.e. G4 P200 means delat 200 ms)
G20 Moves steps per inch
G21 Moves steps per mm
G28 Moves back to origin at full speed
G30 Moves back to origin based provided a certain coordinate at full speed
G90 Moves to coordinate at full speed
G91 Moves in increments
G92 Sets current position as origin
M Placed in the Arduino Code — Doesn’t mean anything in Arduino Code
‘$’ Cases Definition
$1 Sets step pinouts
$2 Sets direction pinouts
$3 Sets limiting switch pinouts (for minimum)
$4 Sets limiting switch pinouts (for maxmimum)
$5 Enable Servo for Z-Axis **Removed for our purposes**
$6 Declares how many steps per mm should be moved
$7 Declares feedrate
Customized Definition
$9 Turn on solenoid valve
$10 Turn off solenoid valve
$11 Move microservo 1
$12 Move microservo 2
$13 Move microservo 3
$14 Move microservo 4
Table 1. GCode Commands processed by Arduino.

 

Stepper_control.ino

This file includes functions/subroutines called out by the process_string.ino file. It will calculate how much the motors should be moving.

Flowcharts

Flowcharts were also made to help us understand the code and each purpose of the subroutines and functions in the file.

Loop 1 Define Parameters Loop 2 (Set up) Loop 3 If Serial IS avaible part 1 Loop 3 If Serial Is avaible Part 2 Loop 3, If Serial NOT availble Loop 3, Part 1

Figure 2a. GCodeParser.ino

Process String Loop 1 Process String Loop 2 Part 1 Process String Loop 2 Part 2 Process String Loop 3

Figure 2b. process_string.ino

calculate_deltas calculate_feedrate_delay dda_move_2can_step dda_move_1 do_step getMaxSpeed_disableSteppers init_steppers

Figure 2c. stepper_control.ino

Pinout Reassignment

Blog post on the pinout reassignment can be found here: https://www.arxterra.com/spring-2016-3d-smd-me-uno-shield-and-software/

Z-Axis Code Modification

The Z-Axis was originally controlled by a microservo, which would tilt the pen up and down, as shown on Fig. 3. This was not sufficient to control our vacuum head, so we decided to work with stepper motors and remove the servo control in the code.

Figure3

Figure 3. Original Z-Axis control with microservo.

The original Arduino code included a servo pinout and write attachments.

Z-AxisOriginal

Figure 4. Original Arduino Code setup section included the function servo.attach(), which was used to control the Z-Axis.

The function highlighted in Fig. 4 was commented out, since our stepper motor would not use this function. To remain consistent with the code, we decided to go through each line in the process_string.ino file to determine where the servo library functions are called out and remove them so we could switch to stepper motor control.

Z-Command Z_New

Figure 5. (Left) Original Arduino code. (Right) Modified Arduino Code for Case $1, which initiates the pinouts.

 

In the stepper_control.ino file, there was a function to determine which was the dominant axis to calculate the feedrate delay. Z-coordinates were originally not implemented, so we had to implement this portion.We also added the A-Axis at this point, which is labeled as the “b” variable.

OldfeedrateDelay NewZ-DeltaSteps

Figure 6. (Left) Original Arduino Code. (Right) Modified Arduino Code for both the Z-Axis and A-Axis code.

Addition of A-Axis

The A-axis is controlled by a stepper motor, so it was important to assure that each variable is declared each time the X-Axis and the Y-Axis are called out. Because we decided to utilize the stepper motors similar to the X-Axis and Y-Axis, the feedrates and the steps per mm were the same.

The changes to each call-out are shown below. We decided to use variable “b” because the Java code already uses the variable “a”, and the arduino code can read only one letter at a time.

1 2  gcoderparser float

Figure 6a. Addition of A-axis using the variable ‘B’ in the GCodeParser.ino file.

process 1 Process 2

Figure 6b. Enables the step and directions pins for Me UNO Shield pinouts. This was modified in case ‘$1’.

Process 3 process 4

process_string 1 process_string 2

Figure 6c. Added lines to search for variables of ‘b’ so that motors are able to be moved. If a line ‘B40’ is sent, then the subroutines in the process_string.ino file will know what to do with that command.

process_string 3 process_string 4 process_string 5

Figure 6d. More modification in the case statements to be consistent with the rest of the stepper motors.

process_string 6

Figure 6d. Added variables in the process_string.ino file to read any G-Code commands.

The screenshot of Case 92 as shown above was modified so that the origin of the variable is not only X, Y, and Z but also zero’d for A. Hence, we see that there are 4 values of ‘0.0’.

step 1 step 2

Figure 6e. Addition of A-Axis code in the stepper_control.ino file.

Limiting Switch Feedback

Similar to the X-Axis and the Y-Axis control, we decided to set a limiting switch for the Z-axis to check whether it goes too far up. In the stepper_control.ino file, there is a function called dda_move (). A portion of the code checks whether the limiting switches have been hit at the end of the working area. Fig. 7 shows the portion where the limiting switch for the Z-axis is added. The Z-minimum pin was not used, but had to be included to remain consistent with the amount of variables added to the function.

Z-Canstep

Figure 7. Limiting switch Arduino code added under the dda_move() function.

Microservo Control

For our reel feeders, we decided to attach reel wheels onto four microservos. To control out microservos, we decided to create our own case statement for the Arduino to process in process_string.ino.

With the help of our president, Ryland Watts, we were able to utilize a while statement. His while statement required delays, which we didn’t want to use. A subroutine was created and called out when ‘$’ statements were provided in the process_string.

Table 1 shows the customized code we added. Fig. 8 shows our subroutine.

move_reel

Figure 8. Subroutine move_reel gets called out when ‘$11’, ‘$12’, ‘$13’, or ‘$14’ is in the serial monitor.

caseServo

Figure 9. Case statements for servo control.

In process_string.ino, the move_reel subroutine is called out if the inputs of the ‘$’ are created.

Solenoid Valve Control

For the solenoid valve, we are considering on controlling the value using an n-channel MOSFET. This was based on the lesson taught by Ryland Watts, where we learned how to control DC motors with Arduino digital pins.

SolenoidValveCircuit

Figure 10. Solenoid Valve Circuit for Arduino

The following code is in the process_string.ino, where ‘$9’ and ‘$10’ turns the solenoid valve on and off, respectively. The 12 Volts attached to the solenoid valve is the rated voltage at which the solenoid valve will turn on.

SolenoidValve

Figure 11. Case code to activate the solenoid valve off and on.

Conclusion

The summary of software modifications required thorough understanding of our coding goals and what was already implemented in the Makeblock Arduino code. With the help of our president Ryland Watts, we were able to complete our software modifications.

 

SPARCCS Spring 2016: Critical Design Review (CDR) Debrief

Posted by Mikhael Semaan (Project Manager).

Original notes taken by Eric Hanna (Design and Manufacturing).

These are our notes from meeting with Mr. Hill, the instructor of EE 400D, following our CDR Presentation [1].

Read more

Spring 2016 A-TeChToP CDR Debrief

By Cody Dunn (Project Manager)

Overview

This blog post provides insight into the CDR debrief for team A-TeChToP (the CDR Presentations were posted on an earlier blog post). The group did not perform at the expectation level of the customer and must improve before the end of the semester.

Read more

UFO Mass-Thrust Trade Off Studies Spring 2016

Written and posted by: Luis Valdivia (Project Manager)

Table of contents:

  • Introduction
  • Formula
  • Tests
    • 1291g
    • 1391g
    • 1504g
  • Conclusion
  • References

 

Introduction:

This document highlights the importance of weight for the UFO abducted quadcopter. Each EDF delivers a maximum thrust of 650g. Running all 4 motors should be able to lift the quadcopter, if the aircraft is not over weight capacity.

 

Formula:

In a hobbyking forum, we found a formula used to determine the allowed weight for certain thrust values carried by the motors.

 

Thrust per edf = (Weight of aircraft * 2)/Number of fans being used

We can turn the formula around and solve for the maximum weight allowed on the UFO abducted.

 

Weight of aircraft = (Thrust per edf * Number of fans used)/2

 

In our case we will have an allowable weight of:

Weight of aircraft = (650 g* 4 EDFs)/2 =1,300g

 

Tests:

Our first test, we attached the 3d printed legs we intended as a replacement of the original landing legs.(also included the battery, 4 EDFs, 4 ESCs,  multiwii flight controller, wireless receiver, lipo low voltage indicator and support attachments for the frame) . The weight of the vehicle for this test was 1291g (9g below our limit).

 

The video can be seen here

 

Our second test, we attached the ducts to hold the servo motors and also included the battery, 4 EDFs, 4 ESCs, 4 pairs of 3d printed legs, a multiwii 328p flight controller, wireless receiver, lipo low voltage indicator and support attachments for the frame. The weight of the vehicle for this test was 1391g (91g above our limit).

 

The video can be seen here

 

For our third and final test, we attached the servo motors (x4) and also included the battery, 4 EDFs, 4 ESCs, 4 pairs of 3d printed legs, 4 ducts to hold the servo motors, a multiwii 328p flight controller, wireless receiver, lipo low voltage indicator and support attachments for the frame. The weight of the vehicle for this test was 1504g (204g above our limit).

The video can be seen here

Conclusion:

 

As a conclusion, we determined the thrust vectoring control for stability would not be possible with the current set up we have. Possible solutions: replace current set up with stronger fans, tilt current EDFs to vector thrust, and finally side fan(s) similar to a helicopter. Table 1.1 demonstrates the necessary thrust per EDF (assuming 4 EDFs are being used) to lift our vehicle. Strictly, anything above 1300g WILL NOT LIFT.

 

Weigt of vehicle (g) Thrust per EDF (g)
1291 645.5
1391 695.5
1504 752

Table 1.1 Above demonstrates relation between mass and required thrust, for liftoff. 

References:

  1. http://www.hobbyking.com/hobbyking/forum/forum_posts.asp?TID=38561