Spring 2018 3DoT Hexy: Power Estimate of Micro Metals

/in , /by

By: Kris Osuna (Electronics & Control Engineer)

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

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

We obtained two unidentifiable DC motors from Professor Hill’s resource cabinets. Current and Voltage measurements were obtained using an Arduino Uno and INA3221 Breakout Board. Measurements were taken with a load that is half the weight of 3DoT, 66.3g, and the gears in motion. We purchased two DFRobot FIT0481 micro metal gear motors and began our testing.

Components Needed

  • Scale
  • 3DoT David
  • 3 micro metal gear motors
  • INA3221 breakout board
  • Arduino Uno
  • Opto-Reflective switch
  • 2 NPN transistors
  • Resistors 100, 200, 1k
  • Process Control Student Guide by Parallax INC

Related Requirements

  • The micro metal motor must be able to turn six gears
  • The motor must be able to work in the 3.7-5V range
  • The motor must have an RPM of at least 360 with a 66.3g load

Setup

A riser was placed on the scale and tared so that we can weigh 3DoT David shown in figure 1. 3DoT David weighs 132.6 grams. There are two micro metal motors used so each motor will have a load of 66.3 g. The original motor inside 3DoT David was removed. The motors were connected to the INA3221 breakout board to measure current with no load. Set up can be seen in figure 2. RPM was calculated by using the opto-reflective switch to read the black marked paper on the sheet attached to the motor shown in figure 3. The motor spins the attached piece of paper, which is half black and half white. The opto-reflective switch has an IR LED and phototransistor which is able to differentiate the black and white part of the paper. Each count means a full rotation was achieved. The motor shaft was marked black and recorded for 10 seconds then played in slow motion to confirm that the opto-reflective switch readings were correct.

The motor being tested replaced the motor inside 3DoT David. This is done so that the gears moving would be part of the load. The motors are connected to the INA3221 breakout board to measure the current while dealing with the load. RPM was calculated by using the opto-reflective switch to read the black on the sheet taped to the gear attached to the motor. The gear attached to the motor was marked, recorded for 10 seconds and watched in slow motion to confirm the opto-reflective results were accurate.

Figure 1: 3DoT David Weight

 Figure 2: Current Measurement

Figure 3: Calculating RPM 

Figure 4: Full RPM measurement set-up

Figure 5: Current measurement with load

Figure 6: RPM measurement with load

 

Results

Table 1: Measurements of cabinet motors at 3.7 V

Table 2: Measurement of cabinet motors at 5 V

Table 3: Measurements of our purchase motors 

 

The following graph is for table 3 which uses the purchased micro metals that will be used on 3DoT Hexy

 

Graph 1: Results from our purchased motors graphed

 

Analysis

The purchased motors stall at around 3.4 V with a load, because of this it means that we cannot use the 3.3V pins on the Arduino Uno board. The 3DoT board can provide 3.7V to our motors. We are waiting for 3DoT Hexy to be 3D-printed to decide whether we will need 3.7V or 5V power to our motors. Once we find the full weight of 3DoT Hexy with all the sensors attached we should run another power study. The new power study will be more realistic because 3DoT Hexy will be moving and have all the sensors workings. If 3DoT Hexy can take the full load without the motors stalling at 3.7V we would only need one buck booster for the UV LEDs.

 

 

Resources

Figure 7: Micro-motors from resource cabinets

Figure 8: Purchased Micro-motor

  1. Code for INA3221 Current Sensor
  2. Motor Load Test Presentation
  3. EE370L_Manual
  4. Purchased micro metal motors

Spring 2018 3DoT Hexy: Determine Gear Design

/in , /by

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

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

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

     Since we are going to base our design of Spring 2016 3DoT David, we will need to implement a functional cam system that is either similar or better in design then that constructed by the Spring 2016 team. In this blog post we will: go over current gear ratio from existing 3DoT david cam system, determine the cam system design for Hexy, potential driving and driven speeds for our design (based on motor selection), go over the gears we will use , and implementation.

Related Requirements

  • To keep cost down, and keep a toy aspect , the robot shall use only 2 micro motors to drive the movement of the robot.
  • The robot will need to navigate remotely through a custom built maze (built by AoSa image), memorize the path it took, start over, and autonomously travel through the path it took.
  • The robot shall operated in a tripod form, having three legs (2 outer in one side and middle leg in the other side) to provide stability while moving.

Update (March 15, 2018)

We decided that pursuing a 3:1 configuration would be the way to go. This is due mainly to the femur-to-gear joints. 20T gears have a smaller surface area over which to place joints that need to be made bigger based on assembled prototype.

