Spring 2017 SpiderBot: Preliminary Design Document

/in , /by
edit+xClone Element

Table of Contents

SpiderBot Team:

Project Manager – Nicholas Jacobs

Missions, Systems and Test Engieer – Jeff Funetes

Electronics and Control Engineer – Shaun Pasoz

Design and Manufacturing Engineer – Daniel Matias

 

 

Program Objectives

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot is the 2nd generation SpiderBot. The customer has requested that SpiderBot utilize a 3DOT microcontroller board with a custom SMD I2C board. The customer also specified that SpiderBot be controlled from the Arxterra App via a Bluetooth communication link or by the Arxterra’s web interface.  Lastly, the customer expects iterations of the engineering method, a neat and orderly cable tree, and an aesthetically appealing design.

 

Mission Profile

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot will be an 8-legged that is built upon the Terra Spider design concept. The SpiderBot will be validated to the customer during an end of the semester Pac-Man style game. SpiderBot’s role in the game is to provide live aerial video footage to enable participants to navigate a maze and reach a target square of the maze. Moving from outside the maze to the grappling launch point, then raising from the floor to an elevated position, and then providing a live video feed will demonstrate all SpiderBot’s design specifications stated in the Project Objectives.

 

Requirements

Program Level 1 Objectives:

By Project Manager Nicholas Jacobs

  1.  The SpiderBot project shall be completed by 10 May 2017. One week before Finals week (10 May 2017) http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
  1.  Total production cost must not exceed $250.00 US.
  2.  Spiderbot shall participate in the end of the semester Pac-Man style game. http://web.csulb.edu/~hill/ee400d/S’17%20Project%20Objectives%20and%20Mission%20Profile.pdf

Project Level 1 Requirements

By Project Manager Nicholas Jacobs

  1. SpiderBot will incorporate the 3Dot controller, SMD I2C boards.
  2. SpiderBot will be controlled by the Arxterra App using bluetooth.
  3. SpiderBot shall incorporate a smartphone or NTSC camera to provide real-time battlefield conditions to bi-ped and velociraptor remotely.
  4. SpiderBot should climb a wall by means of a rope/harness mechanism.
  5. SpiderBot shall be able to move forward, backwards and turn both left and right through use of DC motors.
  6. SpideBot shall compact size.
  7.  Will play in end of semester games
  8. Should provide video feed

Project Level 2 Requirements

By Mission, System, and Test Engineer Jeff Fuentes

  1. Spiderbot shall utilize the integrated 3.7v Li-ion battery to power the SpiderBot for 20 minutes.
    1. SpiderBor shall incorporate 2 seperate batteries to supply DC motors and servos and another 3DOT board, and motor driver.
  2. Spiderbot shall receive commands from the arxterra app via the HM-10 Bluetooth module on the the 3DoT board.
    1. SpiderBot shall establish a reliable comunication link up to 10 meters. 3DOT board will serve as the peripheal device and the smartphone will serve the central device. HM-10
  3. SpiderBot shall implement an Android smartphone or TTL Serial JPEG (capable of NTSC) camera to provide battlefield footage.
    1. NTSC camera will be an Adafruit NTSC Camera.
  4. Spiderbot shall utilize an Ultra-Micro Servo to drive the  rope/harness mechanism.
  5. Spiderbot shall utilize the TB6612FNG Dual DC Motor Driver to walk on 8 legs, through sets of 4, each driven by one motor.
  6. Spiderbot shall incorporate 3d printed parts that take no longer than two hours to print. 
    1. SpiderBot shall weight 3lbs or less. 

Design Innovation

Creative Solution

By Project Manager Nicholas Jacobs

From our Creative Design solutions, the SpiderBot team has decided to implement a unique idea into the Spring 2017 design. The end-user has specifed the need for a real-time video feed that will be provided to the control interface of two contending robots. SpiderBot will deliever an aerial view of the battle arena. The idea for an aerial view was the product of our Duncker Diagram which presented the issue of how our SpiderBot will climb a wall. Intially a suction cup system was proposed to adhere the SpiderBot to the wall. During the Attributes Listing design appraoch and after further consideration of the suction cup approach, the decision was made to scrap the suction cup idea. Our unique idea to provide the aerial video feed is to implement a grappling hook that would shoot and secure onto an anchor that will support the weight of SpiderBot allowing it to retract itself into an elevated position in order to provide aerial coverage.

 

Systems/Subsystem Design

 

Product Breakdown Structure

 

Electronic System Design

By Electronic and Control Engineer Shaun Pasoz

Last semester’s SpiderBot ran into several areas of difficulty; the worst of which was dynamic walking. They used servo motors to control the actions of the robot. While servos are excellent devices as they provide feedback from the motor, their pitfall is they cannot sustain a large amount of weight.  Therefore, this semester we have been tasked to implement a SpiderBot featuring DC motors.

Since the 3DoT board can only supply a current of 450mA, it is highly probably that we will need to implement an external power supply. In order to get the greatest motor efficiency, the first step is to decide on what configuration we would like to choose for our power supply. The following table shows a simple trade-off study between different batteries.

Battery: Weight: Rated Voltage: Capacity: Cost: Size: Discharge:
Ultrafire 18350 1200mAh 3.7V Unprotected Lithium Ion (Li-ion) Button Top Battery 20.9g 3.7V 1200mAh 4.95 35×18.5 mm N/A
6V Tenergy 1600mAh NiMH Side by Side Battery Pack with Hitec Connector 130g 6V 1600mAh 10.99 84x17x30.  mm 10C (10.6A Calculated)
Efest 18650 3000mAh Flat Top Battery – Purple Series 46g 3.7V 3000mAh 8 18.23×65.02mm 20A Continuous

System Block Diagram

By Mission, System, and Test Engineer Jeff Fuentes

