Spring 2016 Velociraptor: Project Summary

By: Khoi Vu (Project Manager)

Table of Contents

Program Objectives & Mission Profile:

The Spring 2016 Velociraptor biped was inspired by the robot Titrus-III. The robot that was designed and created by Tokyo Institute of Technology. The purpose of this project is to design a Tyrannosaurus class biped robot to be used as a toy. The mission profile is to demonstrate the feasibility of the dinosaur biped as toy product. The objective of this project focuses on a toy with the ability to detect and avoid obstacles. The Velociraptor will be controlled wirelessly by establishing a communication between a Bluetooth module and the Arxterra Android application.


More information including  the Program & Project requirements can be seen in this velociraptor blog:

The Design:

The design of the Spring 2016 Velociraptor focuses on solving flaws that may have caused previous generation Velociraptor to failed. These problems were discovered in a creativity activity using a variety of methods. Some of these methods include brainstorming approach by having the engineers listing out possible reasons that may have caused the last generation to failed, attributes listing of the robot, and Lateral Thinking using a different point of view and as well using the forced relationship technique. The team had narrow the problems to four flaws that could be improved and increase the chance of success for the Spring 2016 Velociraptor. The conclusion of the activity can be seen in Figure 1 below.



Figure 1: Creativity Activity

More information including the methods for the Design Innovation can be seen in this velociraptor blog:


Size & Weight:

One of the main problems that occurred in the Fall 2015 MicroBiped was that it was extremely heavy. This was due to the facts that everything in the previous generation was printed completely solid. The measured weight of the MicroBiped was 920 grams. With the new design of the Spring 2016 Velociraptor, the team was able to decrease the size but as well as the weight of the robot to approximately 600 grams. In Figure 2b showing the final robot’s actual weight 657 gram.


920grams            IMG_0842

Figure 2a: Fall 2015 MicroBiped                                  Figure 2b: Spring 2016 Velociraptor

This is a 30% reduction in weight from the previous generation. This design innovation reduces the weight of the robot, this also leads to a reduction of stress that is put on the servos. By reducing the stress on the servos we also lowered the power consumption of the robot.  The engineers were able to reduce the weight by reducing the printing material needed to hold the robot together but as well as placing the servos tightly together, this method reduced the amount of material needed to be print. The team also remove the head and tail of the robot completely to reduce the weight and instead using the weight of the battery as the head and tail (Figure 2b).

Center of Mass:

In figure 2a, you can see that all the components of the robot where placed at the body, this created a problem in the center of mass. when the head and tail of the robot turn to one side it was unable to stabilize itself on one foot to change the position of the other foot. This was a critical problem because if the robot is unable to balance itself on one foot it will be unable to meet Level 1 requirement 5, which stated that the robot must be able to statically walk the course. In the new design, you can see that we have change how the robot weight is distributed. First, we remove 2 large item, the head, and the tail. By removing this part we not only significantly reduces the mass but as well as reduce the printing time for the project. Second was to instead of using 1 large battery which was placed  under the body in the previous generation, we split the battery to 2 pieces and used them as the weight of head and tail to counter the weight of the body (Figure 2b).


More information can be seen on this Velociraptor blog:


Servos are designed to provide torque not to hold weight, this was one of the flaws in the Fall 2015 MicroBiped. The weight of the head and tail of the robot were completely held by the servos. In the new design, we wanted to distribute the weight of the head and tail to the body. To accomplish this we designed a triangular shaped frame that held the head or tail. This frame in then connected to the aluminum piece of the body that held all the servos. This design put the majority of the head and tail weight to the lower aluminum body frame. However, we realize that our design still contains a flaw in which the servos still need to provide a lot of torque to lift the head and tail. Therefore, the team went back to the drawing board. To fix this problem we used the forced relationship technique, by forcing the robot to take the attribute of a garage door. The team came up with an idea of using a spring to hold the weight of the robot, this removes the stress on the servos while moving the head and tail.


More information can be seen on this velociraptor blog:


The design of the Leg is extremely important for the stability and balance of the robot while walking. In the previous generation, there was a critical error that may have to cause the robot unable to walk. After the team carefully analyzing the Microbiped, the engineers discover that it was missing critical joints that help the robot maintain balance while walking but as well stabilizing the robot. The third joint helps the robot holds its foot parallel to the ground or the walking surface. This design can be seen in the 3D model as well as in the exploded view.


More information on Joints can be seen in this velociraptor blog:


Project Features:

3D Model:

3D model is crucial for designing our robot. Using Solidworks program to draw our model helped our team to visually see and validate the feasibility of our design. Rather than constantly 3D printing components to test for the center of mass and the mass of the legs, by simply using Solidworks mass properties utility we were able to validate and verify. By using Solidworks not only will we be able to test the feasibility of the robot but also decrease printing time and cost.

More information describing the methods of Designing and Manufacturing can be seen in this velociraptor blogs:


Besides the communication Bluetooth HC-06 device, the two sensors used for the velociraptor are the accelerometer and the ultrasonic rangefinder.


The choice of orientation sensor used was the ADXL335. It is an analog data type sensor capable of detecting orientation on all three axes, x, y, and z. While a gyroscope/accelerometer combination board is more accurate and inexpensive, it was unfeasible seeing the serial code in the Arduino took up over 50% of program memory, and due to time constraints, this chunk of code was unable to be edited in a short time frame. The ADXL335 accelerometer is not only simple in terms of coding, but also accurate within a couple degrees. The data obtained from the accelerometer will sense whether the velociraptor is going up an incline. Upon receiving such information, the velociraptor will initiate a different walking code moving the center of mass towards the head and allowing the velociraptor to handle walking upwards.


ADXL335 accelerometer

Range Finder:

The choice of ultrasonic sensor for the velociraptor was the MaxSonar EZ3 MB1030. It is capable of detecting no less than 5 inches and up to 254 inches. There is a resolution of +1 inch due to an acoustic effect and becomes even more accurate at farther distances. It has both an analog and PWM pin for different output types, but the PWM option was chosen here for more accuracy and less noise. The velociraptor will use this sensor so that upon reaching a certain distance away from an object or wall of hindrance, the velociraptor will stop in its steps and wait for the user to choose whether to turn left or right.