Trade study (March 6, 2018)

3DoT David’s Cam

     Since we were given access to the 3DoT David robot and their blog post research, we were able to analyze the design more in detail. The manufacturing department even went the extra mile to model gears from the robot on solidworks by measuring the pitch diameter, outer diameter, tooth thickness, addendum, dedendum, pressure angle and face width using a digital caliper (click here for meaning of these variables). Below is a model of 3Dot David cam system:

Figure 1: Current cam design 

The gear ratio for 3DoT David’s cam is 3:1. The small gear has 10 teeth with a pitch diameter of 10 mm and the big gear has 30 teeth with a pitch diameter of 30 mm. The driving gear (where motor connects) is the lower left blue gear. According to, Spring 2016: 3DoT David Gear Train , 3DoT David is designed to drive the larger gears at 2 rev/sec, therefore, the driving speed of the motor should be 360 RPM. The 3DoT David team decided that it would be best to use geared motors rated at 450 RPM at 6V and use a booster shield to reach 5 V to get to 360 RPMs for the input gear (click here to read more on how they determined this motor choice). A video of 3DoT David cam performance can be seen by clicking here .

The cam system we will use

So far two potential cam designs are going to be used to experiment on. The first one will be 3DoT David’s 3:1 configuration, and the second one will be a 2:1 configuration shown below:

     Figure 2: Alternative design

For this configuration we would use small gears with 10 teeth and large gears with 20 teeth. Since gears sizes are scaler, modeling 20 tooth gears from 10 tooth gear, generated above, was not an issue. The reason for using this configuration is that it would reduce length of 3DoT Hexy by 6 mm from 3DoT David design, and reduces length of femurs that would connect to the red gears. This document will be updated when we determine the configuration we go with for our cam system.

Required Driving and Driven Speeds for our design choice, under ideal conditions

Note: Driving Gear (G1) = small gear connected to motor.

Driven Gear (G2) = large gear used to move legs.

 

For the most part we want our robot to rotate its legs anywhere between 1 and 2 rev/sec. Therefore we will calculate speeds for 1 and 2 rev/sec for 3:1 cam system, and 2:1 cam system, both shown above. Calculations were done using Gear train document as a reference from wikipedia.

Note: G1 speed = Wa, and G2 speed = Wb

Na = teeth on G1, and Nb = teeth on G2

Figure 3: Calculation for different cam configurations 

The Gears we will use

There are two methods of obtaining gears for our cam system: buying or fabricating gears. After consulting with Prof. Hill over the possibility of fabricating gears, Hill recommended we just pursue purchasing gears. Therefore, the manufacturing department went on a hunt for purchasable gear sets. Taking into account that we need gears with 10, 20, and 30 teeth to model our two configurations and the source material on gear instability done by the 3DoT David team we found the following two gear sets on Amazon:

Figure 4: Out sourced gears 

Both sets have the desired pitch diameters of 10, 20 ,and 30 mm. The advantage of picking Set 2 is that it will be the same gear set that 3DoT David used.

In case these gears don’t work, we always have the gears the manufacturing department accurately created from scratch using solidworks for CNC cutting:

 

Figure 5: Gear generated in Solidworks 

Note:

These gears cannot be found in Solidworks libraries. These models were accurately obtained by determining the pitch diameter, outer diameter, tooth thickness, addendum, dedendum, pressure angle and face width using a digital caliper and using 3DoT David’s Gears as a reference.

 

Files for these gears can be found below:

Gears

How final design would look with legs connected

3:1 System:

Figure 6: One side of assembled cam 

This design will be mirrored along the vertical axis and femurs will be positioned in opposite order of the ones above: outer legs in an middle leg out to have 3 legs on the ground at all time for balance (tripod).

Note:

2:1 system will have the femurs connected to the red gears and would be positioned in the same way as above .

Conclusion

Currently we are more interested in pursuing the 3:1 cam system for our design, however, we will attempt to model the 2:1 system to see if it would be better for our design instead of 3:1. We will update this document after the rapid prototype has been made modeling both gear designs. From this blog post our E&C was able to determine motor selection based on the gear calculations above. We will be using a 530 RPM at 6 V high torque micro gear box motor, will see RPM rating at 3.7 V (battery rating) and determine whether or no we need a boost shield to drive the cam system at the desired RPM.

Resources

  1. https://www.arxterra.com/3dot-david-gear-train/
  2. https://www.arxterra.com/3dot-david-rapid-gear-instability/
  3. https://en.wikipedia.org/wiki/Gear_train/

 