The system block diagram displays how Spiderbot’s proposed inputs and outputs will function.  The 3DoT board can supply its own power, but it is not enough for all the peripherals we will be using.  Communication and telemetry will be handled by the 3DoT board consisting of the HM-10 Bluetooth LE module, an android phone, and the Arxterra app.  The motor outputs on the 3DOT board will drive two DC motors which will supply mechanical engery to a set of four legs each.  As dictated by the mission objective, Spiderbot will make use of a camera and harness/grappling mechanism via servo control. An external PCB will allow for further function if the 3DoT board cannot fully deliver.

3DoT Board Schematic

  1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/3DoT%20Datasheets/Block%20Diagram.pdf
  2. https://www.arxterra.com/3dot/

Fritzing Diagram

Mechanical Design

By Maunfacturing Engineer Daniel Matias

Our spiderbot will be based off the terrabot model and be built using 3D printed ABS plastic parts for our first rapid prototype. I will design the parts myself using solid works to have them 3D printer ready.

The body of the spiderbot will be large enough to house the 3Dot Board and two motors with gears to run the Theo Jansen walking mechanism for the legs.

Design and Unique Task Description

By Mission, System, and Test Engineer Jeff Fuentes

 

Nicholas Jacobs

  1. Research prospective sources for material/services

 

Jefferson Fuentes (Missions, Systems, and Test Engineer)

  1. Design potential schematic to begin fritzing diagrams
  2. Work in conjunction with E&C (P, Shaun) to analyze power requirements needed for motors and peripherals
  3. Begin decoding and designing Arxterra app.
  4. Conduct trade off studies concerning DC Motors alongside E&C
  5. Conduct trade off studies concerning our harness/grappling mechanism

 

Shaun Pasoz (Electronics & Control Engineer)

  1. Consult fellow Electronics and Control engineers to discuss parameters to implement a game to demonstrate 3DoT Board capabilities.
  2. Examine trade-off studies for various batteries and motors.
  3. Work on simulations for motor control through the Arduino Uno board to help limit decisions between motor choices.
  4. After choosing motor, stress tests on motor gear systems need to be conducted to detail the max current draw based on the weight of the robot.
  5. After deciding on proper motors, batteries, and control systems, conduct tests to analyze how long the battery can run on a single charge.
  6. Create a Fritzing diagram using parts from interface matrix
  7. After finalizing electronic layout, create a PCB layout using CAD software.
  8. Consult Systems Engineer to develop software subroutines to make the SpiderBot perform its tasks.

Daniel Matias (Manufacturing Engineer)

  1. Conduct trade-off study to determine which material will best suit our needs
  2. Begin designing and implementing 3D models to be potentially built
  3. Begin preliminary EagleCAD files to gain an idea of layout

 

Resources:

http://arxterra.com/preliminary-design-document-4/#h.pit64qv19iz

http://web.csulb.edu/~hill/ee400d/Documentation%20Lecture%20Series/04%20Preliminary%20Design%20Document.pdf

http://web.csulb.edu/~hill/ee400d/Lectures/Week%2004%20Modeling/c_Design%20Process%20and%20Modeling.pptx

Spring 2016 AdBot Materials Trade-off Study

/in , /by

By Muhammad Maqbool (Manufacturing and Design)

There are many different types of material we used to finish our final design. The body and the arms of our AdBot were made of aluminum of 0.125” thickness that we obtained from McMaster. The reason for using aluminum instead of plastic was the size of our body and we wanted a strong and reliable material—something that would not fall apart. It was impossible to 3D print the body of our AdBot. Our president Ryland had access to welding tools and drill press; he helped us put the body together and did a pretty good job with it and we ended up saving a lot of money. Our major concern after the body was put together was the weight. The body is strong but it is heavy.

For our 3D printing material, we went with ABS plastic because:

  • ABS is stronger than PLA
  • Cost less
    • Easy to use
  • Heat-resistant
  • Water-resistant

Source: http://www.makergeeks.com

Spring 2016 AdBot Final Project Documentation

/in , /by

AdBot Final Robot 2

AdBot is a robot that can drives around campus in place of a person passing out flyers.

Dang Le (Project Manager, Electronics and Control)
Don Tran (Mission, Systems, and Test)
Muhammad Siddiqui (Manufacturing and Design)

Table of Contents

Executive Summary

Program Objective
The project objective is to build a rover that will simulate a flyer distributor advertising CSULB’s Eta Kappa Nu social, guest speaker, and technical events on campus. Using a single power source the rover will launch from, and return to, an HKN advertisement booth and run in a general high foot-traffic area on campus which consists of flat areas, sloping areas, and stair ways, as shown in the course map. The rover will be controlled remotely using a computer with internet connection. Negotiations of budget resulted in the rover to cost less than or equal to $250. There is to be expected 0 to 16 mph wind during the course run on May 13th (Reported in Weather Report) [1].

Mission Profile
The perimeter of the grass is 275 ft / 84 m. The north and south sides are leveled. The east side has 9 steps. The west end is a ramp.

Figure 1 Test Course

Figure 1 Test Course

Level 1 Customer Requirements
1.1 AdBot shall travel at 4.55 ft/s at the pace of an individual delivering flyers.
1.2 AdBot shall follow CSULB Regulations for Activities and Advertising.
1.3 AdBot shall launch from the HKN booth and return.
1.4 AdBot shall operating with one power source.
1.5 AdBot shall be controlled remotely through Arxterra Control Panel.
1.6 AdBot shall go up nine steps of a staircase.
1.7 The budget shall be $250
1.8 AdBot shall protect its hardware from weather conditions on the day of the final.

Level 2 Requirements
1.1 AdBot shall turn at 84 rpm.
1.2 AdBot’s sign holder shall be within 3 ft.
1.3 The course shall be completed in 8 min.
1.4 AdBot’s current draw shall require 1000 mAh.
1.5 The Arxterra app can connect via bluetooth within 3 ft.
1.6 AdBot shall provide 25 kg-cm torque to straighten out.
1.6 The sign shall be 5.3 in. from the back of the chassis.
1.6 AdBot shall not bend at the motors or servos due to weight.