MaxSonar EZ3 MB1030 ultrasonic rangefinder


More information can be seen on this velociraptor blog:

System Design:

Updated Block Diagrams:

System block diagram Final 1.2

Finalized System Block Diagram


Finalized block diagrams including interface matrix and system block diagram showing interface connections and active control circuits for statically and dynamic walk showing what software blocks are being sent from Arxterra to the microcontroller.
More information can be seen on this velociraptor blog:

Microcontroller Trade-off study:

In order to determine what microcontroller that should be utilized for the brain of the Velociraptor, a trade-off study was conducted. On the basis of what pins the components that make up the build of the Velociraptor will utilize as estimated in the systems resource map as presented in the PDR and other important factors as weight, dimensions and cost the Arduino Micro Atmega32U4 microcontroller was chosen.
More information can be seen on this velociraptor blog:

Bluetooth Arxterra Communication:

Bluetooth setup

To control the Velociraptor wirelessly as stated in project level 1 and 2 requirements a Bluetooth communication between the robot and the Arxterra application on an android device needed to be established. This blog post gives an instruction on how to set up first the
Bluetooth connection; download Arxterra application, Bluetooth setup on breadboard and connection to the microcontroller, Bluetooth code in Arduino IDE and lastly configure Bluetooth on android device and Arxterra application for a successful connection. To verify the Bluetooth serial communication with Arxterra app, a setup of four LEDS on the breadboard was built to be controlled by the joystick on the app. This setup was created to show the joystick control of four different LEDS, so the future walking code could simply be implemented into the joystick code and control the Velociraptor to walk forward and turn etc.
More information can be seen on this velociraptor blog:

Experimental Results:


The power test was conducted to determine the current draw of the robot, the experiment was done using a single servo with a different mass attached to the servo lever arm. We also completed the actual power consumption of the robot after it was assembled. The total power draw of the robot was no more than 2000mA, this allows us to estimated that with 6000 mAh battery, the robot can be used for about 3 hours.

For more information about the power, the test can be seen on the Velociraptor Blog post.


The purpose of the incline test is to determine the maximum angle the robot will be able to stand or walk on an incline. In the test, a variety of angle used to determine at which angle the robot failed to stabilize itself on the incline. Furthermore, the robot also stood in the different position on the incline to determine where the center of mass will fail to land on the robot’s foot.

For more information about the Incline, the test can be seen on the Velociraptor Blog post.

Material Strength:

Material trade-off studies have been done in order to find the suitable material to hold the weight of the head and tail. Our original design to incorporate the PCB and all sensors underneath the robot required us to have a hollow bottom piece. We needed to maximize the space which required thinner chassis for the bottom piece. After doing a quick material trade-off study as well as a material experiment we’ve decided to incorporate aluminum to certain components of our robot to reduce the weight of the robot but as well as maximize the strength of the robot.

For more information about the material trade-off studies can be seen on the Velociraptor Blog post.


After assembling the prototype, we’ve realized the weight of the head and tail were giving too much stress toward the servos. We decided to incorporate a new design on the robot, by adding a spring to lessen stress on the servos holding up the head and tail. By adding the spring, not only did it reduce the weight on the servos to hold up, we’ve observed it also reduced the power intake by the servos.

For more information aboutSpring Experiment can be viewed on the Velociraptor blog post.

Acetone Bath:

After finalizing our prototype, in order to unify the surface texture of 3D PLA filament and Aluminum we’ve decided to use Acetone Bath to smooth out the uneven surfaces created due to 3D printing. After few trials to maximize smoothing texture, sanding the 3D materials before acetone bath gave the best results.

For more information about Acetone Bath can be viewed on the Velociraptor Blog post.

Subsystem Design:

Interface Definition:

The interface definition shows the pins that are on the Arduino Micro, the table below show how the Spring 2016 Velociraptor is connected to the Arduino Micro.

Interface matrix FinalInterface Definition

More information can be seen on this velociraptor blog:

PCB Design:

This section will showcase the process of creating and testing the PCB, from the fritzing diagram, to breadboard testing, to Eagle schematic, and finally to the PCB layout.

Fritzing Diagram:

The first step towards the fabrication of the PCB is making a Fritzing diagram. Here, the microcontroller, sensors, actuators, power source, and voltage regulator are laid out. A fritzing diagram is particularly important in pin mapping on the Arduino micro. There is a communication device, a digital ultrasonic sensor, an analog accelerometer, and digitally controlled servos. The Arduino has a limited amount of digital, analog, serial, I/O, etc. pins. Upon completion of the Fritzing diagram, it is noted that there are sufficient pins on the micro to suit the velociraptor needs. Last semester for the MicroBiped, a PWM servo driver was implemented, however unnecessary.

Note the Fritzing diagram does not include resistors, capacitors, and other small elements to be implemented on the PCB in the future. Below includes:

  • (4) 18650 MXJO 3.7V 3000mAh
    rechargeable batteries
  • MIC29510 5A adjustable voltage regulator
  • (8) MG92B 3.5kg*cm @ 6.0V servos
  • MaxSonar EZ3 MB1030 ultrasonic sensor
  • HC-06 Bluetooth module
  • ADXL335 accelerometer


Fritzing diagram


Next, the Fritzing diagram was used as a map to build the circuit on a breadboard. Because the voltage regulator had not shipped in at this point, the servos were powered separately by four AA batteries in series to achieve the optimal 6V. All components ran smoothly, which justifies the Fritzing diagram. As observed, due to the numerous connections needed for the velociraptor, the wiring could get quite messy. Thus, it is important to mount the Arduino micro directly onto the PCB to omit as many wires as possible and thus result in a cleaner project.



Breadboard testing

PCB Schematic:

