Spring 2016 AdBot Software Design

/in , /by

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

The software block diagram shows the order that the firmware handles data and calls main functions.

Software Block Diagram

Figure 1 Software Block Diagram

Software/Firmware Design Details

In the arxrobot_firmware tab, edit just #define project TRUE. The loop() function basically calls commandDecoder(). The command tab is where the commandDecoder() function is written. It checks a command packet (several bytes of information from the Arxterra app for each kind of AdBot activity) if it is correct. It usually is; Editing the firmware does not require using CoolTerm and finding LRC byte. When the packet passes this decode checkpoint, the commandHandler() is called. This function determines what kind of operation the packet does. The packet could be for controlling a motor or moving a servo. Scroll down in the pinouts_robot tab and a list of robot operations are shown. Next to each operation is a hex value, which is equivalent to the packet’s third byte, which usually is thought of as data[2]. When the firmware is loaded onto the Arduino Uno, and the Arxterra app sends a packet to the Arduino Uno, the firmware looks at data[2], looks up the operation name in the pinouts tab, and finds in the command tab what function the operation name calls. These functions for example are move_TB6612FNG() and move_servo() and they are located in any of the available tabs. Arduino scripts that are moved to subfolders within the arxrobot_firmware folder are no longer part of the firmware code and will not load onto the Arduino Uno or show up when the arxrobot_firmware scripts open. Note: Arduino understands the compound addition operator “A += B” as a shortcut of writing, A = A + B.

AdBot Pinouts

The AdB1 tab contains functions to run the DC drive motors. The pinout connections the Arduino recognizes is listed below.

Motor Front Left

const int aIn1 = 2;
const int aIn2 = 4;
const int aPWM = 3;

Motor Front Right

const int bIn1 = 7;
const int bIn2 = 6;
const int bPWM = 5;

Motor Back Left

const int cIn1 = 8;
const int cIn2 = 9;
const int cPWM = 10;

Motor Back Right

const int dIn1 = 13;
const int dIn2 = 12;
const int dPWM = 11;

Servo

const int SERVO_1 = A0;

move_TB6612FNG and run_TB6612FNG functions

An L298 half bridges has two channels to control two motors separately. With each channel, Arduino connects to a first input pin (C), a second input pin (D), and an enable pin (Ven). When the enable pin is written to low, the corresponding motor is free running. When the enable pin is written to high, the motor can move forward, move backwards, or stop.

 L298N

Resource Files

The software block diagram is created using the full version of Shapes.

Link 1 Software Block Diagram.shapesdoc

Link 2 RoSco Arduino Sketches

Link 3 AdBot Arduino firmware

Spring 2016: 3DoT David System Design

/in , , , /by

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

Introduction:

The purpose of this blog post is to summarize the work done on the system design of the 3DoT David and show the final state of the system block diagram and system resource reports. At the end of this blog post, the reader should understand the different subsystems of the 3DoT David, how they interact with each other, and what parts were chosen for each subsystem. The interface definitions matrix is also covered here.

Table of Contents

System Block Diagram

 CDR System Block Diagram(1)

This system block diagram shows how all of the subsystems of the 3DoT David interact with each other. The major subsystems are the smartphone with ArxRobot App, 3DoT Board, PCB, battery, IR emitter, IR detector, micro motors, gear train, 3D printed legs, and flexible resistors. The interaction between the subsystems will be explained below.

The smartphone with the ArxRobot App is the subsystem that the user will be interfacing with the most. The user will be controlling the movement of the 3DoT David by using the directional pad controls on the app. Those inputs will be sent to the 3DoT Board via bluetooth. It will be processed by the Atmega 32u4 microprocessor that is on the 3DoT Board. If there is any telemetry, it would be sent back to the smartphone but that is not the case for the 3DoT David.