Spring 2018 3DoT Hexy: RGB Color Sensors

/in , /by

By: Kris Osuna (Electronics & Control Engineer)

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

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

   A RGB sensor is going to be needed to allow 3DoT Hexy to detect intersections. A different color will be placed at every intersection to allow our robot to know the type of intersection.  We will be using the RGB Light Sensor – ISL29125 to get values from printed paper.

Components

  • Arduino Uno
  • Light Sensor – ISL29125

Related Requirements

  • Light sensor must be able to tell the difference between colors

Update 2: (March 20, 2018)

 

     Color sensors will no longer be implemented for our projects due to a customer revision of the maze definition. According to the customer, since we plan on using UV sensors for our line following design, it would be more optimal to implement intersection detection using a UV grid (as shown in the maze definition). Also color sensing was out of the question for robots like biped or velociraptor whom would have difficulty reading RGB due to required placement position.

Update 1: (March 8, 2018)

Setup

We used the RGB Light Sensor – ISL29125 (figure 1) to get values from printed paper. The sensor was zip tied to a ruler to detect values from 1 inch away (figure 2). We obtained the red, green and blue values and recorded the range that appeared. In the software we added the red, green and blue values and found the average. The table is arranged from lowest average to highest average to show which color would be the most beneficial to use.

Results

Table 1: Sensor Values 

Purple, blue, red and yellow would be ideal to use due to the difference in averages making it harder to confuse each other. If you use the average as a data point the sensor can tell the difference between the colors since none of the color averages overlap.

Figure 1: Left – RGB color sensor ISL29125

 

Figure 2: Set-up for measurements

Resources

  1. RGB Sensor Datasheet
  2. Light Sensor Code

Spring 2018 3DoT Hexy: Decision of Movement Mechanism

/in , /by

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

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

     Taking into account the level 1 requirement of using only 2 micro motors to drive the movement of the robot, and by using designs from previous semesters as a reference. We as engineers had to determine the most optimal mechanism that would take full advantage of the 2 micro motors. References, such as that of  Spring 2016: 3DoT Spider-Bot Mechanism Research, pretty much covered the most promising designs to implement using 2 motors. However, we decided to focus more on the two models that were successfully built in the past: the Klann Linkage mechanism of Spring 2017’s Spiderbot, and the Hex Bug 2 mechanism Spring 2016. The goal we wish to accomplish by picking from the former or the latter is to:  reduce the amount of time invested in researching new designs, increase the probability of success, and invest more time building on improving existing designs.  

Related Requirements

  • To keep cost down, and keep a toy aspect , the robot shall use only 2 micro motors to drive the movement of the robot.
  • The robot will need to navigate remotely through a custom built maze (built by AoSa image), memorize the path it took, start over, and autonomously travel through the path it took.
  • The spiderbot shall have an allocated budget of $250, however to compete with the existing robot toy market we shall try to minimize the cost of production as much as possible.  
  • In order to minimize manufacturing cost, and packaging cost the robot shall be able to be constructed from subassemblies within 10 minutes.
  • For quick production of the prototype, the preliminary project shall be restricted to six hours of total printing time with a 2 hours limit for each single print.

Design 1: Spring 2017 SpiderBot, Klann Linkage Mechanism

Figure 1: Klenn Linkage Mechanism 

     Eight legged Klenn linkage spiderbots follows a 4 inner and 4 outer rule for stability.  This means that the spider will always have 4 points of contact: Case 1: outer legs lift and inner legs thrust, and Case 2: inner legs lift and outer legs thrust.

Pros:

  • Parts can be fabricated using laser cutter, reducing our 3D print times
  • Design will have 8 legs like an actual spider due to the need of bilateral symmetry
  • Design can be implemented using 2 motors
  • Can turn in place if programmed correctly

Cons:

  • A lot of parts will increase weight of the robot
  • The width of the robot will need to increase in order to fit 3DoT board and all components in the middle.  

 

A lot of resources on this model can be found online. Below are links to a couple of useful references on the Klann Linkage mechanism.  

  1. How it works
  2. Two Motor controlled Klann Linkage mechanism that can turn
  3. Going over objects
  4. Movement Dynamics
  5. Sample model built from start to finish

 

Design 2: Spring 2016 3DoT David, Hex Bug 2 Mechanism

 

Figure 2: Hex Bug Mechanism

 

This design can be accomplished using a cam system and by configuring the legs to move either as:

Shown above:

Case 1: Outer 4 legs lift, inner 2 legs thrust

Case 2: Inner 2 legs lift, Outer 4 legs thrust.