Next, the PCB schematic was created on Eagle. Starting on the bottom left are the inputs for the two sets of 18650 batteries (connected in series to a battery compartment on the head and tail). A large bypass capacitor is implemented near the batteries to reduce current transients required by the device. Small resistors were also connected in between the two batteries to help with a possible voltage offset between the two pairs. The two batteries in series provide 7.4V and these two sets in parallel double the longevity during use. One battery is 3000 mAh, so the series connection increases this to 6000 mAh. It is calculated that the project most likely draws approximately 3A, meaning the velociraptor should ideally operate for 2 hours, a perfect time span for a child to be playing with a toy.

Moving on to the right, the TO-220 package was created and laid out for the voltage regulator. The resistor values were chosen to bias the LDO regulator to output a voltage of 6V, and the recommended layout was implemented as stated in the datasheet. An enable logic conversion was mainly implemented to meet the two PCB IC requirement, but can be utilized in the future. Using two transistors and appropriate resistors, this connection is connected to a digital pin on the Arduino and allows the user to code to enable the use of the voltage regulator. For instance, if the servos are currently not in use, the voltage regulator can be shut off upon request.

On the top left are the servo connectors. There are a lot of wires due to the number of servos, thus, most of the wires were implemented on the PCB. The servos are powered directly from the LDO regulator to optimize the torque rating for the servos.

To the right is the Arduino micro, where the connections to the MCU can be seen.

Lastly to the right are the Bluetooth, ultrasonic sensor, and accelerometer pin connections. None of these will be mounted directly onto the PCB, thus using appropriate phoenix 256 connectors or pin headers will be used to allow communication between the Arduino and these devices.

More information can be seen on this velociraptor blog:



Eagle schematic

PCB Layout:

PCB layout was done using EagleCad. The dimension of our body was L: 5.60 cm, W: 4.60 cm. We have decided to mount on all the sensors and the Arduino micro on to the board itself by using female connectors. The first priority was to fit all the thru-hole components onto this size of the board while keeping all the sensors as far away as possible from the power supply due to noise. The power supply traces must be short and wide to prevent oscillation or excessive heating and make sure none of the thru-hole components must be under the mounting components to prevent it from heating.  The picture below shows the final layout of the PCB.

PCB layout FINAL

PCB Layout

More information describing the PCB layout can be seen in this velociraptor blog:

PCB Components:

The complete list of PC components is listed in the figure below. The total cost for all capacitors, resistors, NPN amplifiers, LDO regulator, heat sink, and Arduino Micro was $41.24. It is important to not only choose the appropriate packages on Eagle but also purchasing the components accordingly to these packages. There is a total of seven surface mounted parts, and the remaining is through-holes.


PCB component shopping list

Hardware Design:

Hardware design incorporates the designs we’ve made on Solidworks. When we started building a fast prototype, we’ve realized certain design features such as thickness, length or hole sizes not feasible for our overall design. When we’ve started building our prototype, we’ve observed 2 different possible errors, random & systematic errors. Random Errors are caused by unknown and unpredictable changes because 3D printing is done by building the object layer by layer using heat to melt the polylactic acid (PLA) filament, Although our 3D model part may have a thickness of 0.5 cm, when it print the thickness varies around 10%. Systematic Error usually comes from the use of the machine. There are various settings for the 3D printer which could cause the printing to be more accurate or decrease/increase printing time. By decreasing the print speed or having finer layer height may increase the accuracy of the prints but will increase the printing time.

The previous generation microbiped used 1 servo to hold and control the movements of head and tail to perform static walking. A new feature we’ve added to the Velociraptor was not only using 2 servos to control the head and tail but also attaching a spring to prevent the servos from holding up all the weight of the head and tail. Figure 1. below shows how we’ve attached the spring to the robot.


Figure 1. Servo attaching to the head on the final prototype

For more information about hardware design and the new feature can be seen on the velociraptor blog posts:

Software Design:

Before tying together all the different codes, all of the software files were initially created and tested separately. Integration of the final code includes (and were created in the following order):

  1. Static walking
  2. Stopping upon object detection
  3. Turning
  4. Bluetooth
  5. Walking up an incline
  6. Dynamic walking

One of the most important techniques in the success of static walking is the fact that even though the non-stepping foot is stationary and in place, the servos still move. This not only prevents the velociraptor from dragging this stand-still foot but also propels the body forward. Virtually, all leg servos are always moving.

Due to the SRAM memory limitations, it’s important to store all velociraptor servo angles in flash memory using LUTs. There is about 10x more program memory space versus SRAM. These servo angles were planned and stored in excel and saved as a CSV file. This organizes the data and allows these arrays to be opened up in notepad for easy transfer to the .h files utilized by the Arduino. PROGMEM was the command responsible for the main code reading from these flash .h files.

Some considerations had to be made in designing these servo angles. There have to be small incremental changes in angles to prevent any quick motions that would cause the velociraptor to become imbalanced.  The steps must be designed to be reasonably lengthed for the velociraptor to make any progress in moving. The stepping leg must be able to lift high enough because there is a 0.5cm rubber divider in between the linoleum and carpet of the velociraptor’s mission objective. The angels for a set of legs must be designed so that while re-initializing on the floor, the foot keeps parallel on the floor, and these feet must be move at the same distance per time so that when both feet are on the floor and re-initializing, one isn’t moving faster than the other and causing the velociraptor to make unwanted dragging turns. Lastly, manufacturing engineer Mingyu designed the head and tail max swing so that the center of mass would be centered on top of each respective foot at the maximum capable servo angles allowing for the head and tail to move completely to the left or right.

Static Walking

The static walking was designed so that at any point in time, the velociraptor will be able to balance in place. This is very dependent on where the center of mass is. While both feet are on the floor, the velociraptor will maintain balance whether or not the head and tail are on one side or the other. When the velociraptor is taking a step, the center of mass will be centered above the foot on the floor.

Stopping Upon Object Detection

If the user no longer has a hold on the static forward walking button, the velociraptor will stop. Also, when there is an object detected within the vicinity, the static walking code will terminate and the velociraptor will come to a stop. At this point, the velociraptor will wait until the user enters turning left or right. As long as there is an object in front of the velociraptor, it will no longer pursue static walking.