The 3DoT Board interacts with both the PCB and micro motors. It will be sending the control signal for the IR emitter and speaker to the PCB while receiving the outputs of the IR detector and flexible resistors after the processing is done on the PCB. The 3DoT Board also contains the Sparkfun dual motor driver TB6612FNG, which drives the micro motors. The board receives power from the battery.

The PCB contains the Schmitt trigger circuit which converts the analog output of the IR detector into a digital signal for the 3DoT Board to analyze using hysteresis. It also contains the circuitry for powering the IR emitter and speaker. It also contains the voltage follower and antialiasing filters to prepare the outputs from the flexible resistor sensors for the 3DoT Board to process in the motor phase control module of the software.

The IR emitter is controlled by the signal sent from the 3DoT Board and is powered via the circuitry on the PCB. It sends an IR signal in an attempt to tag the opposing robot. Both the IR emitter and IR detector make up the tagging system of the 3DoT David.

The micro motors are controlled by the Sparkfun dual motor driver TB6612FNG and move the gear train of the 3DoT David. The gear train is connected to the 3D printed legs and moves when the gear train moves. The movement of the 3D printed legs will move the entire 3DoT David and is used as the input of the flexible resistor sensors.

Interface Definitions:

Final Interface Definitions 1

Final Interface Definitions 2

This interface definitions matrix shows how the various subsystems will be connected to the pins of the Atmega 32u4 microprocessor. The HC-06 bluetooth module will be connected to pins PD2 and PD3 which corresponds to the TX0 and RD0 pins of the bluetooth module. The Sparkfun dual motor driver TB6612FNG will be connected to pins PD7, PB5, PB6, PC6, PF7, PF6, and PF5, which corresponds to the PWMB, PWMA, AIN2, AIN1, STBY, BIN1, and BIN2 pins. The control signal for the IR emitter is connected to PD1 and that goes to the PCB. The IR detector output is connected to PD0. The speaker is connected to pin PB7.

System Resource Reports:

These are the system resource reports for the 3DoT David. The only major difference since the CDR is that the micro motor has been changed from the 3.7V 50K RPM coreless motor to the 900 RPM Micro Geared Motor.

Power Report:

Final Power Report

This power report shows the updated values after changing from the 3.7 V 50K RPM coreless motor to the 900 RPM Micro Geared Motor.

Mass Report:

Final Mass Report

This mass report shows the measured mass of all components used to build the 3DoT David. It can be seen that the measured mass is 62% of the total expected and 50% of the project allocation. This was achieved by using the most efficient design for the 3D printed parts, which reduced the printing time and overall weight of the parts.

Cost Report:

Final Cost Report

This cost report shows both the expected costs for parts that were generated during the PDR and the actual cost of the parts that were selected. All of these prices incorporate the shipping fees for those parts. The total actual price listed is assuming that all of the parts listed will need to be purchased and does not include the cost of the 3DoT Board.

 

Spring 2016: 3DoT David Software Design

/in , , , , /by

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

Introduction:

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

Related Level 2 Requirement:

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

Table of Contents

Software Flow Chart


 CDR Software Flow Chart

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

Software Block Diagram

CDR Software Block Diagram(1)(1)

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

CommandDecoder Module

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

CommandHandler Module

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

Move Robot Module

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

Motor Phase Control Module

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

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

IR Emitter On Module

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

Tag Tracker Module

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

Robot Disabled Module

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

Telemetry Module

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

Implementation of modules

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

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

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

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

The final version of the Arxterra Firmware (click here)

 

Spring 2016 AdBot System Block Diagram and Interface Matrix Definition

/in , /by

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

A system block diagram and interface matrix allow people to replicate the project. 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.

Figure 1 Interface Matrix Definition

Figure 1 Interface Matrix Definition

Figure 2 System Block Diagram

Figure 2 System Block Diagram

Resource Files

Link 1 AdBot Interface Matrix Definition Excel Sheet

The system block diagram is created using the full version of Shapes.

Link 2 System Block Diagram.shapesdoc

