Spring 2017 Velociraptor: Final Project Summary

Table of Contents

Author

By: Jesus Enriquez (Project Manager)

Spring 2017 Velociraptor Project Team:
Jesus Enriquez (Project Manager)
Oscar Ramirez (Mission, Systems, & Test)
Mohammar Mairena (Electronics & Control)
Andrea Lamore (Manufacturing)

Executive Summary

Program Objective

The Objective of the EE 400D Velociraptor Robot is to produce a robot that emulates the body of a “Velociraptor”. The robot will compete in a custom game of “Pac-man”. The finished product must meet the following Program and Project Requirements:

  1. Total production cost  must not exceed $200.00 as agreed upon between the project team and the College of Engineering
  2. The load of the Velociraptor shall be primarily driven by DC motors
  3. The Velociraptor will be controlled through the Arxterra App (Android or iPhone) using Bluetooth
  4. The Velociraptor shall use the 3DoT board and custom PCB to carry out robotic controls to achieve mission success as defined in the Mission Profile
  5. The Velociraptor shall perform a static walk as it navigates the custom maze

Mission Profile

The Velociraptor Robot shall compete in a “Pac-Man” style game against the Biped Robot during the EE 400D Final on May 15th, 2017 as described below:

  1. The game will involve both robots starting on opposite ends of the maze in which the Velociraptor will begin the game as the “Ghost” , whereas the Biped will act as “Pac-Man.”
  2. The Velociraptor shall attempt to collect as many dots as possible while navigating the maze utilizing either a static or dynamic walk.
  3. Control of the Velociraptor will use the Arxterra Control Panel.
  4. Video support will be provided by the Spiderbot from an aerial view.
  5. The Velociraptor shall use the 3DoT board and a Custom PCB to carry out the robotic controls in order to achieve Mission Success

Project Features

  • Static Walk
    • The Velociraptor shall be able to perform a static walk in order to navigate the custom EE 400D maze.
  • Universal Joint (Similar to Human Hip)
    • One of the creative solutions that we came up with came from the inspiration of how a hip moves, with the help of a universal joint.
  • Turning Capabilities
    • With help of the previously stated universal joint, this would give our robot turning capabilities, with the help of servos
  • Head/Tail
    • The head and the tail would only be used for cosmetic purposes since moving them would cause too big of a shift in the center of balance.
  • Theo Jansen Leg Mechanism
    • We decided to go with the Theo Jansen because it was a leg mechanism that rotated on a single axis which was ideal for our design since we were using DC motors.
  • 3DoT Board
  • Custom PCB

System Design

Below is an exploded view of the system design for our Velociraptor.

System Block Diagram

The system Block Diagram shows the inputs and outputs of our Velociraptor. It shows that our original design had a total of 4 servos and 2 DC motors, along with 2 rotary encoders for determining the velociraptor’s leg position. Ultimately this design was changed over and over as we went through the iterative design process. We ended up using only 2 DC motor and 2 servos, along with 1 rotary encoder to determine the position of the legs.

Subsystem Design

Experimental Results

We were able to test out and experiment on most of the driving factors of our robot. The following tests/experiments have been documented in blog posts with further information which can be reference to below.

Servo Torque Test

Leg Mechanism Prototype

RGB Color Sensor

DC Motor “Move” Command

Servo Custom Commands

Interface Definition

In the figure below, is the interface definition matrix for our robot. It is important to keep this interface matrix updated and to also continuously keep track of all the revisions because as the design changes, it can have an affect on the resources that have been allocated in the previous design such as number of pins and hardware limitations. It might be a good idea to leave room on your custom PCB or Schematic in the case that the design changes and you need more pins available for a variety of thing (i.e. extra motors, new sensors).

Cable Tree

Our Cable Tree was done through computed aided drawing which is not recommended. But as you can see below, we took into account the different things that would need to be mounted onto our robot like the 3DoT, the PCB, and the motors. One of the things we did not take into consideration was the slack that we would have to allow for the wires when turning the legs. Also, wire wrap is highly recommended to use in order to give the robot a cleaner overall look.

Mission Command & Control

Software Block Diagram

