By: Khoi Vu (Project Manager)

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.

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: 

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:

Joints:

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:

Sensors:

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

Accelerometer:

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:

Finalized System Block Diagram

Microcontroller Trade-off study:

Bluetooth Arxterra Communication:

Bluetooth setup

Experimental Results:

Power: 

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.

Incline:

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.

Springs:

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

Breadboard:

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

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.

Turning

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.

Bluetooth

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:

Verification/Validation:

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.

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.

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.

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.

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

Final 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

By: Ashlee Chang (E&C)

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.

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

Bluetooth

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

By: Mingyu Seo (Manufacturing & Design Engineer)

Introduction:

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.

Procedure:

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.

Conclusion:

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.

By: Mingyu Seo (Manufacturing &Design)

Introduction:

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.

Requirements:

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)

Figure 2. Exploited View of Velociraptor

First Design:

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:

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.

Problem:

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:

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.

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

Simulation:

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.

Conclusion:

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.

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.

Problems:

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.

Solutions:

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:

Finalized PCB layout

Finalized PCB layout Wiring