Design requires small lift height, in order to reduce time outer legs remain of the ground for stability.

 

Or:

can be reconfigured by adjusting the position of the legs on the gears to follow a tripod motion(as shown below).

Figure 3: Tripod Movement 

This was what Spring 2016s 3DoT David design had to do, click here.

 

Pros:

  • Design looks simple, not as many parts compared to Klenn linkage model
  • Can be designed to be small and compact because 3DoT board and other components can be placed over the mechanism without interfering leg movement .
  • Can turn if properly programmed, as demonstrated in the Spring 2016 video.
  • Can be driven using only 2 motors  
  • A lot of components can be made with either 3D or laser cutter.
  • Uses only 6 legs which reduces weight and cost of manufacturing.

Cons:

  • Leg to floor clearance during lift will be small, therefore, won’t be able to go over big objects

 

Resources:

  1. https://www.arxterra.com/spring-2016-3dot-spider-mechanism-research/
  2. http://robotics.hobbizine.com/knexapod.html

Final Design Decision

     Having had studied both design more in depth we decided that implementing the Hex Bug 2 design was the way to go. The Hex Bug 2 design takes advantage of gears configured as a cam system to provide sufficient torque to the legs for movement. This will reduce amount of 3D components needed since we will most likely be able to purchase gear set from an online retailer. Also this design only requires 6 legs meaning we will have less weight and less 3D printed parts to worry about. The only components that will most likely need to be 3D printed will be the femurs, and tibias. The chassis will most likely be laser cut. Since we need to fit the robot in small maze rooms, current maze rooms are  3’’x3’’, the Hex Bug 2 design allows us to make everything small and compact because we can place the 3DoT board and other components on a platform over the gear mechanism without interfering leg movement. The issue of floor clearance during lift won’t be an issue because going over objects is not a mission requirement.  

 

Spring 2018 3DoT Hexy: Improving 3DoT David Design

/in , /by

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

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

     Since we decided to model 3DoT Hexy of Spring 2016’s 3DoT David, Prof. Hill recommended that we get in contact with the owner of 3DoT David to have access to the robot. Luckily, we were able to get in touch with the owner and were permitted to use the robot as a reference. From 3DoT David, we have learned a lot about: movement dynamics, overall dimensions, and weakest points in the structural design. In this blog post we will highlight the weakest points in the structural design of 3DoT David and provide solution that will be implemented in our design of 3DoT Hexy.

Related Requirements

  1. In order to minimize manufacturing cost, and packaging cost the robot shall be able to be constructed from subassemblies within 10 minutes
  2. For quick production of the prototype, the preliminary project shall be restricted to six hours of total printing time with a 2 hours limit for each single print
  3. The robot shall be designed in such a way that there are no dangling or exposed wires and the final fabrication is pleasing to the customer
  4. To keep cost down, and keep as a toy aspect , the robot shall use only 2 micro motors to drive the movement of the robot.
  5. The spiderbot shall have an allocated budget of $250, however to compete with the existing robot toy market we shall try to minimize the cost of production as much as possible.

Gear Capture System

     According to Chris (one of the engineers behind 3DoT David) 3DoT David’s cam system has a tendency of “gear popping”. This means that at high speeds the gears tied to the shafts slip off. To solve this problem the 3DoT David team relied on melting the tips of the shafts to prevent the gears from lifting. This also was a problem for the gears tied to the motors which could not rely on the previous solutions do to having a steel shaft. This solution solved the gear popping problem, however, it complicates the mission task involving assembly and disassembly. Below are images of how it looks:

Figure 1: Old gear capture design

Caps for gear shafts

Figure 2: Gear Capture solution

      To solve this problem we decided to use caps obtained online from a different gear set. The caps have a diameter of 3.2 mm which will be the diameter of the shafts we will use in order to ensure we have a tight fit without heating or gluing. This will make our cam system easier to assemble and disassemble.

 

Top shaft to prevent gear tied to motor from popping:

Figure 3: Old design: Nothing prevents the gear from popping off

Figure 4: Gear capture solution for driving gears

We will incorporate a shaft positioned over the driving gears that will be part of the 3D print of the top panel. This will keep the driving gear from coming off.

Gear to motor shaft connection

     3DoT David relied on gears that have a bore greater in diameter than the shaft diameter of the motors. The solution the 3DoT David team used to solve this problem was to insert a piece of a pen tube into the bore to provide a tight fit. The problem with this solutions is that there is no real mechanism that locks the gear to the shaft to prevent the gear from slipping from the shaft.