There were a couple of brainstormed ideas on how to go about turning for the velociraptor. These ideas included (in order): swinging the head and tail like a baton and using that momentum to turn, one foot taking a step larger than the other, and keeping one-foot stationary as the other one takes a step and re-initializes. The last option was discovered accidentally with the preliminary static walking code and seemed to be the most viable option. Because each leg only has two servos, the ways to implement turning are limited. The cons here for turning is that the foot that is staying still will be dragged, of course. It is important that the floor and the foot have a reasonably low friction coefficient. For instance, this code would not work if both the floor and feet were made of rubber.


The foundation Bluetooth code was obtained from S&T division manager Alia in a folder named arxrobot_firmware containing many Arduino files. Four buttons will be used on the Arxterra android app: forward (static walking upon pressing down, standing still while not being pressed), left and right (turning), and back (dynamic walking). Four while loops will be implemented to test these button conditions, and the respective codes will be run.

Walking Up An Incline

Upon testing the regular static walking code on the incline, the velociraptor failed and was unable to handle the 6.5* incline on the ramp. Naturally, the velociraptor “became” tail heavy and fell backward. Thus, for the incline code, the velociraptor must move its center of mass towards the front of the body to fight against the gravitational pull backward. New leg servo angles were designed in order to successfully allow the velociraptor to walk up an incline upon accelerometer information.

Dynamic Walking

Instead of using the center of mass to keep the balance at any moment of time for static walking, dynamic walking uses inertia to keep balanced while “running.” Here, the head and tail do not make full rotations left and right, the steps are smaller, and the feet are not lifted as much on the floor. Upon “startup” and “ending,” the velociraptor has to gain momentum by wiggling slowly to its complete dynamic walking loop. Using this momentum, the velociraptor is able to keep balance.

More information can be seen in these velociraptor blogs:


Multiple tests were done to make sure that the Spring 2016 Velociraptor meet all the requirements that were set by the customer. Most of the requirements were completed. However, there were some incomplete requirements. For detail of the test plan click on the link below

Project Update:

Resource Report:

Power Report:

For the final updated power report, the project allocation was changed after the PDR equally to the mass report and a new project allocation of 5000mA was set. The actual current draw of the Arduino microcontroller and the voltage regulator was not possible to measure after mounted on the PCB and instead the total current draw of the final build of the Velociraptor was measured as to 1735 mA this is what the batteries need to provide power for. The MXJO IMR18650 3000mAh -3.7V- 35A batteries chosen for power supply does, therefore, prove to be sufficient to power the Velociraptor.

Final Power report copy

Power Report

Mass Report:

For the final updated mass report in figure 2, the project allocation has been changed since the PDR. In order to set a more realistic allocation, the resources/parts masses was added up and a contingency of 100g was set. Likewise, for the mass report as for the cost report, the original idea of the final frame cut in all aluminum acted as the heaviest post on the budget and therefore the group decided to change that to a hybrid chassis to minimize the total weight of the Velociraptor. Cutting only the bottom part holding the servos, the head and tail in aluminum reduced the weight of this post from 344.70g to 154.00 g. By printing the legs in 3D PLA filament only added another 88g to the weight of the chassis adding up to a total weight of the chassis at 242g rather than the 344.70g. The actual weight measured of the batteries turned out to be much less than the expected weight and therefore added to minimize the total weight of the Velociraptor to 560 g and thus successfully stay within project allocation.


Final mass report copy 2

Mass Report

Cost Report:

Due to the cost heavy aluminum frame post on the cost budget presented at the PDR, the total expected cost exceeded the project allocation of $400 and thus the change of parts was necessary in order to reduce the budget and stay within the limit. The final budget for the Velociraptor Spring 2016 shown in figure 2 has been reduced by changing the material used for the chassis of the robot. Instead of utilizing all aluminum for the final frame, the group decided to make a hybrid chassis made of aluminum for the bottom part holding the servos, the head and tail and print legs and feet in 3D filament Polylactic Acid (PLA). The change of parts successfully reduced the final cost of the project to a total of $257.48 and thus the final costs stays within project allocation.


Final cost report copy 2

Cost Report

Work Breakdown Structure:

The work breakdown structure (WBS) is critical to any project as it defines the roles and responsibilities of each engineer within the project. Creating a clear WBS can help a team move forward quickly because each engineer will know their purpose for the position and this will make management much easier.


Work Breakdown Structure

Project Schedule & Progress:

The chart below present the task that has been completed by the Velociraptor team, overall the team was able to complete about 98% of all the tasks assigned. However, we were not able to finish the final walking code giving the robot the ability to walk up an incline. Therefore, leaving us at only 85% completed on the walking code task in the testing category.

CaptureSpring 2016 Velociraptor Completed Schedule

Project Burn-down:

During the critical design review (CDR) our team was extremely behind due to a delay in creating the schematic and laying out the final PCB design. This is seen below where the blue line separates from the red line during the first week of April. However, a week after CDR the team was able to fix all the problem as well as assembling the final product. When all the problem were fixed, we also finish assembling the robot. This allowed us to get back on schedule which is shown in the Final Burn-down chart below.

Screen Shot 2016-05-07 at 10.16.40 AMFinal Burn-down Chart

Project Video:

The final video presents the engineering methods and the process of creating the Spring 2016 Velociraptor biped. To see the process using the engineering methods click on the image Spring 2016 Velociraptor or the link below.


Spring 2016 Velociraptor

Velociraptor Walking the figure 8

Final Video: Spring 2016 Velociraptor Final Video

Concluding Thoughts:

  1. Before starting a project, the team should find all the problems and find ways to improve the project.
  2. The key to of having a successful project is to make sure you are always ahead of the planned schedule. There will always be obstacles that will slow your project down. If you are ahead, these obstacles will not affect your deadline significantly.
  3. Have your first prototype within the first month of class. This will help you find the problems in the early designs and fix it before any decision are made with a faulty designs.
  4. Teamwork is critical, the project cannot be completed by an individual with the given time. Make sure that everyone are following due dates.
  5. In the case when the project falls behind, request help immediately.

Project Resources:

Kevin Lundberg – 3D Printing & PCB parts

Mingyu Seo – 3D Printing

Khoi Vu – Wood Workshop

