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

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.

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

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.

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.