Spring 2016: 3DoT David Design Evolution

/in , , , /by

Introduction

The design has changed for the last couple weeks. By assembling the 3Dot David, problems and issues occurred, and had to be adjusted, especially for the bottom plate, legs, and top plate.

Related requirement:

As part of the level 2 system requirement follows:

The 3DoT David shall use a 3D printed chassis and legs. This follows from the project level requirement about using 3D printed parts.

Table of Contents

3DoT David plates design evolution

Bottom plate design evolution

Bottom Plate 1

The bottom plate below had some problems because the extrusion cuts made on those 10 holes. Placing the connection for the gears on those holes with the screw made the gears unstable and loose. In addition, the plank below on the right had to be super glued to the bottom of the bottom plate for 24 hours to cure. Some of the planks were easily broken off by drilling a hole on the bottom plate with the plank attached it. In the gear instability blog post on testing #1, this proves that the screws on those gears were interfering with the movements of the gears.

Chasis

Plank

 

 

 

 

 

Bottom Plate 2

In solving the problems occurring in the 1st bottom plate, planks were then attached to the bottom plate. Gear instability was an issue. So making extrusions on the bottom plate, instead of extrusion cuts solved the issue of gear instability and movement of the gears. The holes on the bottom plate were made because the printing time exceeded 2 hours. With these holes, the printing time was exactly 2 hours.

bottomplate1

Bottom Plate 3

The holes made on the bottom plate was not quite nice. So, “V” shaped extrusion cuts are made because they reduced less printing time, makes the design look nice. The two extrusion cuts are made for the new gearbox motors to be placed right at the bottom of it.

 

bottomplate3

 

Bottom Plate 4

This is final design of the bottom plate. This is tested and assembled  by the team. The changes made here are the 10 extrusions, where the gears are to be placed, to be 1 centimeters. The reason is the washer will be placed first, and then the gear will be placed second for it to freely rotate. In addition, securing the gears in place was an issue. To solve the issue, the use of the soldering iron will burn the 6 extrusions, where the large gears are placed, as it will form a surface that will secure it in place. Those semicircle holes are made to reduce the printing time, which came to exactly 2 hours. The motors are then attached to the bottom of the plate with a extra hole to secure the gearbox so that the motor does not move.

bottomplate4

Top plate design evolution

Previous top plate 

The previous top plate measures to be 7 cm width and 12 cm length in order to fit the PCB and the 3Dot board on it. Each hole on each corner will connect the bottom plate with spacers and screws.The team thought of the battery on the 3Dot board because it can produce amount of heat to the top plate, which could melt it.
TopPlate

Final top plate

The final top plate is the same dimensions as the previous top plate. The only changes to it are making extrusion cuts in order to prevent the heat of the 3Dot board and PCB from touching the top plate. A hole is made so that the IR tube is screwed into it. Cables from the motor will go through the hole mentioned in the below figure. An extra extrusion cut is made to see the gears move for everyone to see.

FInal_top_plate
3DoT David legs, femur and tibia design evolution:

Legs design evolution

Leg 1

 

As the team assembles the 3Dot David, connections that were made with the tibia and femur were blocking the movement of all the other legs. As a result of the tests that were made, the team decided to change the leg design to make sure there are no interferences with the movement.

legs

Leg 2

By making it as one piece and centering the tibia, no interferences will be made on the movement. However, it could not be printed because the height of the tibia was too high at 6.8 cm.

leg1

Leg 3

By making separate pieces of the leg, which are the tibia and femur, 3D printing will make it easier because the parts have a flat surface. The extrusion cut was made for the connection of the screw at 0.265 centimeters. Super glue will be added to secure them in place as it walks on the floor.

tibiafemur(2)

 

Femur design evolution

Previous Femurs

The previous femur had trouble stabilizing its weight as it walks. By attaching all the six femurs, it was not able to balance because of the 4 legs attached to the corner gears. However, this femur will be implemented into the middle gear of the gear train.