Figure 5: Old driving gears Motor shaft held to gear bore via the use of a cut piece of pen tubing.   

Figure 6: New driving gears 

     The motor shaft has a D shaped shaft, therefore using a gear with a D shape bore would lock the gear to the motor shaft. Luckily, our manufacturing engineer was able to find gears that have the 10 mm pitch diameter for our driving gears with a smaller bore, as shown above. This means that we can cut out the D shape using a dremel tool or other precision cutting tool.

Lift Mechanism

     3DoT David’s Lifting mechanism works well in thrusting and lifting the spider forward, however, the amount of lift of the current design is proportional to the length of the femurs. Since we want to reduce the overall width of our robot (to give it a better aspect ratio relative to a 4”x 4”  maze room),  figuring out a way to reduce the length of femurs while providing an acceptable amount of lift is desirable. 

 

Figure 7: Old leg design, note: units = cm

Solution:

     We decided that integrating the lift mechanism into the femurs of the legs would give us more control over the lift angle (since it will be based on the angle of the contour we define), as well as reduces the width of the robot since femur lengths can be reduced and will eliminate the need of the protruding lift mechanism. As an added extra, we also expect to see reduced 3D print times for the femurs.

 

     Our solution involves re-designing the femurs and the base to have a guide that will increment the angle of the femur as the femur rotates outward, providing lift. How it works:

Figure 8: Gear-to-Femur relation

     At point A the femur should be touching the floor and preparing for thrust. At point B, the femur begins ascending. At point C the femur is at its peak lift. At point D, femur is descending.This solution enables us to control the lift of the legs based on the angles of the femur contour. The guide that the femurs will follow will also have an angle to provide a smooth transition from point A to point C. As shown below:

 

Figure  9: New leg design 

     As can be seen above, the length the leg extends is 31.69 mm from the chassis, compared to 3DoT david’s 38mm leg extensions our leg design will reduce the overall width of the robot by 2*(38mm – 31.69mm) = 12.62mm. Our legs will have a lift distance of 5.56 mm which is 1.24mm less than 3DoT David Design. Also note, the top panel will have a protrusion that will keep the legs down when they are in there innermost point to keep them grounded as can be seen by the image above in the upper left corner. The height of our robot will be 28.28mm vs 38.1mm therefore our design will be 9.82mm lower meaning we should have a better reading for our sensors.

     Below are the calculations for our leg’s profile. Note, calculations for determining our leg profile were obtained from Spring 2016 3DoT David Leg Movement Angle Study.  

Circumference of femur tied to gear:  

C = 41.54 mm

Initial Lift do to inner contours:

7.89 deg – 3.59 deg = 4.3 deg

sin(4.3) = x/41.54    

x  = 3.12 mm

Final Lift Obtained = 11.92 deg

41.54 mm * sin(11.92 deg) = 8.58 mm

8.58 mm – 3.12 mm = 5.46 mm of lift of the ground

 

From our actual results, we can see that our design is .1 mm of the actual Lift.

If we wished to modify the height clearance of our design we would just change the value of the initial lift by changing the angle of the leg contours.

Leg Joints

      3DoT David’s leg joints where not a pretty sight to the eye. Since the design relied on a single contact point for the femur to tibia joint, 3DoT’s joints would loosen and become flimsy as the robot walked. The solution the 3DoT david engineers had was hot gluing the joints to make them stick together better (as shown below). However, this beats the purpose of the assembly and disassembly portion of the mission. To solve this problem we decided to redesign the leg joints to have more contact points.

 

Figure 10: Old legs and femurs 

 

Figure 11: New leg design

     By implementing this design, we had to redesign the tibias to give the joints 5 contact points. This will make the joint more sturdy. To prevent the joint from being a flexible joint, we will thread the hole the hole shown in the image above and insert a screw across to prevent the joint from moving the femur and tibia.

Wire Management

Purpose: Provide a path for wires from top panel to bottom panel that does not protrude out of the robot or interferes with cam movement.

 

Figure 12: Old design -Wires are wrapped in electrical tape and are susceptible to interfere with gear rotation.

 

Figure 13: New design

      Wires will have an isolated passage from top to bottom panel through two different apertures. Both holes will will have an 8 mm diameter opening giving plenty of space for all wires that will be connected to components on the underside of Hexy.  

Redesigning top and bottom panel

      We will be re-designing the top and bottom panel to accommodate new design changes made from old design review. We will also take this opportunity to give Hexy a unique appearance different from that of 3DoT David, and try to improve on reducing 3D print times.

 

Figure 14: Old design