Banggood – Robot’s Parts

Parallax – PCB Parts

Mouser – PCB Parts

Osh Park – PCB Fabrication

Spring 2016 Velociraptor: Verification & Test Plan

By: Camilla Jensen (System & Test Engineer)

In order to verify the level 2 requirements, a verification test plan has been created to test each component for the build of the Velociraptor before incorporating it to the build. The components are tested against its limitations as specified in datasheets and the level 2 requirements and consists of mostly physical test performed with a ruler, protractor, scale, stopwatch etc.


The validations test plan is created to test that the build of the Velociraptor lives up to the costumers expectations as stated in the level 1 requirements, i.e. Perform statically/dynamic walk, turn, detect an obstacle, walk up an incline and resemble a tyrannosaurus class of dinosaur.


Follow this link for full Verification and Validation Test Plan:

Verification & Test Plan

Spring 2016 Velociraptor: Updated Walking Code #3 (Final)

By: Ashlee Chang (E&C)

Table of Contents

Fulfilling Requirements

Level 1 requirements #4 is stated as follows:

The Velociraptor shall be able to statically walk on all surfaces of the course.

Level 2 requirements #9 is stated as follows:

For the Velociraptor to have the ability to travel up a 6.5-degree incline, an accelerometer shall be implemented to preserve the chassis balance.

Level 2 requirements #10 is stated as follows:

An ultrasonic sensor shall be implemented to the build of the robot to detect obstacles at a range of 20 cm.

Level 2 requirements #11 is stated as follows:

To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at a an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles.

Level 2 requirements #11 is stated as follows:

To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at a an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles.

Level 2 requirements #13 is stated as follows:

To establish the wireless connection between the Arxterra Application and the Velociraptor in order to control the robot a Bluetooth communication shall be executed into the system’s robot design.

These requirements were to be met through C++ coding done through Arduino’s software editor. However, due to the load of work in such tight time constraints, the dynamic walking is incomplete and the incline walking code is unfinished. This will be explained in the concluding remarks.

Final Arduino Folder

Below is a link to the final folder. The entirety of the folder will be broken down in this blog.

arxrobot_firmware FINAL

The original Bluetooth folder passed on utilized 20% of program storage memory. Some unneeded files were removed to conserve memory in the arxrobot_firmware folder: battery_selector and fuel_gauge. This brought down the program memory to 14%.


Contents of the final velociraptor folder

Look-Up Tables

As explained in the Walking Code #2 blog, servo angles were moved to Flash memory to compensate for the SRAM limitations. The majority of the code is within the cells from 1-170. Originally over 400 cells long, the LUT size has been optimized in trade-off with more if-then statements throughout the code. The LUT size could be shortened further.


LUT explanation

In cells 1-40 and 81-120 in the excel spreadsheet, the left leg and right leg will take a step. In 41-80 and 121-160, all leg servos are re-initializing as the head and tail sway directions. Lastly, 161-170 are dedicated to pre- and post-turning arrays. The point here is to bring the body closer to the floor so that the velociraptor could grasp the floor more roughly while turning.


For this blog, the turning code has been implemented. There were several approaches the group has brainstormed to accomplish this. By accident, it was discovered a turning mechanism could be a dragging mechanism where one leg drags behind as the other scoops backwards. It not only proved to be an effective turning method, but also the LUTs used for walking were also capable here. Originally, the turning code for each foot was over 100 cells long and took up 65% of program storage space. By using the same LUT values for static walking and turning, the space was optimized so that only 48% of program storage space was used.


Program storage space optimization results

Object Detection

The velociraptor head measures 7 inches long. Thus, it was coded so that any object 6+7=13 inches in front of the ultrasonic sensor (half  of a foot from the head) would prohibit the velociraptor from moving forward. The user would have to hit the left or right turn button and go on from there.


Upon passage clearance, the forward button will work


Only four buttons were needed for our project: forward, left/right turn, and dynamic walking. Only the third and fifth element of the package were used in our particular application, which basically dictates which button is pressed. Additional coding was needed to make up for the fact that the Arduino Micro is a Leonardo device. Below shows one of the many modifications made by the S&T division manager to allow our Bluetooth to communicate with the Arxterra app.


Leonardo device modification

Unfinished Business

Time constraints disallowed the further progress of the velociraptor as of the due date. In the LUTS, cells 171-355 (un-optimized size) are dedicated to dynamic walking. It was an in-progress task that was ultimately unsuccessful. A demonstration could be done, but the user would need to hold the robot as it jerks from side to side. It was difficult to code the velociraptor using momentum to keep afloat–finding that sweet spot between balance and imbalance.

The analog accelerometer is capable of sensing incline and using that data to initiate a new walking code that would bring the center of mass towards the head. This would require a completely new walking code with new angles: due to the geometry of the legs, just “re-positioning” all leg servos by the same angle would not in effect allow the velociraptor’s original walking code to walk any longer. A new set of angles need to be discovered where these changing angles would stay perpendicular to the floor. Not to mention, there arises a problem on how the velociraptor will react once it slowly reaches the 7* incline (i.e. before hitting the full 7* incline, the velociraptor already starts tilting backwards).


Spring 2016 Velociraptor: Updated Block Diagrams

By: Camilla Nelly Jensen (Systems Engineer)

According to the Critical Design Review Debrief, the team had made some error in the CDR powerpoint. These errors have been fixed and shown below.

For the System Design, the Active Control Circuit for the software blocks of the dynamic walk was missing and thus that circuit has been updated along with the rest of the system block diagrams for the Velociraptor in this blog post. Likewise, the interface matrix has been updated in order to show leftover available pins of the microcontroller.


blog post pic

 Figure 1: Updated System Block Diagram

The system block diagram displayed in figure 1 shows the interface connections of the inputs (Arxterra application) and outputs (servos) of the Velociraptor. For the updated version both sensors, ultrasonic and accelerometer and Bluetooth module have been mounted on the PCB along with the microcontroller, some directly into the pins of the microcontroller in order to minimize the use of wires to establish connections. Since microcontroller requires voltage input of 7-12 V, two batteries in series (3.7V*2=7.4V) have been placed on the head to provide that. The other two batteries have similarly been placed in series on the tail but as the servos require an input voltage of 6V the batteries have been connected to a voltage regulator to downsize the 7.4 V to match the 6V for the servos. The location of the batteries has been chosen to minimize the weight on the body of the robot.