Design Solutions
Tracks instead of wheels make AdBot look military. They can drive over obstacles on the ground without getting stuck.

Prototyping

For the PDR, the chassis was built out of wood and 3D printed wheels. The 3D printed tracks had more tension in hopes that they do not fall off. The wheels had longer treads. AdBot was powered by battery. It moved with differential drive control and could drive forward, backwards, and turn. The tracks shifted on the wheels. The servos moved using an unsigned byte, slider from 0-90, custom command in Arxterra.

For the CDR, the chassis was built out of 6061 aluminum. The wheels were reprinted and prevent the tracks from undoing. The left side tracks moved together; the same goes for the right side.The motors were switched to higher torque ones and changed from 6 V to 12 V. Without a battery yet, AdBot was powered with a AC to DC wall adapter and wire. The geared motor to lift the arms was not finished.

Prototype

Motor Driver Trade-Off Study
The Arduino pins supply less than 0.040 A. The solution to drive motors is to find motor drivers. The trade-off study is in this link here.

Motor Trade-Off Study and Torque Test
DC motors are commercially available and offer choices. The motors have gears that changes thousands of rpm into hundreds. The motors of interest offer more torque force with decreasing speeds. Several motors are purchased and tested as stores do not claim the torque information or stall current. This link link has information.

Experiments
AdBot was taken to lab equipment to measure the motor specifications. Free multimeters have a 0.020 A limit. The torque test apparatus was used on motors. 1K, 5K, 10K, and 20K potentiometers could not stall the motors. The motor shafts were held onto a bearing by a screw and the bearing was attached to a wheel. This was done in order to provide grip to cause stalling. More information is here .

Subsystem Design

PCB Design
The custom PCB is a shield that fits on top of the Arduino Uno. It contains motor drivers to supply current to five motors. It features an HC-06 bluetooth module. The layout and schematic are in these links here and here. We made a through-hole PCB, but had to remake it into surface mounted.

AdBot Final PCB

AdBot Schematic

Arduino Software Code Design
The firmware folder has many files containing multiple functions. The commandDecoder receives information from the Arxterra app in the form of a command packet and authenticates it. It will then pass the data packet to commandHandler to distinguish out if this is a move operation or camera-related operation and whatnot. The Arduino code then passes the packet to a function that will work on it. move_TB6612FNG() receives a packet for driving. The code is in this link here.

Software Block Diagram

Software Block Diagram

Interface Matrix Definitions and System Block Diagram
A system block diagram and interface matrix are available so that this project can be replicated. They show the components that are used and wire connections. AdBot’s interface matrix begins displaying all the Arduino Uno’s pins and names. Components are placed in columns. When an Arduino pin is not vacant anymore, the row turns white to indicate that the next component cannot place a jumper lead in the white box. The table and diagrams are in linked here.

Interface Matrix Definition

Interface Matrix Definition

Hardware Design

There are many different types of material we used to finish our final design. We wanted to use strong and reliable materials. Material trade-off study is described in this page here.

Our project manager worked on the schematic and the manufacturing engineer put together the layout. One of the problems our manufacturing engineer faced while doing the layout was the positioning of the pins that will be connected directly to the Arduino Uno. Information about the custom PCB manufacturing is in this link.

Start out with understanding the basic design of AdBot. It consists of a total of eight big wheels, eight tension wheels, four tracks, two gears, one wooden shaft, one wooden pole, one pole holder, and one flat top. The design for the wheels and tracks are from previous semester’s RoSco. I modified them so that they work for AdBot requirements. Details about designing in SolidWorks is here.

Verification and Validation

Verification Test Plans
AdBot’s performance depends on the test plan. These plans show the requirements were considered and are kept when constructing AdBot. The table is linked here.

Verification Table

Validation Test Plans
The customer looks at qualitative features of the product built. Validation tests are done on the day of the final demonstration. The table is linked here.

Validation Table

Project Status

Mass Budget
Knowing individual masses lets the manufacturers know what components or materials to take out or replace. The allocated mass is based on the overall masses to stall the drive motors.

Mass Report

Power Budget
Power Report

Cost Budget

The construction of AdBot rover received a $250 budget. After the first few weeks, $100 was spent on breadboard parts and the chassis. The team has to keep track of our budget during the time building the project. Luckily we saved money and time on shipping due to our team purchasing Amazon prime. The project ended up with approximate $208 of spending—not including the PCB fabrication and SMD components. The cost of the end product is shown.

Cost Report

Project Schedule and Work Breakdown Structure

Project Libre was used to schedule the semester. The WBS illustrates the members’ duties in the schedule and pace to complete those. The depictions are shown

Schedule_1

Schedule_2

Final_BurnDown

The burndown line will not reach zero in software.

Schedule_3

 

Project Demonstration

Concluding Thoughts

AdBot is designed after a tank, and it is built from the ground up on a $250 budget. We ordered several parts from China to save several dollars. This mistake delayed our project for the CDR presentation. We spent a lot of our money during the design phase too on tools and parts to learn to use. With four weeks left and no electronics engineer to make a new schematic, the systems engineer, manufacturing engineer, and I worked extra overtime. The systems engineer had a difficult time writing and troubleshooting his C++ functions that receives commands from the Arxterra application. I was busy a lot in the project, because having one person working on manufacturing is not enough. Construction requires multiple heads to check, cut, drill, and build correctly. Everyone worked on software and tasks almost everyday for months.

The front motors at the end of the arms on AdBot are heavy. It places enough tension on the shaft to shake the servo around, which is screwed onto brackets. In this situation, the president helped us mount the servo securely. To make AdBot better, we should move the motors inside the chassis to drive the four front wheels. The tracks are too long to print on certain machines. The printed tracks took a long time to work on, but after printing, they do not come out as expected. On the final, we used metal tracks.

 

Resource Files

The system and software block diagrams are created using the full version of Shapes.

AdBot Video

CDR

PDR

Project Libre Schedule

Verification & Validation Table

SolidWorks Model Files

EagleCAD Schematic

RoSco Arduino Firmware