Figure 15: New Design

      For the bottom panel we will fit gear lift guides into the chassis instead of having them stick out like in 3DoT David’s design (as explained in the lift mechanism section). We will extrude cut patterns in top and bottom panel to reduce 3D print times while at the same time giving our design a symmetric and appealing view. Top and bottom panel will have holes for the wire management and for the driving motor connection. The design will have more holes upon determination of the position of the custom PCB board, battery, and 3DoT board

 

Adding Washers

Figure 16: Adding washers 

     3DoT David didn’t see the need of adding washers to reduce friction, however we will incorporate washers along with grease in order to reduce friction between the gears and the chassis.

 

References

  1. https://www.arxterra.com/spring-2016-3dot-david-design-innovation/
  2. https://www.arxterra.com/3dot-david-rapid-gear-instability/
  3. https://www.arxterra.com/3dot-david-rapid-joint-connection-between-gear-and-leg/
  4. https://www.arxterra.com/3dot-david-leg-movement-angle-study/

3Dot Advanced Lab

/in , , , /by

In the “Blink” example the frequency at which the LED blinked was controlled by the calls to the delay function. In this lab a potentiometer is used to increase and decrease the duty cycle of an external LED. Concepts introduced in this lab include wiring an external circuit to the 3DoT I2C connector, plus Arduino […]

Read more

Custom Commands – Bluetooth Communication

/in /by

By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

One of the many benefits of working with the Arxterra App is the ability to create custom commands and communicate with your robot over Bluetooth. Although many of the necessary commands have been predefined there is still plenty of room to create custom user defined commands to make navigating and controlling your robot a breeze.

In this blog post we will examine the MOVE command which will allow the user to control the robots speed and orientation using the D-Pad on the Arxterra App. We will walk through how to set this up step-by-step to ensure that future semesters can focus on other aspects of their project.

Parts Required

  • Wheels with electric motors (Pathfinder has 6)
  • Motor Driver (Pololu VHN 5019)
  • Microcontroller (Arduino Mega2560)
  • Bluetooth Device (HM-10)
  • Android or iOS Device with Arxrobot App (iPhone 6)
  • Power for Electronics (12V Lead Acid Storage Battery)
  • Robot3DoT Library

Step 1: Physical Connections

First and foremost, you will need to wire everything up, that is motors to motor driver(s) and motor driver to the microcontroller. This can be done by looking up the data sheet for your specific motor driver and wiring accordingly. Also, you will need to connect your Bluetooth device to the microcontrollers serial port as well ensuring that TXD -> RXn & RXD -> TXn.

Step 2: Downloading the Arxterra App

In order to gain access to the Arxterra App you will need to get in contact with Jeff Gomes. The app is available for both android and iOS devices, however, it is easier to get the app onto an android device. There is one additional step when it comes to installing the app on an iPhone. Since the App store is a little bit more selective as to what they offer, the Arxrobot app is still considered to be in beta testing and you will need your specific Apple user ID to get access.

Step 3: Import the Robot3DoT Library

This is where you will find a lot of the code that will make your life a million times easier. This library can be found here. In order to import this library you will first need to download the library, leaving it in its .zip format. Once you have downloaded it you can import it into the Arduino IDE by opening your computers file folder and dropping that file into the library file within your Arduino folder.

Step 4: Including and using the Robot3DoT Library

After you have imported the library you will need to open a new script within the Arduino IDE. Now you will want to include this library in the sketch you have created and you should see at the top of your code the library include statements. If you would like to get a better understanding of how the code works you can view the libraries by finding them in the Arduino folder under libraries and selecting the libraries .cpp file. This can be very beneficial as you can make sure this code works for your specific purpose and if not then you can make modifications as needed.

Now you will need to insert the following lines of code to be able to use the command handler properly. All of these are entered before your setup code.

  1. Robot3DoTBoard Robot3DoT; // Instantiate as Robot3DoT at end of class header
  2. const uint8_t CMD_LIST_SIZE = 1; // total number of custom commands
  3. void moveHandler(uint8_t cmd, uint8_t param[], uint8_t n);
  4. Robot3DoTBoard::cmdFunc_t onCommand[CMD_LIST_SIZE] = {{MOVE,moveHandler}};

 

  • Note that for custom commands you will need to define the specific ID for that command. For example, the MOVE command is already associated with ID 0x01 and does not need to be redefined.

Within the setup code you will want to insert the following:

  1. Serialn.begin(9600); // This opens up the serial port that your Bluetooth device is connected to.
  2. Robot3DoT.begin(); // This is a predefined setup function within the Robot3DoT Library
  3. Robot3DoT.setOnCommand(onCommand, CMD_LIST_SIZE);

 