Interface matrix Final

Figure 2: Interface matrix

Figure 2 shows the components of the Velociraptor’s pin connections and the leftover available pins on the Arduino Micro Atmega32U4 microcontroller board. The interface matrix hasn’t changed much from the PDR since we decided to go with the original components after testing other components. This comprises testing of the accelerometer where the first objective was to use the MPU-6050 3 Axis Gyro Accelerometer Sensor for the Velociraptor to detect an incline. But after testing the accuracy of the gyro-accelerometer is showed an error of 1-2° degrees and took up too much memory of the microcontroller and thus the group decided to go back to the original accelerometer ADXL335 that detected inclines more accurate and takes up less memory. Likewise, with an ultrasonic sensor the first intent was to utilize the HC-SR04 Ultrasonic Ranging Sensor but during tests, the sensor would loose signal and thus not valid to use for the Velociraptor to detect obstacles. Therefore, the group decided to change to the MB1030 LV-MaxSonar-EZ3 Ultrasonic Rangefinder, which operated to the accuracy listed in the datasheet and did not loose signal. The ultrasonic sensor is, therefore, the only component that has been changed for the setup and the LV-MaxSonar-EZ3 utilizes one pin less than the HC-SR04 only a TRIG pin.


Software block statical w_ legend

Figure 3: Active control circuit for statically walk

The software block diagram in figure 3 shows how the input command is sent via the Bluetooth module and through what pinouts to reach the Arduino firmware blocks to be decoded and handled before sent as subroutines to the output components, the servos to act the subroutines sent. The sensors, ultrasonic and accelerometer also gives inputs to the subroutines of the servos and thus if the ultrasonic sensor detects an obstacle the input routine shall block the MOVE subroutine for the servos. Likewise with the input from the accelerometer, if it detects an incline, an input routine will be sent to the servos subroutine and change the subroutine (walking code) in order to adjust to the incline.

For the Velociraptor, we are only sending commands from the Arxterra application to the servos to perform and not receiving any data from the components to the Arxterra application. The orange example box on the left shows how telemetry/data from the batteries could have been implemented and handled; the status of how much power the batteries have left could have been remotely sent back to the Arxterra application via the Bluetooth’s receive (RXD) channel in order to keep a real-time track of when to recharge the batteries.


Software block Dynamic w_legend

Figure 4: Active control circuit for Dynamic walk

Spring 2016 Velociraptor: Spring Experiment

By: Mingyu Seo (Manufacturing & Design Engineer)


After assembling the final prototype and testing the static walk, we’ve found the weight of the head and tail were straining the servos. We’ve decided to use a spring to support the weight, which lead us to perform a quick experiment to see how much the spring will help support the weight. A variety of miscellaneous items were use as mass to test the spring constants.



Figure 1. Experiment procedure

Figure 1. shows the experimental procedure to test the spring. We’ve added weight to see the extension of the spring, and to see how much the spring will be able to support with maximum of 300 grams due to our head and tail only weights 200 grams with the battery included.



Figure 2. Experimental Data



Figure 3. Attached spring to the head of the robot.


By adding a spring we were able to reduce majority of the stress applying to the servos. By removing the stress on the servos we also conclude that it reduces the power intake of the servos because the servos no longer hold the full weight of the head and tail. To see how much power is consume refer to the servo load test blog post.

Spring 2016 Velociraptor: 3D Smoothing

By: Mingyu Seo (Manufacturing & Design)


In order to accommodate mass budget of the robot, our team has decided to create the legs and the top using 3D filament polylactic acid (PLA). One of the drawbacks of using 3D printing method is the result of the prints having ridged surface texture created by the layer by layer printing. There are multiple solutions for smoothing surface of PLA 3D prints to make the final product better. We will be looking at 2 methods that are safe and simple to apply.

3D printer setting:

Layer height (mm): 0.25

Shell thickness (mm): 1.2

Bottom/Top thickness (mm): 1.0

Fill Density (%): 25

(Leg Picture here)

The picture shows the one of the finished print for the right leg, which we could clearly see the ridged surface texture.

Smoothing Methods:

  1. Acetone Bath
  • Acetone bath is one of the most commonly used method to smooth out PLA and ABS materials. It melts the outer plastic and creates a smoother and glossy looking surface. Acetone bath is the simplest and fastest method to smoothing 3D materials.


  • (Optional) Sand the 3D material using sandpaper (P320 most optimal) to smooth out the ridged surface.
  • Pour enough acetone in a container (Just enough to fully submerge the part)
  • Keep the part submerged for 40 ~ 60 seconds
  • Take it out and dry.

(*CAUTION: make sure to use gloves when handling PLA due to melted plastic)

2.  XTC-3D epoxy

  • XTC-3D epoxy has lately been getting attention in 3D community which uses 2 liquids that are mixed together and then brushed onto 3D prints. Due to XTC-3D is a protective coating that does not melt plastic, so sanding all parts before applying is highly recommended.


  • sand all surfaces of the 3D parts using P320 or P600 sandpaper.
    • starting off with P600 may be a safer option,
  • Apply coating on to 3D parts using a brush.
  • Dry for minimum 4 hours.

XTC-3D coating works with all 3D materials as well as wood, plaster, fabric, cardboard, and paper. It’s easy to apply but takes a long time to dry. It takes minimum 4 hours and may need to be applied several times to have a unified smooth surface.



To decrease production time, our team has decided to incorporate acetone bath to our final product. Program Level 1 Requirement 1 states the Velociraptor biped robot shall demonstrate its feasibility as a toy. To fulfill this requirement, acetone bath will not only help to smooth out the rigged surface but also improve the look of the final product.

Spring 2016 Velociraptor: Hardware &Simulation

By: Mingyu Seo (Manufacturing &Design)