The Velociraptor software contains four different subroutines. Three subroutines control the robots movements and one controls the color sensor and LED. The software begins by first decoding incoming data packets, then each subroutine is called based on the decoded command in the commandHandler. Also please note that the subroutine for the Head/Tail movement was removed in the final design since we decided to use it for cosmetic purposes instead.

Electronics Design

There were a series of steps that had to be run through in order to choose the different types of parts for our robot. In the link below, we have a slide-set detailing the different parts that we used for our robot.

Electronics Design

Firmware

The firmware design for the robot can be found in the following link below.

Firmware

PCB Schematic/Layout

Included is a blog post that goes through the stages which our schematic, PCB, and construction went through during our project design.

Finalized PCB Layout Design

Hardware Design

Below is a series of blog posts which takes you through the hardware design and assembly process that our manufacturing engineer went through as she continuously developed new designs and models through the engineering iterative design process.

Exploded View of Velociraptor

Verification & Validation Test

Our verification & Validation test plan can be referred to in the link below. The other link includes the verification matrix detailing which requirements we were able to meet throughout the engineering design process.

Verification & Validation Test Plan

Verification Test Matrix

Project Status

Power Allocation

The Power Report shows that the Velociraptor team is at ~930mA and the Project Allocation is at 680mA. In this case we had a negative contingency which meant that we were allocating too much power to our original design. Later on, we ended up taking away some of the components such as DC motors and Servos which dropped our contingency for a positive note.

Mass Allocation

The Mass Report is based upon the torque needed to drive the robot, which is ~400g. The robot weighed 889g which was because we ended up decided to make the robot a lot larger in size than that of the original anticipated design.

Cost Report

Looking at the cost report above, we can see that we went well over our budget. We had an allocated budget of $200 originally and spent a total of $361.25 in the end. For future suggestions, it is better to do research on getting parts from personal vendors rather than distributors (i.e. McMaster Carr) in order to get parts for a cheaper price.

Updated Schedule

Top level

System/Subsystem Level

Much of the top level schedule had remained the same mostly throughout the duration of the project. This was mainly because most of the time we could not really push back important deadlines for the top level at all. As for the system level, this one tended to be very dynamic throughout the duration of the project since there was consistent design changes throughout the semester which continuously pushed tasks back.

Burn-down Report

The project overall started off very steady getting things done on time in the beginning since they were mostly top level tasks. Although as we started to dive into the system level tasks, we started to delve off-track which was tied to a lot of the iterative design changes we were making. In the end, we were not able to finish 100% of the tasks which we hope to which was caused to consistent errors and mistakes such as accidental drops or parts being burnt out from time to time. Expecting the unexpected and being prepared is suggested for future purposes because anything that can go wrong, will go wrong sometimes.

Concluding Thoughts

Lessons Learned / Future Suggestions

Below are a few suggestions for some of the things our group encountered as we went through the engineering design process for this project:

  • Theo Jansen Leg Mechanism:
    • Our team highly recommends that the Theo Jansen leg mechanism to NOT be used for future generations of any Bi-Pedal robot. The Theo Jansen leg mechanism was extremely difficult to deal with when it came to getting the robot to perform any type of walk. The Theo Jansen is more practical for other robots such as the spider-bot which has multiple legs.
  • Position Tracking:
    • When looking at the options that we had for position tracking, the one idea that we stuck with was the rotary shaft encoders. Dealing with the rotary shaft encoders was tough when it came to the wiring and placing them on the DC motor alone was also difficult since the cheapest encoder shaft we could find did not fit the motor shaft. So in this case we design an adapter to fit it. Look into hall sensors for future references, it may be simpler and give the robot a cleaner look.
  • Material:
    • Looking back at our design, it was not as strong as we hope it would be. We ended up using 3D printing and laser cutting for convenience purposes but realistically we needed a much stronger material. Ideally in the beginning we wanted to use aluminum to give it a clean look but it was way too expensive. Our suggestion is to find a way to laser cut all the parts because it will give a cleaner cut look to the robot and will also cut down manufacturing time. Laser cut wood or plastic would also be ideally stronger for the design so it isn’t too fragile.
  • Universal Joint:
    • The Universal Joint worked amazingly well when it came to turning the legs in a 90 degree fashion while still being able to take a step. I highly recommend to continue to use the universal joint and incorporate it in future designs that require a turn.
  • Springs on the Feet:
    • The Springs on the feet were very beneficial to our design as it gave almost full control of how we wanted to fix the feet in place. It is recommend to use more than 2 springs in future designs as you’ll see that ours only had two.
  • Static Walking:
    • The best advice that I can possibly give, considering it was our biggest challenge, is to focus a huge amount of your time into testing the robot to make sure it walks. The earlier you can get the robot to stand on its own and possibly even take a step, the more likely your project will be successful. We did not spend much time testing the robot to see if it could walk because we continuously kept changing the design. Sometimes, it’s best to stick with a design that is simple and full-proof but also satisfies the customers requirements
  • Electronics:
    • When beginning the course, please make sure that your E&C or someone on your team is good at coding in C++. This will be very beneficial for the team since it will push for faster prototyping. Also do not hesitate to reach out to the division managers who are there to be resourceful for things such as Code or Electronics in general.