AdBot Arduino Firmware

AdBot Interface Matrix Definition Excel Sheet

Software Block Diagram

System Block Diagram

AdBot Bill of Materials

Spring 2016 AdBot Custom PCB Schematic

/in , /by

By Dang Le (Project Manager)

The PCB schematic for AdBot, made by the project manager, in figure 1 shows pin allocations with the integrated circuit components and the Arduino Uno.

AdBot Schematic

Schematic page 2

Schematic page 2

Figure 2. First L298P motor driver.

Figure 2. L298P motor driver.

The first L298P half bridge is the surface mount PowerSO20 component, which is not the Multiwatt15 breadboarding type so the pins read differently. The sense pins are grounded. They are not connected to 0.5 ohm 2 watt resistors for measuring the voltage and current draw. The device is manufactured with two no connection terminals. Vs requires inputing the power source, which is a 12 V battery. Vss is for inputing 5 V to keep power for logic.

Figure 2. L298P number 2.

Figure 2. L298P number 2.

Figure 3. L298P number 3.

Figure 3. L298P number 3.

 

 

 

 

 

 

 

Figure 4. Arduino Uno pins 8 and higher.

Figure 4. Arduino Uno pins 8 and higher.

The above image shows the header connection to the Arduino and the roles some pins are designed to have. Each half bridge has runs two motors, so they have a total of four input and two enable pins to connect to the arduino. JHIGH refers to pin number 8 up to SCL.

Figure 5. Arduino Pins 1 to 7.

Figure 5. Arduino Pins 1 to 7.

The above image shows the the remaining pins. JLOW represents Arduino pin number 1 to 7. The voltage divider connections to the bluetooth module. Analog pins are used to write digital highs and lows to the motor driver just as digital pins are capable of doing.

The project manager worked on soldering and troubleshooting the PCB board. He measured and tested the board for problems.

Spring 2016 AdBot Custom PCB Manufacturing

/in , /by

By Muhammad Maqbool (Manufacturing and Design)
Dang Le (Project Manager)

PCB layout was one of the hardest tasks to complete. We were left with no schematic. Our project manager worked on the schematic and the manufacturing engineer put together the layout. One of the problems our manufacturing engineer faced while doing the layout was the positioning of the pins that will be connected directly to the Arduino Uno. The dimensions for the pin placement were found online while keeping in mind the distance between Jlow and Analog should be 1.9”. The motors are placed on the right edge of the board so it is easy to connect or disconnect wires. All the capacitors are placed on the bottom right of the board so it is easy to put the components when the PCB arrives. We were not sure about the placement of the half bridges so the manufacturing engineer double checked it with the president and we ended up placing it between the pins that will be connected to the Arduino. They are kept close to the power source. For routing first I made a power bus of 0.18” and dragged it all the way down and then manually routed all the components that will be getting direct power from it. All the remaining wires are 0.016” thick. Source

Figure 1. PCB layout

Figure 1. PCB layout

 

Spring 2016 AdBot SolidWorks/3D Model Design

/in , /by

By Muhammad Maqbool (Manufacturing and Design)

Start out with understanding the basic design of AdBot. It consists of a total of eight big wheels, eight tension wheels, four tracks, two gears, one wooden shaft, one wooden pole, one pole holder, and one flat top. The design for the wheels and tracks are from previous semester’s RoSco. I modified them so that they work for AdBot requirements. The tracks are metal in the final design.

Figure 1. Full profile

Figure 1. Model front profile.

 

Figure 2. Chassis holes for the motors.

Figure 2. Chassis holes for the motors.

Figure 2 shows the body of AdBot and the dimensions are 12x8x2 inches with a thickness of 0.125 inch. The holes on the back side provide a path for the motor shaft to attach to the wheels directly. The holes have a diameter of 0.160 inch, which was measured using a Vernier caliper.

The diameters of the front side holes are 0.250 inch. They are openings for the shaft, which connects with arms and free-spinning wheels. The shaft has a thickness of 8mm.

Figure 3. Arm turning gear.

Figure 3. Arm turning gear.

Figure 4. Servo gear.

Figure 4. Servo gear.

Figure 3 shows the gear I designed for the shaft. The inner radius is kept to 8.5mm so that it sits on the shaft. I use a setscrew to screw the gear on the shaft to make sure it does not move from its position. Figure 4 shows the gear design for the servo and it is screwed directly on the servo arm. The two gears are kept close to each other so their teeth can overlap. When the gear on the servo moves, it moves the shaft gear with it, hence moving the arms up or down.

Figure 5. 3D track model.

Figure 5. 3D track model.

Tracks are one of the most difficult objects to be printed. The tracks around the arms have a diameter of 4.9 inches. The tracks in the back have a diameter of 9”. To increase the size of the tracks from 4.9” to 9” I increase the circular pattern in the SolidWorks file and then increase the length of the tracks while keeping in mind the gap between each loop, because the gap actually makes the track stretch when it is 3D printed. The problems I faced while printing the tracks was that the 9” tracks has more weight compare to the 4.9” tracks so they hang from the wheel rather than sit tight on the wheels.

Figure 6. Wheels.

Figure 6. Wheels.

All the wheels on our AdBot have a diameter of 2.5” with a thickness of 0.7”. The two wheels in the back connect directly to the motor shaft with mount couplings. There are four free spinning wheels on the shaft in the front (two wheels on each side) and one wheel on each arm.

Figure 7. Aluminum arm model.

Figure 7. Aluminum arm model.

AdBot comprises two arms, one on each side. The hole in the back is cut so it can fit onto the 8mm shaft and the hole in the front provides path for the motor shaft to connect directly onto the wheel. The arms are made of aluminum. The dimensions I chose are 6×1” with a thickness of 0.125”. I used a drill press to make perfectly aligned holes on the arms.

Figure 8. Tension wheels

Figure 8. Tension wheels