In the main loop make the call:

  1. Robot3DoT.loop();

Now you’re ready to write your command handler functions. The MOVE function already has functions that are associated with it but you are able to write your own functions if you’d like. For our purposes we wanted a simple move function to control it’s direction at a specified speed. The directional pad has four buttons: up, down, left and right. They all have their own unique ID associated with them and by processing the data sent to the Arduino we can assign their values accordingly. For example:

Figure 1: Implementation of a command handling function, Credit: Mark Huffman

Step 5: Verify Bluetooth Connection

This is perhaps the most troublesome step. When I was setting all this up I could not seem to get any sort of communication with the app and the Arduino. After wasting hours of changing serial ports, examining the libraries and looking up troubleshooting methods I discovered three key issues.

  1. The HC-06 device we had from a previous semester was defective. I discovered this while looking up troubleshooting methods. A simple way to determine if your device is defective is by creating a “transmission loop”. This is done by shorting the RXD and TXD pins on the device and making sure it is turned on (If it doesn’t even turn on that’s your first clue). Download the free app Bluetooth terminal on your iPhone or Android and connect to it. Once you are connected you can send the device ASCII characters and it should send back exactly what you sent. If you are getting no response then your device is most likely defective.

 

  1. There are different kinds of Bluetooth technology. iPhones only operate with BLE communication whereas Androids can use a variety. If you plan on using an iPhone to control your robot make sure you have an HM-10 or HM-11 device to connect to. Also, make sure that within the Arxrobot app phone configuration settings you have selected the proper Bluetooth connection.

 

  1. For some reason the Arduino Mega will not allow you to upload code if you have Bluetooth connected to the Serial port. In which case I moved the Bluetooth to the Serial1 port. Since I changed the serial port physically and not within the software there was no established communication line. Let this be a reminder to make sure the serial port you are using is being called within the code otherwise this can be a nightmare.

 

  • Hopefully future semesters can learn from my shortcomings and not have to struggle with this aspect of their project.

Step 6: Drive Around or Something

Now that you have setup Bluetooth communication, defined your motor functions and wrote the code to establish communication between the app and your device you can literally do anything you want from blinking an LED to autonomous GPS navigation. Just know that all of your commands are going to be in this type of format and you can extract whatever information you want and do with it what you will.

References

  1. https://www.arxterra.com/goliath-fall-2017-app-setup-and-remote-control-user-guide/
  2. https://www.arxterra.com/goliath-fall-2017-custom-telemetry-custom-commands/

Spring 2018: BiPed Work Breakdown Structure

/in /by

By: Miguel Gonzalez (Project Manager & Manufacturing)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Work Breakdown Structure

For project BiPed, the group consisted of three members fulfilling the roles of Project Manager, E&C, MST, and Manufacturing Engineer. Since the group consisted of fewer members than the positions to fill the manufacturing role of the team was given to the Project Manager.

The diagram below shows the workload of the project and how it is distributed among the team. It is based on the job descriptions and shows major tasks that each person is responsible for. We will be taking a look at each team members role more closely to better understand the structure of the team and its workload.

Fig.1 BiPed Work Breakdown Structure

Miguel Gonzalez (Project Manager)

Fig.2 PM and Manufacturing Engineer Tasks (Blue)

At the top of the WBS in blue, we have the project manager section. Note that in our case the project manager is also the manufacturing engineer and thus the tasks for both roles are given to the same person. The second blue icon shows the tasks specific to the project manager which has the project manager responsible for the following tasks:

  • Creating and managing schedule
  • Creating a budget list
  • Creating the preliminary report
  • Creating the final blog post
  • Creating project video
  • Define Work Breakdown Schedule

The manufacturing tasks given to the project manager are listed to the right side of the WBS also in blue. These tasks are broken down into three sections Mechanical Design, 3D Modeling, and Assembly. These sections were created based on which tasks are needed to be done before moving on to the next section. For example, Mechanical Design is a prerequisite for 3D Modeling and Assemble thus it is located on top of the other tasks.

Jeffery De La Cruz (MST)

Fig.3 MST Tasks (Red)

Moving on to the left side of the WBS (in red), we have all the tasks assigned to the MST engineer. Once again, these tasks are divided up into three sections System Designs, Software, and System Tests. The system designs include tasks that have a focus on research and trade studies that will end up helping with the software development and system test. Once those tasks are done the MST engineer can proceed with implementing the software with the Arxterra control panel and onto an android application. The final tasks for the MST engineer focus on verifying and testing all sections of the robot to see if they are operational.