Last but not least, please do ask Professor Hill for help since he did come up with idea at the end of our project which we should have came to him for in the first place. Using your resources and communicating across all management levels is extremely important.

Resources

  1. Project Video
  2. CDR
  3. PDR
  4. Project Libre (Burndown)
  5. Verification & Validation
  6. SolidWorks
  7. EagleCAD Files
  8. Code

Spring 2017 Velociraptor: Counting the Number of Dots Encountered

Table of Contents

Authors

By:  Oscar Ramirez (Mission, Systems, & Test)
-Body
Edited and Approved By: Jesus Enriquez (Project Manager)
-Introduction & Conclusion

Introduction

One of the other challenges that we faced on top of choosing and configuring a color sensor was the challenge of interfacing the Arxterra app custom telemetry with the count dots command. This post covers the strategy and solution we came up with in order to solve this issue.

Requirement L2-1: The Velociraptor shall be able to count the number of dots it encounters in the Custom Maze using an SMD LED to indicate that it counted a dot
Requirement L2-2: The 3DoT shall send custom telemetry to the Arxterra Control Panel via Bluetooth

Detecting the Red Dots

After configuring our TCS34725 color sensor we needed to implement this into our main code and not just detect the red dots inside the maze, but also count them and find some sort of way to display them. Implementing the red dot detection into the main code was not an issue but displaying the number of counted dots proved to be more of a challenge. A seven-segment display would not be ideal since it would require numerous digital pins on our Arduino and we would also need two seven segment displays to count a practical amount of dots. A much simpler solution would be first counting the dots and display the counted dots by blinking an LED equal to the number of dots counted. For example if we were to collect 14 dots the LED would blink 14 times. To enable this dot count, I created a custom Boolean command that once switched to “ON” would blink the LED the same number of times that are equal to the total dots. Creating a counting dot subroutine and inserting this logic was simple. First I copied the dot counter into a dummy variable so that the value of the counter would remain unmodified. Taking this dummy variable that has the total number of dots that we want to count, I inserted it into a while loop that begins by decrementing it by one and then flashing the LED once. This process repeats until the value of the dummy variable is equal to zero and the LED has flashed the same number of times equal to the total dots counted.

Figure 1: Our custom command that toggles the current red dot count

CountDotsHandler: 

void countDotsHandler (uint8_t cmd, uint8_t param[], uint8_t n)
{
d=c;        // copying number of dots to dummy variable
if (d>0)    // counting the number of dots by derementing d

{

while (d>0)

{

d=d-1;  // subtracting each dot one by one and setting LED to HIGH for each dot

digitalWrite(8, HIGH);

delay(250); // 250ms delay between LED flashes

digitalWrite(8, LOW);

delay(250); // repeating loop until all our dots are counted

}

}

}

Conclusion

This test for us worked fairly well off the robot and the only challenging aspect of this that we came across was that we did not test the robot for a static walk performance in order to predict about how long we should allow the LED to stay on as it encounters each dot. For the future, the best recommendation is to focus on getting the robot to walk first and foremost.

Spring 2017 Velociraptor: Custom Commands (Servo Motor)

Table of Contents

Authors

By:  Oscar Ramirez (Mission, Systems, & Test)
-Body
Edited and Approved By: Jesus Enriquez (Project Manager)
-Introduction & Conclusion

Introduction