AdBot has eight total tension wheels. The purpose of tension wheels is to make sure the tracks do not slide off the wheels as experienced by RoSco. The diameter of the wheel is set to 1.5” so it could weigh less and I kept an empty space in between so the tracks can sit on it perfectly.

Figure 9. Exploded view of AdBot components.

Figure 9. Exploded view of AdBot components.

Conclusion:

The most difficult part for the 3D design in SolidWorks was the tracks. The design was complex and hard to understand. The tracks did not come out as I expected. 3D printing in general is difficult as the parts do not meet your expectations.

Resource File

SolidWorks Files

Spring 2016 AdBot Stall Current Test

/in , /by

By Don T. (Mission, Systems, and Test)

Experiments
AdBot was taken to lab equipment to measure the motor specifications. Some multimeters have a 0.020 A limit. The torque test apparatus was used on motors. 1K, 5K, 10K, and 20K potentiometers could not stall the motors. The motor shafts were held onto a bearing by a screw and the bearing was attached to a wheel. This was done in order to provide grip to cause stalling.

Stall Current

2016-05-09 11_21_27-PDR.pptx - Google Slides

Figure Torque Test Apparatus

Stalling a motor attached to a free running motor by grip

Figure Stalling a motor attached to a free running motor by grip

Figure Measuring no load current

Figure Measuring no load current

Figure Stalling the motor manually

Figure Stalling the motor manually

2016-05-09 11_53_41-PDR.pptx - Google Slides

The wheel torque equation is shown above as the force perpendicular to the wheel radius. To test the wheel torques, use the corresponding formula. Attach a mass to one motor. Apply the rated voltage to the motor and measure the height and count the number of revolutions. The data for torque data and constant current draw are shown here.

How to calculate the force of the wind

Start with a conservation of momentum model.

2016-05-09 12_00_53-Critical Design Review - Google Slides

p = pressure (Pa)

rho = density (kg/m3)

v = velocity (m/s)

x = distance (m)

p = static pressure, Ps = 0

(rho*v^2)/2 = dynamic pressure, Pd

c = total pressure

2016-05-09 12_03_21-How to calculate the force of the wind.docx - LibreOffice Writer

rho_air = 1.225 kg/m3

vw = 17.9 mph

The wind force is the product of dynamic pressure and surface area of an obstacle.

F_w = P_d * A_s

Fw = wind force (N)

Pd = dynamic pressure (Pa)

A_s = surface area (m2)

As AdBot is about to tip over, it loses full contact with the ground, except at one point. AdBot balances on this point and does not collapse left or right. Thus, the sum of the moments about this pivot is zero. The calculation to find where to put the beam on AdBot’s chassis is as follows.

Mw = moments (N*m) due to wind force on objects (wind against phone, sign, and beam)

MO = moments due to objects (phone and beam)

MO = moment due to AdBot’s chassis

Fw,x or y = wind force in the x- or y-direction relative to the earth (N)

xx = horizontal distance (m), which is parallel to earth, beginning from the single pivot point

Fy = object weight (N)

9.8 = gravitational acceleration (m/s2)

Fch = chassis weight (N)

alpha = tilt angle (°)

xch = half-chassis length (m), a.k.a. chassis center of mass

2016-05-09 12_05_31-Critical Design Review - Google Slides

m = mass

A = object’s surface area

l = object’s location of center of mass along the beam

alpha = tilt angle

z = distance from the chassis’s edge to the beam’s base making M_summation = 0

When M_summation is negative, the direction of rotation is clockwise relative to the three-axes drawn, and AdBot lands upright.

Wind Force Tool

Figure Wind force calculation setup

2016 Spring: 3DoT David Final Project Blog Post

/in , , , /by

By 3DoT David team:

Omar Mouline                                 (Project Manager)

Christopher Hirunthanakorn          (Missions, Systems and Test Engineer)

Kent Hayes                                    (Electronics and Control Engineer)

Andrew Saprid                               (Manufacturing and Design Engineer)

Table of Contents

Executive sumary

One of the 3Dot David project objectives was to build a small-sized spider bot that can walk using two motors. When the project was assigned to us, we did research on different movement mechanisms in order to choose the one that best suits our requirements. The research results can be found on this blog post: Spider Bot Different Mechanism Research

Project Objectives

The objective of 3DOT David Spider is to use scaled model of the Hexbug prototype to produce a cool project for the DIY community. The preferred method of control is to use Bluetooth communication between the remote-control (Iphone or Android) and the microcontroller on board of the spider The finished product must meet the following Program and Project Requirements:

  • System processing using a microcontroller (either the 3DoT Board or Sparcs Macro.)
  • Total production cost must not exceed $80.00.
  • Short 3D Printing ( Not exceeding 6 hours and less than 2 hours for each single print)
  • Control The Spider Bot from Arxterra app ( Android or Iphone) using bluetooth
  • 3Dot david must be able to perform a safe interactive game with other projects in a specific field and date as Defined in mission profile

Mission Profile

The Mission Profile for the 3DoT projects is to perform robotic combat. With regards to the College of Engineering Health & Safety Policy, the projects must meet the following Requirements:

  • The game will take place in ECS 315 in a 6 x 6 ft. area on the linoleum floor.
  • Go head to head with other robots in an indoor game of IR tag
  • The emitter must hit the detector in a straight line from a maximum distance of 5 ft.
  • Every time a player is “tagged” by the IR tagging system, a sound will go off
  • Delay time after each tag shall be 5 seconds
  • When either robot has been “tagged” 3 times, the bot will shut down, indicating the game is over.
  • The entire game will last from 10-15 mins

Updated requirements:
Program requirement:

  1. As a senior design project for Spring 2016, the project shall be completed by May 13th, 2016 Monday, May 9, 2016 2:45PM – 4:45PM (Final day) on the linoleum floor of ECS315 at CSULB.http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
  2. As a senior design project for Spring 2016, Documentation of the 3Dot Spider-bot shall be completed by the 25th of April http://web.csulb.edu/~hill/ee400d/Syllabus.pdf