femur

Adjusted femurs

With these two adjusted femurs, theoretically, the 3Dot David will not have trouble walking. The femurs would help it balance as it walks.
Adjusted_leg_femur_2Adjusted_leg_femur_1
Implementing the femurs

By implementing the femurs into the bottom plate, the spider will balance itself, according to the figure below.

femur_positions

Tibia design evolution

Adjusted tibia

 

The tibia had to be adjusted by adding 1.5 centimeters to 5.3 centimeters of the previous tibia. That is because the gearbox on the bottom of the bottom plate was almost touching the surface. By adding it, 6.8 centimeters is the length of the tibia that will solve the issue.

adjusted_tibia

Conclusion
 As the team solved issues with the bottom plate, legs, and top plate by assembling and testing them, the design evolved in that process. Costs and time took a lot in the process. However, the evolution of the design is an experimental process towards finding the final design by making extrusion cuts to lessen the printing time as well as making the design beautiful and stabilizing the spider by adjusting the femurs and bottom plate.

Spring 2016 AdBot Critical Design Review

/in , , , /by

The Rover should travel on level area, ramp area, and stair ways during the mission test.

Critical Design Review

By Dang Le, Project Manager

  • Dang Le (Project Manager)
  • Don Tran (System Engineer)
  • Muhammad Ali Siddiqui (Electronic Engineer)
  • Muhammad Maqbool (Manufacturing Engineer)

Executive Summary

Program Objective/Mission Profile

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).

Mission Profile

The total distance is approximated in 344fts. 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.

Mission-CDR-72dpi

The front of USU building

The Design

The main component in our rover design are including

  • Four drive motors (2 on the front and 2 on the back).
  • One gearbox motor (for the center).
  • Six wheels and tracks.
  • Two arms with supported by horizontal shaft and gear.
  • Pole holder for advertising and smart phone.

Adbotexplosive-72dpi

Project Features

  • Rover with advertising sign will be traveled up stairs and slope area in front of USU building.
  • Rover will be run and return to HKN advertisement booth in a single charge.
  • One shaft  with high torque gear box motor to support the lifting arms weight during the stair climbing.
  • Operator will be controlled remotely using Arxterra application with computer wifi connection.
  • Innovative wheels design to have a better track grip.
  • New aerodynamic body design to reduce weight and wind resistance

Custom PCB Design

Fritzing diagram circuit with three H-bridge and I2C protocol IC to drive five motors with using Arduino and firmware coding.

CDR-Frizing-72dpi

Fritzing Diagram

 

Custom-PCB-72dpi

Breadboard testing transmit and received data with using H-bridge IC circuit and Arduino coding.

 

PCB layout

PCBlayout-CDR-72dpi

 

Hardware Design

By Muhammad Maqbool, Manufacturing Engineer

The body of our AdBot is set to be 12” x 8” x 2”. The Body is made of Aluminum. I got separate sheets of Aluminum each with a thickness of 0.125 inch and I welded them together with the help Ryland Walts. The reason for choosing Aluminum is that for our AdBot we wanted a strong body that would not get damaged if our AdBot hits the stairs or anyone try to kick it.

The body consist of two holes in the back each of a diameter of 0.16 inches, the holes provide a path for the driving motors to directly connect with the wheel. The two holes in the front of the body provides a path for the shaft to pass through and will be connected to the free moving wheels and arms.

The wheels are printed using ABS plastic. ABS plastic is the most cost effective material. Each Wheel has a diameter of 2.5 inches and a thickness of 0.7 inch. The arms of the our AdBot will be of Aluminum as wheel, the arms will be 6” x 1” with a thickness of 0.125 inch. We have two motors in the front of the arm that will be driving the front wheels at all times. I have designed the gear for the shaft and the motor myself. As the motor rotates the gear on it rotates with it hence rotating the gear on the shaft and lifting the arms. I have designed two arm holder myself that will hold the arm on the shaft at all times.