One of the bug requirements that we needed to satisfy for our Velociraptor was giving it the ability to perform a turn in order to navigate the maze. To solve this issue we decided to integrate servos into the robot to turn the hip through the universal joint. This post covers a brief background on the testing we performed through the arxterra app to control the servo for the turn.

Requirement L2-8: The Velociraptor shall be able to turn.

Servo Control

For our velociraptor to turn we needed a servo to control the hip motion to an appropriate angle so that the robot could take a step with the hips turned and take another step with the hips back to their regular state to complete the turn. To control this hip motion a servo motor was the ideal solution.

To begin I included the servo library in my code and declared servo11 as my servo. Next I created a handler and subroutine for this servo. A servo motor will typically only rotate from 0 to 180 degrees and for our purpose we would only need it to go from 0 to about 15 degrees to complete the hip motion. Using a Boolean command from the Arxterra app I set two angles, 0 and 15 defining 15 as “ON” and 0 as “OFF”. Finally using the pwn pin 11 on the Arduino I set up the servo and tested the range of motion with the Arxterra app going from 0 to 15 (toggling the on and off switch).

Reference code:

void servoHandler (uint8_t cmd, uint8_t param[], uint8_t n)

{

Serial.write(cmd);             // servo command = 0x41

Serial.write(n);               // number of param = 1

for (int i=0;i<n;i++)         // param = 90 degrees

{

Serial.write (param[i]);

}

int x = param[0]*180/127;

if (x==1){

servo11.write(21);

}

else if (x==0){

servo11.write(0);

}

}

Conclusion

After performing this test, we were able to successfully send commands to the servo to turn a specific amount of degrees as required. The only thing that was the set back in this test was that there was a lot of iterative designing going on throughout the mechanical assembly of the robot so it did not leave us with enough time for full-proof testing. This provided proof of concept for our robot. This is why it is consistently recommended to focus on the mechanics of the robot more than anything before diving into the servo testing for turning.

Spring 2017 Velociraptor: Schematic, PCB, and Construction

Table of Contents

Authors

By:  Andrea Lamore (Manufacturing)
Edited & Approved By: Jesus Enriquez (Project Manager)

Introduction

We had to build a custom PCB. Our PCB contained a 12 channel PWM expander the communicated with the peripheral devices that the 3Dot board did not have pinouts to hold. It was important to make sure everything on the PCB was I2C compatible so that the 3Dot board could communicate with it via only 2 pins. Netted to the PWM expander is an LED, potentially 3 servos, a color sensor, 2 rotary encoders, and an A2D converter for the rotary encoders.

Requirement L1-5: The Velociraptor shall use a custom PCB

Body

Below is the schematic and the PCB design

The Board we ordered and the stencil

Surface mount soldering.

Solder pasts is layered over the stencil on to the PCB and then heated in the oven. Before laying out paste the stencil and PCB need to be secured with tape. After the paste is spread flat over the stensil with a credit card the stencil and the tape can be peeled off. The parts I was working with were about the size of a grain of rice, this is a reasonable size if one is hand placing parts. However, one of the capacitors I had to lay over the PCB was the size of a grain of sand, in these instances it makes more sense to use a Pick-and-place. If you do not have access to a pick and place make sure you are aware of the sized components you are ordering.

After the parts are placed over the solder, the board can be placed in the oven until the solder turns a shiny metallic color.

With Unheated Paste and Components

Note that is soldering you PCB with paste is not something to guess at. Soldering the PCB requires a lot of visual observation and attention to detail. You must use your best judgment to ensure that there are no shorts after heating up you board. Most of the teams fail the first time because they treat soldering the PCB more like a step-by-step procedure rather than an art.

After placing PCB in Toaster oven for a couple minutes

After I attached the through-hole components with a solder iron.

Conclusion

If I could redo the PCB I’d collaborate more with the EnC so that the parts ordered are a reasonable size so that they could be easily hand soldered onto the board. I’d add a more complicated display to the PCB (probably 2 seven segment displays) and more LEDs. I’d use an LED instead of a header. I’d use screw clamps for the power supply instead of a headers- since they hold easier. I’d include some control buttons/switches so I could potentially program various setting for the Velociraptor and change them easily by adjusting the switches on the PCB and resetting the board with a push button.

Spring 2017 Velociraptor: Final Assembly Update

Table of Contents

Authors