Project Requirement:

  1. The 3DoT David shall be a robot that demonstrates the capability of the new 3DoT micro-controller for DIY hobbyists.
  2. The 3DoT David shall be a low cost project with a total cost that does not exceed $79.95, which includes the cost for 3D printing, PCB, battery, and other components.
  3. To document the difference between development cost and final product cost, the 3DoT spider project must create a Project Budget and a Product Budget.
  4. The 3DoT David shall be controlled by the Arxterra App used on a smartphone.
  5. The 3DoT David shall incorporate 3D printed parts to demonstrate the feasibility of the 3DoT board for 3D printed robots.
  6. The 3DoT David shall have a maximum 3D printing time of six hours for production of parts to ensure the quick production of the robot. Any single print cannot exceed 2 hours.
  7. The 3DoT David shall compete with other robots in a game of tag to demonstrate the functionality of the robot. The basic rules of the game are using an IR emitter to tag the opposing robot, must compete in a 6×6 ft area, have a delay period of 5 seconds after each tag, and be disabled for 10 seconds after three tags.

System requirements:

  1. The 3DoT David shall utilize the HC-06 Bluetooth module on the 3DoT board in order to receive commands from the Arxterra App using a smartphone.
  2. The 3DoT David shall use a single 3.7V Lithium-ion battery or a 3.7V Lithium-ion Polymer (LIPO) battery to provide power for the robot. The 3DoT board will be providing power to all of the peripherals and uses a 3.7 Lithium-ion battery as its power source.
  3. The 3DoT David shall use two micro motors for the movement system of the robot.
  4. The 3DoT David shall use an infrared LED emitter and infrared detector for the tagging system in the game of tag.
  5. The 3DoT David shall be disabled for 10 seconds after being tagged three times to signify the end of a round in the game of tag. This means the robot does not respond to any commands for 10 seconds.
  6. The 3DoT David shall operate for 10 to 15 minutes, which should be equivalent to three rounds of the game of tag.
  7. The 3DoT David shall use a small speaker to produce the buzzing sounds to indicate the end of a round in the game of tag.
  8. The 3DoT David shall use a 3D printed chassis and legs. This follows from the project level requirement about using 3D printed parts.
  9. The 3DoT David shall include a PCB that uses a Schmitt Trigger circuit to convert the analog output from the IR detector into a digital output to be handled by the 3DoT board. It will also have a voltage follower and anti-aliasing filter for the synchronization of the two motors. This PCB shall also provide the connections from the 3DoT board to the peripherals such as the IR emitter, IR detector, and micro motors.

Subsystem requirements:

  1. The micro motors shall operate in between the supply voltage of 3.7V-5.0V, be able to rotate 360 degrees continuously, have a stall current of no more than 250 mA, and cost no more than $10 each in order to stay within our budget.
  2. The 3DoT David shall be made from PLA or ABS filament in order to minimize the mass of the robot and be strong enough to hold its weight.
  3. The IR emitter and IR detector shall be positioned at least 3 inches from the bottom of the 3DoT David.
  4. The maximum distance for the IR detector to detect a direct hit shall be 5 ft. This threshold is for when the IR emitter of the other robot is directly aligned with the IR detector, not when it is at an angle.
  5. The spider-bot shall have six legs to operate its course to battle robots.

Project key features

Design Change

We have been working nine weeks to design the the Hex bug in Solid Work, in week 9 our team with the agreement of the customer decided to Change the design for these reasons:

The hex bug design:

  1. Had a lot of small parts that needed to be printed with precision
  2. It was very complex for a beginner in solid work to design without a professional formation and the right help.
  3. 3D print resource provided couldn’t print our small parts with the precision we needed.
  4. All the part for the design needed to be 3D printed which will be impossible to accomplish with the time restriction given by the costumer.
  5. We couldn’t use any option other than 3D printing to fit our budget.

The geared design:

  1. We were able to be creative and adjust the design to our needs.
  2. The gear movement need some adjustment since the prototype walked only straight. we added a motor to control each side of legs.
  3. By adding the motor we were able to compile the moment of the spider. When we turn off the right motor the spider turn right and vice versa.
  4. Less part to print and they all were able to print with precision
  5. We could of used different method like laser cutting to get some parts but the 3D printing time was enough for our requirements.
  6. The Solid work design level of complexity was little bit higher than the formation and help provided by the division for the manufacturing engineer but not as high as the level of complexity of the Hex bug design.

Tagging System (interactive game)

For the interactive game we had 3 options : Laser tag, IR tag, and Ultrasonic. After doing research on each option, we settled with IR tagging system for its safety. In the pictures below, some arguments about why we choose the IR are shown:

Screen Shot 2016-05-06 at 1.02.16 PM

Motor Control

After assembling the 3DoT David, we found that the motor synchronization is optional. The leg position helped the robot to move forward even if the motors are not in sync. Before that, we looked at different possibilities on how to synchronize the two motors and it is shown on the table below:

Screen Shot 2016-05-06 at 1.05.15 PM

We ended up choosing the Flex resistor. After implementing it to our robot we found that there is a slight improvement when the spider movement was more in sync. However, we decide to remove the flex resistor with the agreement of the customer because of the limited improvement and the limited number of pins available on the 3DoT board.

Innovative Design Solutions

In every step of assembling the 3Dot David, the team discovered issues. By brainstorming ideas, solutions are found and implemented into the design.

Design Evolution

With the solutions found, legs, bottom plate, and top plate are adjusted in Solidworks. By adjusting the parts, the 3Dot David will be able to move freely as it accomplishes its mission.

Design Evolution (for more details click here to go to the blog post) :

Gear Instability

Three tests were made in order to obtain stability for the gears moving the legs as it rotates. The first test was putting screws inside the center hole of the gears, but the screws were heavy affecting the motion of the gear. The second test was implementing white gears into the rapid prototype made of wood. The motors worked perfectly with these gears. However, the gears were too light, which causes concern when inserting the leg on the gear. The issue was solved by implementing extrusions on the testing board in the third test.