The top of our AdBot is more aerodynamic by adding curves to it so it can go fast. The top is 12” x 8” and will sit on the body and I will screw them both. I will design a pole holder that will hold our pole hence holding our sign.

Adbot-topview-72dpi

top-CDR-72dpi Demension-CDR-72dpi

Software Design

Test code for controlling motors with Arxterra Application

SW-CDR-72dpi

SW-master-Slave-CDR

 

Project Update

By Dang Le, Project Manager

Work Breakdown Structure (WBS)

As a project manager, who created and assigned tasks for each member within the team throughout the project. A work breakdown structure (WBS) that showed each of team member who had responsible for their tasks. There could be a change during the mission task depend who has more free time and ability to take workload from other member. Here is our delegation tasks that showed in display below.

WBS-CDR-72dpi

Budget Report updated

As a Project manager, I have to keep track on our budget to make sure it still within our given budget. The most expense is on prototype component and chassis. Unfortunately, our rover were bigger compare to previous semester, thus we have to look for the difference type of tracks that can support our rover during the mission test course. First, we thought we could use 6V DC motor for our rover ( these motor are free from previous semester), but now due to the rover is too heavy and may not be able to travel on stair ways and long distance, so we may replaced with 12V DC motor for final demo. Our budget report with expected cost right now without five of 12 V DC motors is $220.44.

Cost-report-CDR-72dpi

 

Schedule Updated

Project schedule is the software that used to create a task schedule and plan in this project for a specific date to be completed. As the project moved on, we could see which tasks we were completed or behind the schedule. The schedule showed in green check mark that indicated these tasks were completed. However, the main concern was the PCB schematic and PCB wiring layout. We have built a new schematic, which more complicated than our thought due to more parts on PCB and not enough clearance between one trace to another, thus our team member were having so much trouble when doing the layout. Furthermore, we were down by one of our team member electronic engineer. Thus, we were behind the schedule as our planned. Another issue was main tracks for our rover. The current track we have as the same last semester that was not support enough for our rover during the mission test. We are still looking for the tank track and 12 V DC motor with high torque for our AdBot.

ProjectSchedule1-CDR-72dpi ProjectSchedule2-CDR-72dpi

 

Status and Percent Complete

Here is the status and percent burn down  as we move along until this time. The charts showed that we were behind on software coding, PCB layout, and hardware as well.

PercentcompleteCDR-72dpi BurnDownCDR-72dpi

Project Demonstrations

click the link below to watch the AdBot demonstration

https://www.youtube.com/watch?v=CX5fDNFeUjc

 

 

Spring 2016: 3DoT David IR Trade-off Study

/in , , , /by

IR Emitter/Receiver Study

Introduction:

This is an overview of the trade-off study conducted for the selection of our IR emitter/receiver system. We will being going over the characteristics of each component that were taken into consideration while gathering information, as well as solutions to creating the ideal IR system. In addition, there is a link in the resources section that we used to understand the datasheet specs.

Note: There were no actual specifications for the IR system. The following results are what we believe to be the most optimal for our project.

Emitter:

Ideal Characteristics:

  • The IR emitter we choose should have low input voltage (2V~3V) to consider low power consumption
  • As narrow a beam angle as possible (10 degrees ~ 20 degrees) for increased accuracy
  • Cost efficient for DIY hobbyists ($0.75 ~ $2.00)

Results:

IRTradeOff_SFH 310_BlogPost

Screen Shot 2016-05-04 at 10.22.34 PMFig. 1: Table of appropriate IR emitters)

Receiver

Ideal Characteristics:

  • The range should not be greater than 2m (6ft) in order to meet the subsystem reqirements.
  • Wide directivity (receiving angle) around 100 degrees ~ 180 degrees so it can be hit from all angles
  • Cost efficient ($0.50 ~ $2.00)

Results:

Screen Shot 2016-05-04 at 10.22.01 PM

(Fig. 2: Table of appropriate IR receivers)

Conclusion

  • On the emitter side, it would be wise to consider using the SFH4545 because it has a beam angle of 10 degrees, can handle up to 1A (motor driver goes up to 1A), has an average current of 100mA, only needs 1.5V for supply, and is only $0.62.
  • On the receiving end, the best choice would be the TSMP77000 because it has the lowest range of all the receivers (5m), has a wide directivity (100 degrees), and is only $0.69.
  • There is a helpful link in the resources section that explains how to create your own lens tube for improved accuracy and range.

Update:

Kent was given a SFH310 for the detector and a NTE30047 for the emitter in order to test how each component was working. The beam angle is a bit wider on the emitter he was given but it will work fine for our game of tag when combined with a lens. The purpose of the lense is to increase the overall range and increase the accuracy of the emitter. See the IR/Emitter blog post to see my research on the effect of lenses on IR emitters.  The lenses have yet to arrive, but when they do he will begin testing to see if the range increased and determine what the voltage rating is at the further distances.

Resources:

Understanding Diode Ratings | http://www.allaboutcircuits.com/textbook/semiconductors/chpt-3/diode-ratings/

DIY Laser Tag |  http://www.lasertagparts.com/mtoptics.htm

 

Spring 2016: 3DoT David Blog Posts Table Of Content

/in , , , /by

BY: Omar Mouline ( Project Manager)

Project Manager (Omar Mouline)

  1. Spider-Bot Preliminary Research Project.
  2. Spider-Bot Preliminary Design Document.
  3.  Spider-Bot Mechanism Research: When we design was assigned to us i did a little research on other mechanism to better understand the leg movement.
  4.  Blog Posts Table Of Content: All the blog posts link with a summary to faster access information.
  5. CDR Debrief: After the CDR we were given the grades and asked to
  6. Executive summary: Project objective, mission profile, and design change arguments

Electronics and Control Engineer (Kent Hayes )

  1. Spider-Bot Preliminary Research Project.
  2. Spider-Bot Preliminary Design Document.
  3. Servos and Motor Trade-off Study: Research and trade-off studies on different motors servos to make sure we made the right decision.
  4. IR Emitter/Detector Testing: Fritzing and connection of the IR system and test.
  5. IR Lens Study: since the IR emitter have a big range we had to use a lens to reduce the range of the IR emitter.
  6. PCB Design: PCB design for our Project.
  7. Motor Driver Control: we needed a motor control drive to control our motors.
  8. IR Trade-Off Study : trade of studies on different IR emitter detectors possibilities.
Missions, Systems and Test Engineer (Christopher Hirunthanakorn)
  1. Spider-Bot Preliminary Research Project.
  2. Spider-Bot Preliminary Design Document
  3. 3DoT Board Troubleshooting: Installing software and testing and verification.
  4. Spider-Bot IR Transmitter and Receiver Research:  Research on how the IR transmitter detector work.
  5. Arxterra Firmware Configuration: Firmware how to connect the 3DoT board to an iPhone or Android

Manufacturing and Design Engineer  (Andrew Saprid )

  1. Spider-Bot Preliminary Research Project.
  2. Spider-Bot Preliminary Design Document
  3. Spider-Bot Alternative Printing for Small Parts: Research Made on different possibility on how to manufacture our design.
  4. Spider-Bot Cam Simulation: simulation of the first (Hex bug) Cam design.
  5. Gear Instability : we were able to find 2 type of gears on Amazon we test and tried both.
  6. Rapid Joint Connection (Between Gear and Leg): As part of the adjustment we had to do to the new design , we had to add a joint to our design.
  7. Simulation and New Design Parts simulation of the final design movement.
  8. Printing Time: The printing time show the options we have to respect our printing requirement.
  9. Gear Train: study and what RPM we need to receive 2 cycle per second.
  10. Leg Movement Angle Study: What angle we need so our spider legs can give us a correct walk.
  11. Design Evolution: how Brainstorming helped to improve our designs.