By:  Andrea Lamore (Manufacturing)
Approved By: Jesus Enriquez (Project Manager)

Introduction

Assembly of the first velociraptor demonstrated some problems that were not clear from the SolidWorks model alone. These problems included a wobbliness/loose motion of the legs, the hip joint was arching when it should have been straight, and the head and tail were bending and lacked stability. In order to increase the stability of the velociraptor I made some changes to the design.

Requirement L1-3: The Robot should resemble the embodiment of a Velociraptor

Body

Assembly of the first velociraptor demonstrated some problems that were not clear from the SolidWorks model alone. These problems included a wobbliness/loose motion of the legs, the hip joint was arching when it should have been straight, and the head and tail were bending and lacked stability. In order to increase the stability of the velociraptor I made some changes to the design.

Above, on the first assembly, you can see the head and tail that will now be used only aesthetically. Below is the second Assembly with no electronics attached.

I increased the width of the hip socket so the u-joint wouldn’t bend vertically. Two ball bearing were to be used on each side.

I added stabilizers to the leg so the circle would remain vertical. I also cut the circle large enough to reach the stabilizers without interfering with the shaft motion.

A single servo should be able to move the hips, however 2 servos will be attached and move in sync to increase torque. This requires that they be attached at 90 degrees then move plus and minus 15 degrees respectively depending on whether the legs are turning out or in.

I used thicker acrylic sheeting for the new leg cuts and reduced the size of the shaft holes to the minimum size that could fit a 6-32 screw (which I used for the shaft).

I replaced the head and the tail mechanism with a rack and pinion on a linear bearing. This mechanism requires a DC motor instead of two servos. The DC motors will send feedback from the rotary encoders to indicate how many turns and at what angle the rack positioned at. The DC motor moves the shaft back and forth to adjust the Velociraptors center of gravity. At the end of the shafts are counter weight holders that hang low to the ground to lower the center of gravity and increase balance.

 

I found the foot mechanism to be somewhat successful in maintaining the stability of the velociraptor while it walks, however, the more weight I added to the velociraptor (DC motors, rack and pinion, etc.), the more resistance I required from the springs. Later I plan to double the amount of springs in the feet.

I printed some feet and ordered some rubber. I will eventually glue the rubber to the larger foot platforms and attach them to the raptor. The raptor can stand on rubber far better than it can stand on a smooth surface such as tile or plastic flooring. The velociraptor is shown slipping in the following image. He caught himself by landing on his knee.

Although I decreased the hole size for the 6-32 screw shaft to the minimum there is still some wiggle room in the legs. When You laser cut it actually cuts a little larger than expected (Contrary to 3D printing). If I could cut again I’d reduce the hole size a little more since the legs still have some wobble due to the wiggle room in the shaft holes.

I cut some squares that will eventually be used to mount the 3Dot board and the PCB.

I used hot glue in place of super glue or screws since it is easy to peel off if needed. Hot glue was surprisingly useful for temporary fastening of parts, especially parts that don’t have easy compatibility such as DC motors and Servos. Hot glue caused no damage to these parts after being peeled off. I tested this in the following before and after images.

The turning mechanism was successful as can be observed from the following pictures.

The hips can be turned up to 90 degrees outward on each side. When the legs open the shaft connected to the u-joints and legs slide inward. The more the legs open the more room the shaft needs to be able to slide inward. All of this needed to be taken in to account in order to prevent interference of parts.

Conclusion

The new velociraptor is far less wobbly then the first. The hip mechanism, foot mechanism and the new head and tail mechanism work successful. The only thing I would change is the leg mechanism so that it’s sturdier and less wobbly.

Spring 2017 Velociraptor: Configuring the TCS34725 Color Sensor

Table of Contents

Authors

By: Oscar Ramirez (MST)
-Body
Edited and Approved By: Jesus Enriquez (Project Manager)
-Introduction & Conclusion

Introduction

One of the requirements for our Velociraptor was giving it the ability to count the number of dots it encounters in the maze. In order to solve this issue, we came up with a creative solution which uses an LED to signal that the Velociraptor has encountered a dot.

Requirement L2-2: The Velociraptor shall be able to count the number of dots it encounters in the custom maze using an SMD LED to indicate that it counted a dot

RGB Sensor