Gear Instability (for more details click here to go to the blog post): 

Joint Solution

In order for the leg to rotate freely, the joint must be lightweight plastic material. The joint was made in solidworks. The concern about it is that making a connection to secure the joint to the gear. A second solution was made by inserting a tube as a joint. However, there is much labor in sanding the tubes.  A joint solution is found by using one of the parts in the white gear bag for the legs to rotate freely.

Joint Solution (for more details click here to go to the blog post)

System Design

The system design for the 3DoT David is explained in detail in the following blog post. The system block diagram, interface definitions, and system resource reports are all presented there.

System Design (for more details click here to go to the blog post):

If you want to be directed to a specific topic in the system design blog post use the links below:

Trade-off studies

IR Trade-off Study

This study shows off the emitters and detectors relevant to our project according to specifications made by the electronics and control engineer. There is a table with the specs of emitters and a table with specs of detectors.

IR Trade-off Study (for more details click here to go to the blog post)

Servos and motors trade-off study

This trade off study was conducted in order to determine the best way to control our spider’s walking movements. There are brief descriptions of what motors and servos are, and how one may work better than the other for our project.

Servos and Motors Trade-off Study (for more details click here to go to the blog post)

Experimental Results

Leg Movement Angle Study

Calculations are done to find the distance of the final lift of the leg attached to the gear from the surface by using trigonometric equations. The leg must be lifted in order the spider to walk. If the leg is not able to lift, the spider is not going to walk. Thus, a blocker is created to make the leg lift as the gear rotates 360 degrees.

Leg Movement Angle Study (for more details click here to go to the blog post)

Gear Train

The gear train is an important mechanism for the 3Dot David that keeps it moving from place to place. Calculations are done to get the reasonable rotational speed of the gear by finding the gear ratio and using the given rpm of the motor at 120 rpm, or 2 cycles per second with the large gear.

Gear Train (for more details click here to go to the blog post)

Cam Simulation

The first prototype is made with a Cam Simulation simulated in Solidworks. Further details to every part are explained in the  CAM movement system.  However, the design proved to be complex, and it could exceed the 6 hour limit printing time. The CAM simulation had many mates and crashed because of it.

Cam Simulation (for more details click here to go to the blog post)

IR Lens Study

This study was conducted to determine a lens for increasing the range of the infrared emitter to meet the game requirement of 5ft. We will see the various types of lenses as well as calculations for the physics of light through lenses. The conclusion shows what

IR Lens Study (for more details click here to go to the blog post)

Motor Driver Control

This blog post explains how we controlled the motors from the sparkfun Pro Micro using the sparkfun TB6612FNG motor driver. It includes screenshots of the code being used with the sparkfun Pro Micro board to drive PWM signals for how fast the motors should rotate, as well as test functions for turning left, right, and reversing.

Motor Driver Control (for more details click here to go to the blog post)

IR emitter/detector testing

These are the test results of the IR tagging system done by connecting the schmitt trigger, BJT, emitter, and detector circuits. We show how the range is affected as we increase certain resistor values as well as the voltages being read from the output of the schmitt trigger and IR detector.

IR emitter/detector testing (for more details click here to go to the blog post)

3DoT Board motor Current Safety Test

Since there was a change with the mechanical design of our spider, there was the issue of the old motors not being able to rotate the new gears. Therefore we needed to search for motors that were strong enough to turn the gears. The solution to the problem was to use geared motors, which are motors with a gear train that reduces their speed while increasing the torque. However, with this increase in torque, there is also an increase in how much current the motors would demand. We conducted a comprehensive test to show that the current would not exceed 450mA, where the results are stored inside of tables.

3DoT board motor safety test (for more details click here to go to the blog post)

Subsystem design

Interface definitions

Final Interface Definitions 1 Final Interface Definitions 2

This matrix describes how each subsystem will be connected to the main controller (Atmega 32u4) and what those pins are referred to on each respective system. This is covered in more detail in the system design blog post.

System Design (for more details click here to go to the blog post)

Custom PCB Design

The PCB design includes a signal processing circuit, a BJT to drive current to our IR emitter, a speaker, and voltage buffers. Each circuit is thoroughly explained in the PCB design blog post 

PCB Design (for more details click here to go to the blog post)

Hardware Design

The Solidworks simulation folder has all the parts to simulate the 3Dot David. The adjusted parts for the Final David are the parts adjusted to solve issues as the team assembled it during the process.The mechanical design is explained in the link below:

Hardware design (for more details click here to go to the blog post)

The STL files are to be physically printed from Solid Work. The link below contains the zipped STL files:  

Final STL files (click here to access files)

Software Design

The software design for the 3DoT David is explained in detail in this blog post. It goes into depth about the individual modules and what the software has to do.

Software Design  (for more details click here to go to the blog post)

Additionally, the specific changes to the Arxterra firmware as the project progressed are covered in the following blog post. It provides information on the addition and removal of code to accomplish the tasks laid out in the software design blog post.

Arxterra firmware configuration(for more details click here to go to the blog post)

Verification and Validation Documents

In order to prove that the desired product was built properly and achieves its purpose, verification and validation must be done. The verification and validation matrices lists the requirements related to the tests that must be performed and their results. Those documents can be found here.

Verification matrix (for more details click here to go to the blog post)

Validation matrix (for more details click here to go to the blog post)

The verification and validation test plans provide all of the instructions for the tests to be performed and can be found here.

Verification test plan(for more details click here to go to the blog post)

Validation test plan (for more details click here to go to the blog post)

Project final status

The picture below shows The table of task and status of completion. The important tasks were taken from the project schedule presented already on the CDR and PDR, Those tasks were used to build the the project percentage completion graph and burn down graph.

Screen Shot 2016-05-09 at 12.31.34 PM

Completion %

The graph below show the average Vs. the actual completion percentage by week during the 16 weeks of the semester.

Screen Shot 2016-05-09 at 12.16.03 PM

Final burn down