The purpose of this blog is to show the feasibility of the design we’re going to incorporate in to our robot. Using Solidworks, we’ll be able to validate center of mass of the robot when we’re performing static walking. Also by using the simulation on Solidworks, it’ll show the basic motion of the robot walking. Following hardware design will explain the problems and solutions we’ve made to find the most suitable design of Velociraptor.


Project Level 1:

  1. Requirement 1 states the Velociraptor shall resemble a Tyrannosaurus class of dinosaurs as given in the objective.
  2. Requirement 2 states the word “biped” is defined as having two feet; therefore, the Velociraptor shall use two legs to move.
  3. Requirement 4 states the Velociraptor shall be able to statically walk on all surfaces of the course
  4. Requirement 5 states the Velociraptor shall be able to dynamically walk on flat surfaces of the course.

Project Level 2:

  1. Requirement 4 states to resemble a Tyrannosaurus class of dinosaurs, the chassis of the Velociraptor shall be cut out in hollow body parts to assemble a frame-like body structure in a material that is cost effective
  2. Requirement 6 states to maintain balance while performing static walking, a head and tail shall be implemented to the chassis of the Velociraptor

Overall, the design of the robot must resemble a Tyrannosaurus class dinosaur, that walks on two legs, and by incorporating the head and tail will help keeping the robot balanced when it’s performing static & dynamic walk by shifting the center of mass using the weight of the head and tail. New designs were incorporated in to our new design to accommodate mass, price, and power budget.

Hardware Design:


Figure 1. Final Design of Velociraptor (excluding sensors)


2 (2)

Figure 2. Exploited View of Velociraptor

First Design:

right leg

Figure 3. First design of the joint

Figure 3. shows the first design of the joint which incorporates the 3rd joint that was missing from the previous generation. The new design also incorporates a new design of the ankle where it’s connected with 2 parts rather than 1 that holds the leg and the foot, which helps the foot to stay parallel to the surface at all times.

Problem: when assembling the first design, we had few design problems

  1. The 3D printed parts were not sturdy
    1. Not strong enough to hold up the weight of the body
    2. putting too much pressure on the base of the foot started bending parts.

Second Design:

kinda new right leg

Figure 4. 2nd Design of the joint

Figure 4. incorporates the fixed design of our first design. We made all our parts minimum 0.3 cm thickness to prevent our parts from bending. The front joint that connects from front servo to the knee has thickness of 1.2 cm to have a more stable stance, and make sure it’s sturdy enough to hold the weight of the robot.


  1. By increasing the thickness of the joints also increased the angle the head and tail must turn in order to shift the center of mass when performing static walk.
  2. When designing the 3D model, the design did not compensate the extra length added due to servo caps.
  3. The thickness of the foot was still too thin.

Final Design:

New right leg

Figure 5. Final Design of the joint

Figure 5. shows the finalized design of the leg of Velociraptor.

Final Features:

  1. Shifted the front top joint (connecting from front servo to the knee) to the out in order help the robot to find center of mass by moving the head and tail less.
  2. Also have incorporated the placement for the servo caps to bring it closer to the center.
  3. All parts have minimum 0.3 cm to have a stable stance when it’s performing static walking.
  4. Extra length toward the back and outer side of the foot to have a more stable and balanced walking.

PCB placement:

First when we were designing the robot, we have decided to place all the sensors and the pcb underneath the servos. After finishing our PCB layout, we have found the size of the board too big to be placed under and due to the size of the voltage regulator it was not applicable to fit all the components under the robot. In order to solve this problem, we have decided to create a clear casing on top of the robot and place all our components in.

Design Features:

  1. Bottom of the case have been cut out in order to bring the wires underneath and hide it.
  2. hole has been placed on the front side of the casing to place the ultrasonic sensor.
  3. casing will be made with a clear PLA filament to show the components inside.
pcb placement

pcb placement2 Figure 1. Design of the casing to hold up the PCB and also the top view of the casing



The simulation below shows the motion of the Velociraptor when it’s performing static walking.

In order to balance on one foot, we need  to move the center of mass above the supporting leg by moving the head and tail toward the supporting leg for counter weight.



This simulation shows the given dimension of the 3D model shows the feasibility of the design of the Velociraptor, and confirms the level 1 requirement 4, which states the Velociraptor being able to statically walk across the full course. The design that we have incorporated have been tested and resulted as successful when we’ve performed static walking. Biggest issue was trying to keep all wires and components hidden but due to the size of the PCB and the size of the voltage regulator heatsink we have decided to mount it on the top of the robot. The Head, Tail, and bottom plate for the robot was made with Aluminum, but the legs, top plate, and the PCB casing will be printed using PLA filament.

Spring 2016 Velociraptor: Critical Design Review Debrief

By: Khoi Vu (Project Manager)


The Critical Design Review (CDR) purpose is to present data and progress of the project to the President and the Customers. The CDR presents the executive summary, system and software design, experimental results, interface definition, and the custom PCB design that will be used on the final product.


For full PPT of CDR click on the link below:




  1. In the executive summary, there should be an exploded view of the 3D model of the product that contains the name of the person responsible for each slide.
  2. Executive summary should always be short, summarizing the project design and design features.
  3. System design should not show the PCB.
  4. Servos tests in the experimental result were done incorrectly; a stick lever arm was used as lever length changes during rotation. A circular lever arm will give a more accurate result because it will have a consistent radius.
  5. Incline testings did not show how the robot will respond to the incline when it is walking sideways on the incline instead of walking up the incline.
  6. Power test did not give a accurate result of power consumption by the servos, a ammeter should be used to connect in series to find the actual power consumed by the robot since the robot has been completely assembled.
  7. PCB schematic was not presented clearly; a white background with black lines would be much easier to see.
  8. Since the robot is taking in a lot of Current (5 Amp), a fuse is recommended to protect the components of the robot.
  9. Active Control Circuit is missing for the dynamic walking requirement. The team should still acknowledge all requirements that have been listed.
  10. The team should consider how the robot’s foot should always be parallel to the ground and not always the x-axis. This may cause failure when walking over obstacles and inclines.
  11. Verification and Validation tests needs to show more results.
  12. Resource report values that were measured should not contain any uncertainty since the values were measured and not estimated.
  13. Cost Budget should also contain the cost of parts that were donated to show a more accurate cost of the whole project.
  14. Final printing should not start when PCB size is not known yet.