As part of our mission objective, the velociraptor must be able to detect the colored dots inside the maze that it will also be navigating. The TCS34725 color sensor does a great job of detecting a number of colors, from a long distance (about 4 inches). When the color sensor detects the dot inside the maze a led will illuminate, showing that the velociraptor has stepped over a dot. To begin, the color sensor had four pins that needed to be configured to the Arduino. The SDA and SCL pins were hooked up to analog pins A5 and A4 (SDA & SCL respectively). Then the Vcc and ground pins were connected to 3.3V and common ground inside our test circuit.

Figure 1: TCS34725 Color Sensor

Programming the RGB Sensor

To program the TCS34725 we first needed the associated library files. Once those were downloaded inside the Arduino library we were ready to begin. I first set the designated LED pin to an output inside the setup. For this experiment I tried only detecting the color red, but also included blue and green in case the color of the dots inside the maze were to change. I created three 16-bit variables to store the data that the sensor picks up and designated them blue, red, and green. Grabbing the data the sensor was currently picking up I stored it inside these variables. These numbers can fluctuate from around 200 all the way up to 4000 per color depending on the intensity and proximity of the color i.e. the closer and clearer the color, the higher the number. While placing the sensor over the color red it does give values of about 3000 but also gives values for blue and green at about 1000. To differentiate between colors I took the average of all of the colors and then divided the particular color by the average. By comparing these values with each other it was easy to differentiate between them. On the code this was done by creating 3 different if statements and comparing the value of each color to each other. If the detected color were red then the LED would illuminate, signaling that red was detected.

Figure 2: Color sensor facing flat detecting no color (LED OFF)

Figure 3: Color sensor detecting the color red from about 4 inches (LED ON)

Color Sensor Code:

Link: Color Sensor Arduino Code

Conclusion

This method for counting dots was the simplest form we could come up with in terms of electronics and coding. One issue that we came across was that we did not take into account how long to keep the LED on after encountering a dot. To solve this issue, it is recommended to work with sending telemetry back through the arxterra app to let the user know when a dot has been counted.

Spring 2017 Velociraptor: Configuring the HM-10 to Work With the TB6612FNG

Table of Contents

Authors

By: Oscar Ramirez (MST)
-Body
Edited and Approved By: Jesus Enriquez (Project Manager)
– Introduction & Conclusion

Introduction

One of the challenges that we had to come up with was coming up with creative way to get the Velociraptor to perform a static walk. Adding to this challenge we needed to control and implement this static walk through the Arxterra app. With the help of our MST engineer, our team was able to come up with a way to control the DC motors that drive the Velociraptor through a “Move” command on the Arxterra app.

Requirement L2-7: The Velociraptor shall be able to perform a static walk
Requirement L2-5: The Velociraptor shall use the Arxterra Android or iPhone Application and/or control panel to control the Velociraptor

Testing the “Move” Command

 One of the first telemetry commands that we implemented for Velociraptor was the “MOVE” command. The MOVE command controls both the speed and direction of DC Motors A or B on the 3DoT Board. The 3DoT Board uses the TB6612FNG motor driver that can drive two DC motors and control their speed, direction, and even brake. The braking feature can be very useful, especially considering the balance issues with biped robots. The movement speed of the motor is also important to our design since we are using the Theo Jansen walking mechanism that requires a fair amount of control to keep the robot balanced. As far as the direction, it will not be used for our design since it is not practical for the DC motors to go in opposite direction. After testing the MOVE command on CoolTerm and verifying that the board received the command, I moved on to physically testing the move command by setting up the HM-10 Bluetooth sensor and the TB6612FNG on a breadboard. For prototyping purposes I used the Arduino UNO as the micro-controller and used a 9V battery as the main power source for the motor and Arduino UNO.

Figure 1: Arduino UNO breadboard setup with the HM-10 and TB6612FNG

Once synching to the HM-10 with the Arxterra App I used the Joystick layout to send a move forward command to the Bluetooth sensor that then relayed that command to the MCU and back out through the PWM pin and analog pin. Once confirming that the MOVE command worked through simulation and testing we were ready to proceed to the next step in our design.

Figure 2: Sending a “move forward” command on the Arxterra app

 

Conclusion