Jorge Hernandez (E&C)

Fig.4 E&C Tasks (Green)

The final branch in the WBS applies to the E&C engineer and his tasks needed for a successful project. The E&C has the greatest responsibility for the success of the robot becoming operational. His roles are divided into 4 categories Electronics Design, Experiments, Microcontroller, and Control. These categories cover a wide range of taks that need to be realized to proceed with the overall goal of the Biped project which is stated in our preliminary design blog post and here.

Spring 2018: Biped Fabrication Methods (Trade-off Study)

/in /by

By: Miguel Gonzalez (Project Manager & Manufacturing)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Related Requirements

L1-3: Micro FOBO will have 2 legs.

L1-4: Micro FOBO will be a toy robot based on the design of the FOBO by Jonathan Dowdall.

L1-18: Micro FOBO shall be able to traverse cloth, paper, and linoleum materials.

Introduction

When thinking about manufacturing our robot we looked at the many fabrication methods available that we could use to create the BiPed. Of course, the list of ways we can manufacture our robot can be endless, but we made sure to focus our research to limit this list. Our goal for this study is to list the most feasible methods of fabricating our robot and compare the pros and cons of each method. The top three most feasible fabrication methods we could implement on our robot was sheet metal folding, laser cutting, and 3D printing. This blog study will look at each method mentioned to see the benefits and disadvantages of incorporating them into our design. Below you can find our study and the results we arrived when conducting a few tests.

Sheet Metal Folding Method

Fig.1 Sheet metal folding example

The first fabrication method we looked at was sheet metal folding which is a process of getting thin metal sheets and cutting them into specific shapes that would be folded to produce a three-dimensional shape. This shape can be a servo mount, 3DoT casing, robot feet, and so much more. Sheet metal folding is cheap and is a good way to produce sturdy parts rapidly without much effort. One of the drawbacks of this method is that complicated designs are almost impossible to produce. Accurately measured pieces are hard to produce and making exact copies of parts that share the exact dimensions are nearly impossible to make using this method. These drawbacks are too big to ignore especially when we plan on creating a robot that requires precision measurements and complicated design.

Laser Cutting Wood

Fig.2 Laser cutting example

The next fabrication method we consider was laser cutting. Laser cutting is a very niche fabrication method for hobbyists but has been gaining traction in the recent years. With the laser cutting method, you can use various materials for your builds such as sheet metal, plastics, and even wood. This method of fabrication utilizes the precision of a powerful laser to cut material into a predefined shape. This means that you can achieve very accurate and precise cuts. Laser cutting, in general, is very versatile but our team realized that we lacked knowledge on how to use a laser cutter. It was also clear that laser cutting would only be used for a section of our robot design and can’t make complicated three-dimensional shapes that extend well above the laser’s cutting threshold. This takes us to the third fabrication method mentioned below.

3D Printing

Fig.3 3D Printing Diagram

Out of all the fabrication methods described in this blog post, 3D Printing was the only method of creating stuff that has been used by a team member. 3D Printing is a fabrication process of creating a three-dimensional object by adding small amounts of material upon itself until the desired shape/object is obtained. There are multiple ways a 3D printer can produce a design, but we focused on an additive manufacturing process called Fused Filament Fabrication (FFF). This is the most common consumer grade process that is readily available.

With 3D printing, we can model our robot’s chassis designs and print them out at the same dimensions specified in the CAD model. This would allow us to expedite the design and manufacturing process in our project. 3D printing also allows us to create precise measurements and make exact copies of parts while maintaining constant measurement accuracy at each copy. With FFF 3D printing we are limited to using only plastic materials but fortunately, we can choose from various plastics that have different properties. In a later blog post, we will be looking at the different materials available for FFF 3D printing and looking at their properties.

Conclusion

After considering all three methods of fabrication we decided that we should use 3D printing to create all the designs in our robot. 3D printing’s only drawback was that it can only produce stuff in plastics, but our team has concluded that plastic has enough robustness to make our robot function and complete the maze. Lastly, our class has been informed that multiple 3D printers are available in house to produce our robot parts and thus this method of fabrication is also the most available for us.

Sources

  1. https://www.tractorsupply.com/know-how_hardware-tools_metalworking_working-with-sheet-metal-safety-tools-and-sheetmetal-projects
  2. https://www.wikihow.com/Use-a-Laser-Cutter
  3. https://library.ucalgary.ca/makerspace_equipment/3D_printing
  4. https://www.3diy.org/