Number 5 was tested and the results were shown in CDR PPT,  however, the team may have not discussed the results in depth.

Number 14 printing only consist of parts such as the legs that have been enclosure, the team have not finalize the design for the PCB container, therefore, we have not printed the PCB case.





Spring 2016 Velociraptor: PCB layout

By: Mingyu Seo (Manufacturing & Design)

PCB Design:

For our design, we’ve started off by planning where our PCB is going to be mounted. Rather than placing it on top or inside the body frame, we’ve come up with mounting the PCB underneath the body to cover wires connecting all the components together. So, we have decided to mount the Arduino Micro as well as the accelerometer in order to minimize the number of wires connecting to the PCB. We decided to wire the Bluetooth toward the tail and the accelerometer on top to make sure it’ll be able to detect obstacles ahead.


  1. The voltage regulator may cause too much heat.
  2. Minimum space to place all components
  3. Sensors mounted directly to the board must either be mounted so that they hang off the edge of the PCB, or the packages must be edited to include the physical shape of the device to avoid overlap of components.


  1. we will be using thru-hole heatsink method rather than PCB copper heatsink. Also by placing the voltage regulator to the corner, we will be using TO-220 Heatsink. 
  2. Due to very little space provided for PCB layout, we will have to make sure to place the power supply as far away from the Bluetooth, accelerometer, and ultrasonic sensors as possible.
  3. we have a 5.12cm x 4.8 cm PCB layout, which must incorporate Arduino Micro, Accelerometer, Bluetooth, ultrasonic sensor, 8 Servos. By placing all the sensors on one side, we will be able to mount the accelerometer off the edge of the PCB, and connect Bluetooth and ultrasonic sensor with a wire.


PCB Layout:

PCB layout FINAL 2

Finalized PCB layout

PCB layout FINAL

Finalized PCB layout Wiring


Spring 2016 Velociraptor: Material Trade-Off-Study Update

Requirements needed to fulfill:

  • Project Level 1 Requirement:
  1. According to the given course that the robot is to complete, the Velociraptor shall travel on multiple surfaces. Refer to course analysis for more detail.
  2. The Velociraptor shall be able to statically walk on all surfaces of the course
  3. The Velociraptor shall be able to dynamically walk on flat surfaces of the course.
  4. The Robot shall statically travel up a 6.5-degree incline according to the course analysis
  • Project Level 2 Requirement:

6. To maintain balance while performing static walking, a head and tail shall be implemented to the chassis of the           Velociraptor to even out the shifted weight when standing on one leg and           thus meet the Project Level 1, requirement

8. In order for the Velociraptor to travel on two different surfaces, the material that will be placed on the feet shall           have a coefficient of friction of more than 1.0 in accordance to the                      Course Analysis as to refrain from slipping,               and thus meet Project Level 1, requirement 3.

Actual experiments will be done to verify the feasibility of the design using our 2nd prototype.


  1. Material Trade – Off- Study:

a) First Experiment included the feasibility of using 3D filament Polylatic Acid (PLA) for our final robot. When we started building our 2nd prototype, including the head and tail, we’ve decided to distribute the weight of the body by placing the batteries toward the head and tail to put less strain on the servos. By using this design, we will be able to minimize weight of the chassis of the robot and use the weight of the head and tail to shift center of mass.


But putting more weight toward the head and tail, caused the bottom piece of the body that connects the head to start cracking which made us do a material trade-off-study to determine the right material for our robot.



Trial using PLA filament



Trial using Aluminum


The printing the bottom piece using the 3D filament weighed 13 grams compared to Aluminum piece which weighed 19 grams. This not only shows the feasibility of using Aluminum for our bottom piece to maximize the weight on the head and tail, verifying project level 2 requirement 6 to implement head and tail on the chassis to shift the center of mass to balance when it’s performing static walking.


b) The second experiment was conducted in order to verify the 3D filament PLA is feasible perform static and dynamic walking on various surfaces without slipping.

Level 1 requirement 6 states the robot should perform static walking on a 6.5 degree incline, so we’ve created inclines using various degrees to determine if the robot was able to balance and refrain from slipping at a minimum of 6.5 degrees. For our experiment, we started off by creating a slope from 4.5 degrees to 13.7 degrees and tested to determine the degree the robot starts slipping.  In order to create a similar static friction of the course, we have implemented a carpet on the incline. For experimental measurement, we’ve used a protractor to measure the angle of the slope, and for the theoretical measurement, we’ve used the length and height to calculate the slope:


Both feet on Ground:

friction test chart 1

The chart above shows the acceptability of the 3D model, when we assembled the robot, it was able to stand with both foot on the ground up to 15.7 degrees without slipping or falling.

Figure 3b

Placed sideways on a 8.7 degrees incline, successfully balancing and refraining from slipping.

Figure 3a

Robot placed on a 8.7 degrees incline without slipping or falling.



One foot on Ground:


friction test chart 2

When the robot is performing static walk on incline, we’ve tested if it was able to balance on one foot without falling or slipping. As shown above, the experiment showed the robot was able to balance on one foot up to 9.7 degrees incline.

OLU 3a

By shifting the weight of head and tail toward the shifting leg, the robot is able to stand on one foot as if it’s performing static walk. It’s able to stand on a 8.7 degrees incline without slipping nor falling.



Using a thicker material for the bottom piece will not only increase printing time, but also create less space for our components to fit. But by using Aluminum for the bottom piece of the body to hold the head and tail, not only will it be able to hold up to 483 grams but also we will be able to keep enough space in the middle to mount the PCB. The test to verify the material used to refrain the robot from slipping have been successful. The robot was able to stand on both feet and on one foot up to 9.7 degrees without slipping. When the robot has to stand on an incline of more than 10 degrees, we will have to reconfigure the robot’s ideal standing position to slightly lean forward in order to make sure the center of mass stays in the middle of the robot’s body.