Through testing, we were able to successfully send bluetooth telemetry commands through the Arxterra app. It was convenient for our design in that we were able to control the speed of the DC motors which is necessary for a design like the Velociraptor. It is recommended that this be one of the first tests or tasks to complete when doing the velociraptor project since there will need to be a ton of testing for moving the legs/walking which is the most critical to making  successful project work.

Spring 2017 Velociraptor: Robot Assembly Process

Table of Contents

Authors

By: Andrea Lamore (Manufacturing)
– Assembly Process
Edited & Approved By: Jesus Enriquez (Project Manager)
– Introduction & Conclusion

Introduction

Before going into Critical Design Review, our team had to assemble the Velociraptor in order to have it Demo ready. Prior to PDR, we had a design in mind which was modeled on SolidWorks which continued to change as we approached CDR and we went through the engineering design process making iterative changes through the weeks between the two presentations. This post covers some of the thinking and planning that went through our minds as the Velociraptor was being assembled throughout the weeks.

Assembly Process

Assembling the Velociraptor resulted in minor changes to the original design. The legs were made up of several linkages. Screws and locknuts were used as the shaft. Lining up the linkages so that every piece was parallel with the other was key in eliminating the wobbliness of the leg and smoothing out the steps.

I decided to laser cut the flat parts to ensure the dimensions were accurate and the linkages came out smooth. The circle shaped shaft that connects to the motor needed to be re-cut so the there was a tighter fit between the motor shaft and the leg rotation shaft. The smoothness of the “step” is key in getting the velociraptor walking without falling. Below I circled the hip shaft and what part needed to be re-cut.

Note: The primary tools used were a wrench and needle nose pliers.

 

Figure 1: Modified Circular Shaft

 

The servo holder was too delicate and bulky. I ended up laser cutting a part that would replace the 3D printed servo holder. The following shows previous and new design for the servo holder.

 

Figure 2: Original Servo Holder Design

 

Figure 3: New Servo Holder Design

 

The hip of the velociraptor was too long and was just barely hitting the leg shaft on each rotation making the steps wobbly. I had the option of sawing the hip shorter or reprinting it and decided to reprint it. The following image shows the new hip and SolidWorks verified the new part would not hit the leg shaft.

 

Figure 4: SolidWorks Model of New Hip-Design Assembly

 

The feet were laser-cut and super-glued together using “gel” super glue. The resulting hold was very strong and in the future I will try to laser-cut as many parts as possible and super-glue them together instead of 3D printing. The spring mechanism for the foot worked as planned. A little groove was cut into the spring slot so that the spring would not easily slip out of place. The following image shows Left-leg waiting patiently while Right-leg is assembled.

 

Figure 5: Laser-Cut Version for Velociraptor Legs

 

The following 3 image demonstrate how the foot bends at the ankle using the springs:

 

Figure 6: New laser-cut Velociraptor Ankle/Foot Design

 

The head and tail radius, as well as the dummy-weights on the end were adjusted until the velociraptor could stand without tipping over. In the future, as we add the micro-controller and other components, the velociraptor’s head and tail radius as well as the angle of head and tail rotation need to be calibrated with each change in structure.

The gears for the turning mechanism worked well but were recut using thicker plastic to ensure they do not slip when the velociraptor is walking.

The u-joints were originally 3D printed but came out unusable. Lego U-joints and shafts were ordered to be used instead. They worked marvelously. The following images show the 3d printed u-Joints and the Lego u-connects.

Figure 7: Original 3D printed Universal Joints

Figure 8: Lego Universal Joints to replace original U-Joints

The leg shaft and dc motor shafts are not threaded so a screw could not be used as a cap. Instead little rubber bands were used to cap them and prevent slipping-out.

Figure 9: Rubber bands used to cap the screws

For the sake of simplifying the code to come, the group decided one DC motor would be used instead of two. The legs had to be moved 180 degrees out of phase with one another before being locked into place. It was easy to calibrate this since the shaft can only be rotated in increments of 90 degrees to ensure a proper fit.

Figure 10: DC Motor Shaft Design

Figure 10: Velociraptor Assembly before CDR

Conclusion

During hardware design changes, we noticed that the original design was a lot more bulky, making it over all heavier and it also became more challenging to get the robot to walk, let alone standing. Our Manufacturing continued to strip parts away and simplified the design to give it a cleaner and tighter look which also allowed the robot to move more functionally. The final design can be reference to in the final blog post for the Spring 2017 Velociraptor.