Spring 2016: 3DoT David Executive summary (Design Change Arguments)

/in , , , /by

BY:

Omar Mouline                                    ( Project Manager),

Christopher Hirunthanakorn          (Missions, Systems and Test Engineer)

Table of Contents

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 show some arguments why we choose the IR:

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 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 different where the spider move was more in sync.

 

Spring 2016: 3DoT David IR Lens Study

/in , , , /by

By:  Kent Hayes (Electronics and Control)

Introduction:

The way we currently have our set up for the IR emitter/detector, the maximum range is about 3in. In order to meet this requirement, Kent researched and found a way to drastically increase the range by incorporating a lens. Kent previously purchased 11.3mm lenses for our IR emitters. He chose this size for the diameter based on the limited space with which we have to work. We were thinking of creating a tube and mounting it on the side of the PCB box (3in x 2in) that we were going to print. However, there was a change in the design of the legs which pushed our printing time over the 6hr limit so we will not be using the box, and will therefore be mounting it somewhere on the top plate.

Related requirements:

The subsystem requirement states the following:

  • 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.

Lens options:

There are various types of lenses of which to choose from such as convex, concave, spherical, and compound.

  •         Convex: causes light rays to converge/concentrate into one spot
  •         Concave: causes light rays to diverge/spread out
  •         Spherical: less focused the wider the beam angle
  •         Compound: Increasing the focus while decreasing image distortion(aberration)

The lens that will work the best for our project is the convex lens since I wish to focus the IR beam as narrow as possible while increasing the range. There are different types of convex lenses as well. Among these are the more popular plano-convex and asymmetric double convex lenses because they produce the least amount of aberration. There is no notable difference between the two for this application, so I purchased the plano-convex.

IR_LensCalculations_LensChoicesI did further research online in order to preform calculations that would work with the measurements I do have thus far. The following image is of calculations I found on the magnification (M) in relation to the distance projected from the lens to a wall (dScreen)and the distance from the LED to the lens (dLED).

IR_LensCalculations_FL_M_dLED

I followed the formula to calculate the magnification factor with the following values:

DScreen = 2m (Requirement for the IR emitter to be able to fire from 2m away)

DLED = 5mm (Random number just to do calculations)

With these I calculated the mag factor

M = 2000mm/5mm

M = 400

With the mag factor, I can then calculate the focal length of the tube.

Flens = 2000mm/(400+1)

Flens = 4.98mm

I also tried using a larger value for DLED to see what would happen to the focal length

M = 2000mm/10mm

M = 200

Flens = 2000mm/(200+1)

FLens = 9.95mm

These results suggest that my focal length should be between 5mm and 10mm.

In order to get an exact value for the focal length, I did further research and found a helpful link that dealt with the focal length as well as the diameter of the lens. The following Image is of what I found:

IR_LensCalculations_DiameterOn the webpage I found this picture, it listed a formula for determining the minimum lens diameter. It is as follows:

D = 11.3mm lens diameter

F = focal length

Θ = 40 (half angle intensity of the current emitter we are using)

D > 2*F*tan(Θ)

11.3mm > 2 * F * tan(40)

F < 6.73 mm

 

Conclusion:

From the calculations made, we will be making a lens tube with a focal length less than 6.73mm with 11.3mm in diameter. In order to determine your focal length, you will need to use the half angle intensity of your own emitter and the diameter of the lense you have bought.

Resources:

Diameter/Focul Length Calculations | http://alumnus.caltech.edu/~leif/infratag/lens_choice.html

Magnification Calculations | http://physics.stackexchange.com/questions/146956/how-to-chose-right-lens-for-concentrating-ir-signal

Types of Lenses Summary | http://micro.magnet.fsu.edu/optics/lightandcolor/lenses.html