The graph below show the average Vs. the actual task completion graph by week during the 16 weeks of the semester. As asked, when the teem start a task we mark it as 50% completed and when the task is completed we add another 50%.

From the burn down graph we can see that from week 6 to 8 our project was delayed because of issues of the old design. After week 8, we began working on the new design and we are able to recover the lost time.

Screen Shot 2016-05-09 at 12.06.07 PM

Previous Project Blog Posts:

The following Table of Contents blog post was created to organize all of the blog posts for our project and make it easier for future students to access resources related to their role.

All the blog posts made 2016 3DoT David spring semester by department (click here)

Concluding Thought

I found that the project manager position is the most stressful position in the 400D class since our grade is relies on the outcome of the project. But through this post. There were a lot of things that I had to learn on my own and I would have appreciated it if there was some kind of training plan for project managers. Additionally, I would have liked to be able to sit in on the training sessions for the other divisions, so that I could have a better understanding of what they were working on.

Issues encountered :

  • I would advise to choose the right design from the beginning of the semester: our project start was very stressful during the first 8 weeks and that was due to the design that was assigned to us. The mechanism and the shape design was complex for a beginner in solid works specially if they could not get any useful information, which i think it was the division manager part.
  • Improve IR range: It took both teams time to decide what type of tagging system to use between Laser, IR, LED and other than that the we couldn’t find a fast shipping for the lenses which delayed us more. We would have liked more time to test the IR tagging system before the due date
  • Size of the Spider: After searching different kind of gear, we decided to use gears that will give us durability and stability unfortunately they were a little big. If we were able to find smaller gears we would of reduced the size of the spider

If we went back in time, other than applying for a division manager position, i would have chosen to implement the Jerry Mantzel mechanism instead of the Hex Bug mechanism that was provided.

Resources links

  1. Project Video
  2. CDR Powerpoint
  3. PDR Powerpoint
  4. Project Libre File
  5. Verification Matrix
  6. Verification Test Plan
  7. Validation Matrix
  8. Validation Test Plan
  9. SolidWorks Files:
  10. Frizting Files
  11. EagleCAD Files
  12. Arxterra Firmware Code

Spring 2016 AdBot Motor Driver Trade-Off Studies

/in , /by

By Don T. (Mission, Systems, and Test)
Dang Le (Project Manger)

Motor Driver Trade-Off Study
The Arduino pins supply less than 0.040 A. The small Pololu motors with 120:1 or 200:1 gear ratio run on 0.120 mA and more. The result is to find motor drivers.

The motor drivers’ specification of interest are tabled. The integrated circuit selected is the L298N. It is feared that the L298N is not powerful enough. It works fine so far. The L6203 has built in diodes despite it can drive only one motor per device. The L298N needs external diode bridges. Get motor drivers with the diodes built in.

Motor Drivers Trade-Off

Motor Trade-Off Study (and Torque Information)
DC motors are commercially available and offer choices. The motors have gears that changes thousands of rpm into hundreds. The motors of interest offer more torque force with decreasing speeds. Several motors are purchased and tested as stores do not claim the torque information or stall current. The requirement calls for a motor with 84 rpm or more. The 6 V motors have a no load speed of 85 rpm. The torque of 5.4 kg-cm meant that the motors stall at 5.4/3.175  (for 2.5 inch diameter wheels) or 1.7 kg of force, which is 3.75 pounds. The mass of the 6061 aluminum chassis is and arms is 1.108 kg. This figure without the motors and other components added is close to the full load specification of the motor. Instead a 12 V motor is used in its place. The design has front and back motors. The front motors have 9.2 kg-cm and the back motors have 5.4 kg-cm. 25 kg-cm of torque is required to lift the front of a 3.75 lb. rover over a 11-cm step of a staircase.

 

 

Spring 2016: 3DoT board Motor Current Safety Test

/in , , , /by

BY: kent Hayes (Electronics engineer)

Introduction:

The recent purchase of geared motors has brought to our teams attention that the current they output under maximum conditions might exceed the limit of 450mA. In order to conduct a test to prove this to be true or false, we just needed both motors to be run at maximum voltage (5V) under the most extreme condition (motor stall) and measure the current going into the TB6612FNG dual motor driver. Prior to doing this we thought it would be a good idea to measure the current from each motor under normal conditions(gear load), no load, and stall currents at different voltages.

Requirement:

  • The provide a comprehensive test of the robot’s motor current draw that demonstrates that the current will never exceed 450 mA (both motors operating) under all conditions (including stall).

Tables of Results:

  • PWM = signal being fed into the motor driver. Higher PWM means more voltage for the motor
  • Motor terminal voltage= voltage output at the motor terminal

  • No Load current = Current going into the motor driver when there is no load

  • Gear Load current = Current going into the motor driver with the gears in place

  • Stall current = Current going into the motor driver when the gears cause the motors to stall

 

Motor 1 Test Results

 

PWM Motor terminal

voltage

 No Load

current

 Gear Load

current

 Stall

current
255 4.93V 25mA 36mA 192mA
200 3.87V 22.1mA 33.8mA 145mA
150 2.90V 19.5mA 31.2mA 124mA
100 1.92V 16.5mA 29mA 108mA
50 0.95V 13.4mA 26.3mA 97mA

Motor 2 Test Results

 

PWM Motor terminal

voltage

 No Load

current

 Gear Load

current

 Stall

current
255 4.93V 21.4mA 34mA 183mA
200 3.87V 20.5mA 32mA 137mA
150 2.90V 18.9mA 29mA 111mA
100 1.92V 15.1mA 27.5mA 90mA
50 0.95V 12.8mA 20mA 86mA

 

Motor 1 and 2 Max Characteristics

 

PWM Gear load

current

 Stall

current
255 49mA 420mA
200 60mA 300mA
150 69mA 150mA
100 61mA 125mA

 

Conclusion:

Looking at the last table, you will see that while both motors are on and max PWM signal is being applied, the current  going into the motor driver increased to 420mA. While under normal operating conditions, the current being supplied to the motor driver was 49mA.