References

  1. https://www.amazon.com/Technic-U-Joint-Mindstorms-Universal-Joint/dp/B01IKRCU7K/ref=sr_1_1?s=toys-and-games&ie=UTF8&qid=1492407338&sr=1-1&keywords=lego+u+joint
  2. https://www.amazon.com/gp/product/B00OT8QWLK/ref=oh_aui_detailpage_o00_s00?ie=UTF8&th=1
  3. https://www.123rf.com/photo_19111999_assembling-a-robot.html

 

Spring 2017 Velociraptor: First SolidWorks Model

Table of Contents

Authors

By: Andrea Lamore (Manufacturing)
Approved By: Jesus Enriquez (Project Manager)

Introduction

During the early stages of the design process, leading up to PDR, the Velociraptor’s frame was similar to what was presented at CDR but had a few distinct differences in terms of specific part modification and part sizes. The purpose of this post is to present one of the first iterative designs for the Spring 2017 Velociraptor.

3D Modeling on SolidWorks

When first designing the hardware model for the Velociraptor, a design change was made so the Velociraptor could be made to walk with 2 DC motors. The Theo Jansen Linkage allows for walking with continuous rotation around a jingle joint, making it an ideal choice for the Velociraptor leg design.

The Velociraptor requires a turning mechanism. This could be done most obviously by having one leg take steps while pivoting around the other leg (much like how an RC car turns), or my adding an axis of rotation around one of the joints in the leg (either the hip or the ankle in our cases). Two universal joints at the hip was chosen to provide rotation at the top of the leg mechanism. This allows the continuos rotation of the leg  while the hip is at an angle.

 

The DC motor will be placed on the outside of the leg as to help with balance of the robot by moving mass away from the center axis so that shifting the center of mass (done by shifting the head and the tail) may be accomplished more easily. This also allows the motors to stay in parallel with the leg when the hip rotates.

When the velociraptor turns, the center of mass will move away from over the fulcrum point, for that reason two servos will control the head and tail independently. This was decided so that when the velociraptor turns, the head can be adjusted separate from the tail so that the center of mass stays over the fulcrum pint (over the standing foot). The following figure demonstrated how the center of mass changes with rotation of the hip.

Conclusion

As the iterative design process was pushed forward, through prototyping and trial & error, it led to further design changes leading up to our CDR design model. Realizing as oppose to modeling on SolidWorks is much more difficult and that was discovered through experience in assembly the physically manufactured parts for the Velociraptor.

Spring 2017 Velociraptor: DC Motor Selection

Table of Contents

Authors

By: Mohammar Mairena (Electronics & Control)
Approved By: Jesus Enriquez (Project Manager)

Introduction

Through research on DC Motors, I came across gear motors. Gear motors add mechanical gears (gearbox) to reduce speed/increase torque and vice-versa. The increase in torque is inversely proportional to the reduction in speed. Each gearmotor has a different gear ratio that alters the torque/speed calculations. Through the E&C division manager and Professor Hill, I borrowed what were said to be two GM 7’s and a GM17.

Requirement:
L2EC – 4: The velociraptor shall use DC motor(s) to drive the legs of the Velociraptor

Selecting the DC Motors

After testing what was supposed to be two GM 7’s, I realized the current values did not match up to those on the GM 7 datasheet. Upon further research, one of the GM 7’s turned out to be the pololu 200:1 plastic gearmotor with a 90° Output. The other motor was also not a GM 7 as it drew much more current than a GM 7. For both motors, I measured two things: stall current and the free running current at no-load. The stall current is the current at which the shaft of the motor is no longer rotating (under max torque conditions).
Comparing both motors, it is clear that the Pololu is much more ideal for our robot due to the low current draw it will have in comparison to the other yellow motor. In addition, it is important to note that the current draw from the Servo motors has not been taken into account. The Pololu gear motor is a great alternative to the GM 7 for 2 reasons: low current draw and high torque output.

Table 1: Pololu 200 Results

Table 2: Yellow Gear Motor Results

Resources

1) https://www.pololu.com/product/1120/specs
2) http://www.robotshop.com/en/solarbotics-gm7-gear-motor-7.html