Approved by Tim Haddadian (Manufacturing Division Manager) and Lam Nguyen (Project Manager)
Table of Contents
Requirements
Level 1-1 The 3rd generation Velociraptor (W) budget shall not cost more than $102. This estimate is based upon the customer and project team agreement on October 7th, 2016.
Introduction
For the materials, cost and mass of the materials were taken into consideration to meet the Level 1-1 cost requirement.
Materials
For choosing the material, cost and mass of the material should be considered to meet cost budget. The materials chosen for trade-off are the following: aluminum sheets, birch plywood, polylactic acid (PLA), acrylonitrile-butadiene styrene (ABS), and acrylic sheets. Since it is difficult to compare materials that are sold in different sizes, a set dimension is chosen, a volume of 6 inch by 3 inch by 0.125 inch. The reason for the 0.125 inch thickness is due to 3mm thickness limitation for 3D printing. The size 6 inch by 3 inch is chosen for further stress test to analyze which material is the strongest and which is best utilized for maintain the structure of the robot without breaking.
Calculations
Using the set volume, the mass of the volume of material is calculated given the density of the material and cost per cubic inch. The table below shows the given cost and density of the materials.
Table 1. Materials Cost
Calculations document
From the given cost and density, the cost and mass of the volume is calculated. The work shown for the calculations are also linked below.
In conclusion, Baltic birch plywood is the lightest and cheapest material calculated. This would require laser cutting for the designing components of the Velociraptor. If components are too complex to laser cut, then 3D printing will be used. For the 3D printing filament, ABS will be chosen over PLA. Further stress tests will be completed through experimentation.
https://www.arxterra.com/wp-content/uploads/2016/12/FI-Material-Trade-off-Choi.png144144LamNguyen/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngLamNguyen2016-12-17 10:11:392018-03-09 08:17:38Fall 2016 Velociraptor (W): Material Trade-Off Study
By: Gifty Sackey (Mission, System and Test Engineer)
Approved by:
– Lam Nguyen (Project Manager)
– James Lee (Division Manager for Mission, System and Test)
Level 1 Requirements
The 3rd generation Velociraptor (W) budget shall not cost more than $102. This estimate is based upon the customer and project team agreement on October 7th, 2016
The 3rd generation Velociraptor (W) biped robot shall demonstrate its capabilities during EE 400D Final for Wednesday on December 14, 2016 according to the CSULB Calendar 2016-2017 Final at 9:00 am.
The 3rd Generation Velociraptor (W) should resemble a Velociraptor of the Theropodous Dinosaur Suborder. [1]
The 3rd Generation Velociraptor (W) will use a 3DoT board embedded system.
The DC motor can support the mass of the robot with a 50% margin
The 3rd generation Velociraptor shall operate for a minimum of one hour with an external power resource minimum of 1560 mA-Hours.
The 3rd Generation Velociraptor (W) shall use an external PCB with an I2C interface as the 3DoT board.
The velociraptor shall use a 3DoT board library and utilize I2C to communicate with sensors, A/D converter, and GPIO. [4]
Level 2
The 3rd generation Velociraptor shall weight no more than 350 grams
The 3rd Generation Velociraptor (W) shall turn 0-360 degrees on one leg under one minute
The 3rd generation Velociraptor (W) shall create custom commands to be used with the Arxterra Control Panel
The velociraptor shall use the IMU MPU6050 that tracks acceleration and gyration that can provide X and Y angles to +/- 6.5 degree precision
The velociraptor shall use a rotary sensor that tracks at 90 degrees’ precision to determine the position of leg. The leg position controls the head and tail location
The velociraptor shall support the mass of the robot with a 50% margin, 522g in a 0 degree position (Footstep is down on the ground)
The velociraptor shall support the mass of the robot with a 50% margin, 522g in a 90 degree position (Center of foot path on ground)
The velociraptor shall support the mass of the robot with a 50% margin, 522g in a 180 degree position (Time before foot goes to ground)
The velociraptor shall control the head and tail movement with a single servo using gear trains
The head and tail shall use one servo that operates at an optimal torque of 18-45mN-m to maintain center of gravity
The CoG on the axis of the H/T shall be controlled by one servo while being placed over the foot
The velociraptor will not exceed a rating of 1A with the use of the LDO with the external PCB
The velociraptor shall utilize custom telemetry commands that will be displayed on the Arxterra Control Panel
The 3rd generation velociraptor shall walk on a flat surface
The 3rd generation velociraptor shall walk on a surface texture
The 3rd generation velociraptor shall walk on an incline and decline surface
The 3rd generation velociraptor should perform dynamic walking while on a flat surface
The 3rd generation velociraptor should perform dynamic walking while on a surface texture
The 3rd generation velociraptor should perform dynamic walking while on an incline and decline.
The 3rd generation velociraptor should perform dynamic walking while on a step
– James Lee (Division Manager for Mission, System and Test)
Introduction
This blog post will be discussing velociraptor’s communication system; the ArxRobot app and the Arxterra Control Panel that is used to control the robot. At this point in time, the velociraptor group has been able to settle on a design for the velociraptor robot and is currently working on the systems and electronic controls for the robot.
Commands
The velociraptor robot will be able to receive commands through two main modes. It will be either through the community mode or remote control mode. In the event that the velociraptor will be receiving commands from the android phone, the Arxterra app would need to be configured into a remote control mode to make it possible. On the task bar located on the first line of your app, select the button that resembles the app logo merged with the phone. Once the user selects this, they can then select remote control mode. If the user would like to change the control settings back to the control panel, follow the steps above regarding which tab button to select but instead choose the community mode to activate the control panel. When the control commands are sent from an android phone to the velociraptor robot, this communication is made possible with the help of the HM-10 Bluetooth module embedded in the 3DoT board with the help of WIFI or data services from the phone company.
Diagram 1: This shows when the robot has been located before boarding.
Students are allowed to have custom commands on the app and have the commands be unique to their robot. Command types must have their own unique identifier called a Command ID. These ID’s can be chosen from a range of 0x40 (64) to 0x5F (95). For our velociraptor group, we will have a custom command for static walking. The custom command for walking is being defined with the hexadecimal number 0x42. The static walking custom command has been created as a Boolean type whereby the user is allowed to either select an on or off. By default, the static walking custom command is created to be in the off mode.
The following image provided below displays the control panel after the Velociraptor robot has been boarded from the control panel. On the control panel, towards the right side of the screen the app connects to the phone’s camera. Aside from the custom commands that can be designed by students, there are some examples of telemetry commands that are embedded in the application. Amongst these are options for the user to be able to display the phone’s battery, roll and pitch. Students are able to access these modes through the robot capabilities configuration.
Conclusion
In order to have the custom commands displayed on the control panel, the user has to select the community mode. On the other hand, to be more secure with the robot and its commands, users are also allowed to control the robot using the remote control mode option instead. When user’s control the robot from the remote control (phone), they are limited with the options and commands they see on the screen.
Diagram 1: This shows when the robot has been located before boarding.
Diagram 2: Clicking on the green robot allows students to board the robot
Diagram 3: Shows the communication to the phone’s camera
https://www.arxterra.com/wp-content/uploads/2016/12/Featured-Image-Bluetooth-commands.png144144LamNguyen/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngLamNguyen2016-12-17 08:46:062018-03-09 08:17:38Fall 2016 Velociraptor (W): Bluetooth Commands
Kevin Armentrout, Electronics and Control Engineer
Victoria Osaji, Manufacturing and Development Engineer
Table of Contents
Project Overview
Mission Profile
3rd Generation Velociraptor is a robot developed by the CSULB 2016 Fall Semester class that will compete in a Jurassic/Modern Game: Save The Human with other toys on the last day of class, December 15, 2016. The game will involve Velociraptor chasing another robot through various terrain by tele-robotic communication on the Arxterra Control Panel. The arena and terrain the Velociraptor must traverse is developed by the Game Committee. The mission will display the robotic applications of the 3DoT Board developed by Arxterra and Velociraptor’s movement capabilities. – PM Paul Ahumada
Project Objectives
The Velociraptor is a dinosaur toy
The Velociraptor is on a deadline
The Velociraptor will use a 3DoT board
The Velociraptor will be controlled by an Arxterra Control Panel
The Velociraptor will play in a game
The premise of the Project Objectives is that they are derived from the Mission Profile. These objectives that have been simplified will establish every requirement that will be used to build the Velociraptor (Th) robot.
System Design
System Block Diagram
The system block diagram is an overview of what is needed int he project. Different systems can be viewed from this picture. The blue colors are for the linear actuators and sensors not located on the external PCB or 3DoT Board. Purple is for the mechanical characteristics of the robot. Red is for external power that is not on the external PCB or 3DoT Board.
One unique modification to the 3DoT board is bypassing the boost converter which can be seen in the System Block Diagram image. There was a current limit to the boost converter the Velociraptor team wanted to avoid because the maximum currents for the DC motors was above the current limit for the boost converter and polyfuse and be detrimental to a demonstration if an issue occurred.
Subsystem Design
Interface Definitions
Interface Matrix
3DoT Board Available Pins
The interface matrix for available pins lets the Velociraptor Team know what is readily accessible to use and which connector it will be located at. It is as if one looks at the 3DoT board as a black box with several inputs and outputs. The Available pins has every input and output located on the 3DoT Board and what it will be connected to in the project. The rows are what the 3DoT Board has and the columns are what the team intends to connect to the 3DoT board.
MCU Pins
The MCU Pin connections image purpose is for coding. Every pin from the MCU is accounted for and the programmer can determine what they intend each pin’s function. There are pins on the MCU that cannot be accessed and have end traces and are left as ‘end trace.’
Wiring Diagram
The wiring diagram is generated from feedback of the electronics and control engineer and is utilized as a reminder for what connections to purchase and what space must be allowed when sizing the mechanical model. The connectors for each actuator, external PCB, or sensor are labeled so no confusion occurs when assembling the PCB board.
Mission Command and Control
Software Block Diagram
The Software Block Diagram began the process of writing the firmware and finding the needs for inputs from Arxterra. The software block diagram has a light blue color where firmware will take over coding. For static and dynamic walking, the robot needs to differentiate between the walking style and the easiest method to implement that was to have a dynamic push button.
An addition to the diagram would be that was originally not required of the project. As a goal, the team made it a challenge to send telemetry back to Arxterra.
Arxterra App and Arxterra Control Panel
Arxterra Phone App
When customizing the needs for Velociraptor’s custom Telemetry and Commands, the MST needed to start with the phone app. The phone app has custom command and telemetry Custom Entity Definitions that can be created and modified.
For telemetry, the team was interested in reading numerical values of roll, pitch, shaft right of the leg, and shaft left of the leg. Pitch and Roll are rotation angles from 180 to -180 degrees. The shaft positions are 0 to 360 degrees for the legs. The four variables are all singles (4 bytes) being sent to Arxterra Control Panel.
For commands, a dynamic mode button (boolean) would allow users to change between static and dynamic mode. By pressing the button, the servo used to control the body would be turned on/off.
Arxterra Control Panel
The layout of the Arxterra Control Panel is generated after choosing the entities from the Arxterra App on the phone. The custom command and telemetry is displayed along with GPS and a live stream feed of video from the user’s phone.
Custom Commands and Custom Telemetry
Defining Custom Commands and Custom Telemetry and Declaration of Custom Command Functions
The custom commands and telemetry are defined at the beginning of the program to reserve their address space. Numbers below 0x40 are already defined elsewhere for built in commands and telemetry.
With newer versions of Arduino, functions that will be used for the custom commands are created before setup where the variable declaration is, similar to C++. The custom command for the dynamic button and move handler are used for Velociraptor. The reason a custom move handler is used is because there needed to be modifications for the motor control of the robot. The 3DoT board was designed for use with wheeled robotics and the Velociraptor is a biped. The DC motors need to be controlled with precision, which will be defined in firmware.
Telemetry Classes
The defined variables for telemetry are implemented into this section with the Packet Class. The constructor reads the unique variables so telemetry can be sent as different objects all part of the Packet Class.
Sending Telemetry
For telemetry being sent to Arxterra, a local variable is created that is cast into unsigned bytes. The local variable will be initialized as a casted variable setup elsewhere in the firmware. For example, the image above has a temp variable casted as an unsign_16 and the right shaft reads that value to be sent out with the class function ‘sendSensor(…)’.
The schematic contains the SMD’s used for the external PCB required for Fall 2016. There is an I2C interface that has 4 wires coming from the 3DoT Board to the External PCB using Vcc, SDA, SCL, and Gnd.
Breadboard and Fritzing
The schematic was placed onto a breadboard to see if the circuit behaved as the team wanted. The electronics and control engineer received outputs for the rotary sensors and the IMU sensor. These two sensors are what made our PCB external.
The Verification and Validation Test Plans is what our team had to complete for this semester. These items were determined by the customer in the Verification/Validation Matrices.
The test plans have pass/fail tests for each requirement. For our Project, we failed all dynamic tests because of the lack of time and capability to implement a dynamic control mechanical model. The team was also not able to create a dinosaur image that the customer wanted and failed validations.
Project Status
Power Allocation
The Power Report shows that the Velociraptor team is at ~380mA and the Project Allocation is at 650mA. The robot at a 50% margin is 570mA and is thus at a safe operating range and has enough power being received to operate for over an hour based upon the CR123A being used.
Mass Allocation
The Mass Report is based upon the torque needed to drive the robot, which is 657g at a 50% margin. The robot weighed 315g and that is below our 50% margin. The robot motors are capable of moving the mass.
Cost Report
The budgets were determined by the customer in October and this was based upon the cost allocations for each resource. The customer determined what could be provided and what could not be. In this report, their are items with $0.00 and they were provided by the customer. Items covered by the customer helped the team lower the budget to $95.71 and be below the Project Allocation set aside by the customer of $150.00.
Product Break Down Structure
The PBS looked at different categories that would create this project. The image lets the team know all the items that need to be completed for the project in different categories.
Movement Systems encompass actuators and mechanical modeling. Control has the sensors. Software Control has communication and programming applications. Power has all components that use power or deliver. 3DoT/PCB has SMD’s and connections the team must be aware of during project building.
Work Break Down Structure
From the PBS, tasks are divided among the engineers through the WBS. This semester was unique because we lost our Systems Engineer and the Project Manager had to take over that position. Roles of the System Engineer were covered by both PM’s of each Velociraptor.
Schedule
The Burn down Schedule has 3 graphs: expected project completion timeline (blue), actual project completion timeline (orange), percent completion (gray). As can be seen, the project lagged behind the expected project completion timeline and the team was forced to put in more time at the end of the semester. The complexity of the mechanical modeling, such as the legs, pushed back schedule and E&C’s capability to test the robot.
The project is 91% complete and misses implementation of rotary sensors with IMU, UCI linkage leg design, foot design, and firmware control algorithm.
The Velociraptor Project had challenges that proved difficult to get around. The UCI or Theo Jansen Linkages could not be implemented because the Simulation verse Real-world creation of the linkages was different. The delays caused by the leg sets pushed back the control algorithms used to move the robot and a simplistic version had to be created for final project demonstration. Also, the foot design for any biped is something that needs to be handled in the beginning and likely require an actuator to maintain the robot’s stability.
For future projects, the mechanical modeling is crucial to focus on because it will cause the project to fail. Lessons to take from this semester are:
Focus on leg linkage design early. How the linkages move when connected with screws is different than how they move in Solidworks
Do not ignore the foot design. The foot must be parallel with the body and the ground to increase stability. If not, the CoG will change as the pitch angle changes
Have Electronics and Control Engineer be familiar with I2C communication. The team was lucky to have an engineer more than capable of finding solutions to problems with I2C addressing locations for the sensors
By: Victoria Osaji, Manufacturing and Development Engineer
Table of Contents
Introduction:
A printed circuit board (PCB) also known as a printed wiring board is used to build the infrastructure for electronic devices. The purpose of this infrastructure is to mount components and provide the electrical connection between the components in our system, which in our case is the 3DOT board. As part of the subsystem requirements provided: L1-9 Custom PCB-3rd Generation Velociraptor (Th) Project Schedule shall use an external PCB with an I2C Interface (JP5) as the 3DoT Board.
Process:
Figure 1: The schematic provided by the E&C that needs to be designed into a PCB.
To design the PCB I used the software Eagle CAD program. I was first given a schematic by our electronics and controls engineer to make into a PCB layout for our project. I imported the schematic and switched it to a board.
Figure 2: The Screenshot of the connections between the PCB and the 3DOT board after being imported into Eagle CAD
For our project, our PCB had to be designed like a shield for the 3DOT board because of the location we were placing it in. We made the decision to place it right over the square area for the body. As a result of this feature, I needed to make sure that I had made the size and the connections from the 3DOT to the PCB as accurately as possible. Therefore to ensure this accuracy, I imported the 3DOT board from 3DOT library. I then overlapped the 3DOT and the PCB, got the size and connections, and then cut out the power supply part from the PCB because we will not be using it.
After getting the size and connection where they needed to be, I placed the rest of the other components according to the schematic. I tried to make all the components that were connected to each other close to one another. After the placement of the components or ICs, I began to wire. When wiring I made sure to follow the requirements made by the customer.
Figure 3: Screenshot of what the wiring process looks like.
After wiring up everything I ran a couple of design analysis checks to make sure everything required of me and the PCB was met. Then I put some more finishing touches such as copper, the inscription of our project name and class, etc. Since everything was cleared, I got my board approved and then ordered it. Always ensure to order the PCB at least three weeks before the week of the final assembly, especially if ordered by OSH Park, it does take a while to make and get shipped. Also, you would have to solder the board after, so make sure to order the components/parts on the schematic.
Conclusion:
Figure 4: Screenshot of what the final product looks like with the copper and the etching.
All in all, the PCB layout wasn’t hard in its design but time consuming in its conception. Ensuring that I had the right parts in the right location was crucial to the overall success of completion of the PCB. Once it was been determined the reason and overall concept for the PCB design, it was easy and quite fun to do. Thank you and Good luck!
By: Victoria Osaji, Manufacturing and Development Engineer
Introduction:
After a lot of trial and error and prototyping, we have the basis for our mechanical design. Listed below we explain how we achieved each part.
Level 2 Subsystem below:
3. 3rd Generation Velociraptor (Th) should resemble a Velociraptor of the Theropodous Dinosaur Suborder that is scaled down to below the height of the columns in the game.
8. 3rd Generation Velociraptor (Th) shall use a single servo to control the head and tail.
Figure 1: These are different views of our robot without the head and tail.
Body:
The body of the robot was designed with a couple of things in mind. We knew we wanted all the components such as the 3DOT board, PCB, the 2 servos and the 2 GM9 motors to be able to fit within the body so we made the robot approximately about 100mmx52mmx48mm. The thickness was based on the wood we used which was Balsa and it was .3175mm thick.
Figure 2: This is a top view of our chassis. The biggest hole is the hole for where the servo is located.
On the top chassis, we designed a hole about 13mm for one of the servos that is going to be connected to the gear train that will move the head and tail [L2-8]. We made that hole because we wanted all of our gears to be flush on the body and we were able to achieve that with the hole of the top.
Figure 3: This is a side view of our robot. The biggest hole is the hole for the GM9 motor the other three holes at the top in a row are for the gears.
On the side chassis, we have different holes for the gear train 3mm that will be controlling the legs and the hole for the motor couplers that connect to the GM9 motors were 7mm.
Figure 4: This is the cover that went over the head and tail to keep the gears flush on the top.
On top of the top chassis we have a piece that was created to hold the gears in place and this piece consist of ten 3mm holes. The body was designed to be pressure fit to avoid using adhesive hence why there are cut of rectangles on certain pieces and extruded rectangles on others so they can mate into each other.
Gear Train:
Figure 5: This is gear train for the legs on Solidworks.
The big gears have 16 teethes and the small ones have 10 teethes. Two big gears and 2 small gears will be used to make a gear train for our mechanical systems. The big gears have 3mm holes in them so they can be connected to the legs. Calculations had to be done to determine the gear ratios. (Click here hyperlink to blog post)
Motor couplers:
Figure 6: These are the small gears also known as the motor couplers for the GM9s and the rotary sensors.
The motor couplers were made to be connectors from the GM9 motors to the rotary sensors to the legs. They were made in form of gears because we need the motor to drive the gear train for the legs to move. On one side of the motor coupler we have an extruded cut piece 6mmx5mmx3mm to fix the GM9 motor and on the other side we have an extruding shaft for the rotary sensor. It was a circle with a diameter of .125mm cut in a shape of a “D”. This motor coupler goes into the small hole of the side chassis.
Legs:
Figure 7: This is the final design for the legs.
The final design for our legs was two links connected in a “T” shape with a square platform as the foot. The links are about 15mmx 54mm with 3mm holes. The holes on the legs are connected to the smaller holes on the big gears. The project manager, Paul actually came up with this design because it would be easy to control on the electrical side. We had about 3 other leg designs before we came to this one. Click here to see the leg journey.
Head and tail:
Figure 8: To the left is the piece that we used for the head and tail. To the right is the gear train for the head and tail.
The head and tail design was motivated by the requirement to use a single servo to drive the head and tail. The design was simply a gear with 9 teethes on one half and the other half of the circle or gear was elongated about 50 mm into a flat board (.00125mmx.00075mmx.00025mm) for our battery holders (like the picture to the left). Then in between the head and the tail were two small gears with 20 teethes each.
Materials:
Figure 9: These are the materials we ending up using, balsa wood and PLA Filament plastic.
At first we wanted to 3D print our whole robot but we when we prototyped our robot leg with laser cut wood we really liked the appearance of it. Then we processed to laser cut the body just to test it out and we really liked it. We liked how precise it was and the ability to pressure fit with it as oppose to 3D printing. We had a lot of issues 3D printing because I would design something and the 3D printer would print it but the part would shrink or wouldn’t fully print certain parts especially if they were small parts. With laser cutting I was able to design the part with exact dimensions because the laser cutter was very exact. We still 3D printed the gears and the motor couplers because those parts are 3D and the laser cutter only cuts in 2D.
All in all, these are the major things that helped our project come together. This design is simple and it work. T he thing I learned the most is rapid prototype early and have back-ups. Just because something works on solidworks doesn’t mean it is going to work in the physical world. It might be frustrating but when it all comes together trust me, it will all be worth it. Good luck!
By: Victoria Osaji, Manufacturing and Development Engineer
Table of Contents
Design Analysis:
Introduction:
This was one of the four tests we conducted to demonstrate the mechanical capabilities of our robot dinosaur. In this test we are looking to determine the radius our robot head can cover essentially measuring what areas our robot can see as it moves its head around. This way we know the limitations on the robot head so as not to damage any of the linkages or the internal components which are tied together
Process:
Parts needed:
Flat surface area
Protractor to measure out the radius angle
Ruler
In order to measure the coverage angle the steps and measures we took are show below:
1. Set your robot head to the middle of your robot and mark that distance
2. Move your robot head as far to the left as possible without moving the body. Mark that spot.
3. Move your robot head as far right as possible without moving the body. Mark that spot.
4. With a protractor measure the angle covered from the left to the right.
5. This is the range that your robot can visually cover.
We repeat this exercise a few more times to validate the range we are getting on the robot
Results:
What we noticed is our robot moved 160 degrees to the right when turned and in the reverse direction 20 degrees to the left when turned. On average the consistent rotational angle we saw was 140 degrees. We repeated the exercise and had several numbers in ranges of 138degrees all the way to 142 degrees (we had about 8 different tests conducted). Therefore our 140 degree was an average of the all the samples we attained.
Conclusion:
All in all, there are several important factors for why we want to know what our coverage angle. We do not want damage linkages or any parts of our robots by awkwardly turning it in directions it is not able to go. Therefore understanding what our limitations are with regards to knowing what our coverage angle is will help to protect our robot.
https://www.arxterra.com/wp-content/uploads/2016/12/angle.png200256Paul Ahumada/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngPaul Ahumada2016-12-17 07:34:102018-03-09 08:17:59Coverage Angle Test
By Victoria Osaji, Manufacturing and Development Engineer
Table of Contents
Introduction:
This was another one of the four tests we conducted to demonstrate the mechanical capabilities of our robot dinosaur. In this test we are looking to determine the load the robot can sustain without any significant damage or falling apart. This way we know the limitations on the robot support so as not to damage any of the linkages or the internal components which are tied together or put unnecessary strain on the legs.
Process:
Figure 1: One of the load tests conducted on our robot.
Parts needed:
A bowl to hold the load
A system of weighted measure (in our case we used cups of rice)
A scale to measure the weights
A flat surface to balance your robot
Figure 2: Another one of the tests conducted. Using a heavier weighted sample
In order to determine what the load capacity of our robot was, the steps we took were:
1. Get pieces of wood with varying weights. (Always better to use a flat piece of wood but you can also use a flat piece of metal or any weighted substance – we used a bowl of rice)
2. Weigh the piece first and then place on top of robot.
3. Ensure that your robot maintains its balance and doesn’t tip over.
4. If it doesn’t lose the support, move on to another piece of wood. One that is preferably heavier than the last one used.
5. Continue this until your robot shows fatigue or an inability to maintain support.
Results:
Our tests results showed the following:
Weight 1
200g
Weight 2
383g
Weight 3
570g
Weight 4
761g
Weight 5
950g
Weight 6
1.25kg
Weight 7
1.54kg
Weight 8
1.745kg
At about weight 8 we started to see a significant dip in the legs of our robot where it started to diminish. This is where we noticed our first major pressure point. As a result of not wanting to have to put our entire robot all over again from scratch we decided that this would be the load capacity for our robot.
Conclusion:
The load capacity is extremely important to the overall weight and support of the entire robot. It is important to note the limitations on what your robot is capable of and what your robot is able to lift and support that way we don’t compromise the entire structure of the robot.
https://www.arxterra.com/wp-content/uploads/2016/12/load1Feat.jpg200200Paul Ahumada/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngPaul Ahumada2016-12-17 07:29:322018-03-09 08:18:00Load Capacity Test
By: Victoria Osaji, Manufacturing and Development Engineer
Introduction:
The foot of the raptor is probably the most important piece to the animal. This determines the most support for the center of mass and gravity for the raptor. Based on this ideology, we thought about three different types of design for the foot of our raptor.
Level 1 System below:
S1. The 3rd generation velociraptor shall statically walk on a flat surface of linoleum
S2. The 3rd generation velociraptor shall statically walk on a flat surface of cardboard.
S3. The 3rd generation velociraptor shall statically walk on an incline and decline surface of 6.5 degree maximum
S4. The 3rd generation velociraptor shall perform static walking while on a step of .5cm.
D1. The 3rd generation velociraptor should statically walk on a flat surface of linoleum
D2. The 3rd generation velociraptor should statically walk on a flat surface of cardboard.
D3. The 3rd generation velociraptor should statically walk on an incline and decline surface of 6.5 degree maximum
D4. The 3rd generation velociraptor should perform static walking while on a step of .5cm.
For one design we thought of a splined/sloped design. We decided that a curvature at the bottom of the feet may allow the best stability for our raptor. We tried to simulate the feet of humans in this scenario. Most human feet are actually not flat and are more or less splined or curvy and we figured we would duplicate this idea in creating our raptor. The advantages to this idea were minimal at best, while it was the most similar to humans it didn’t offer as much support or foundation for the center of mass for our raptor and when looking at it mechanically it actually would not be easiest design to translate mechanically.
For another design, we thought of a flat surface as the base of the foot of the raptor. In order to support the weight of the raptor we decided that we would need a square base foundation that would support that weight. Also we felt that we would be able to ensure that our raptor would be able to balance better in case of a battle with another dinosaur. However we notice that there would be discrepancies with this design. In the event of a battle, as much a flat base may not provide the best balance, while it would provide some balance it may not be the best. Also when it comes to navigation, a flat surface base as the foot may not provide the best grip for unlevelled surfaces, this may cause the raptor to tilt and fall in areas as such. So then we thought why not a flat surface with spiked feet. This would still give us the strong square- base foundation to which our raptor would be supported which is based off the weight of our raptor as well as the benefits of having spiked feet. With the spiked feet, we would allow the dinosaur to have enough grips as it navigates through different locations. It would also allow for the raptor to use as a weapon in case of a battle. Ideally, this would make the most sense and would satisfy all the components we are looking for our raptor to have.
The previous semester, spring 2016, did a very detailed material trade-off study that we liked based on Aluminum and PLA Filament (3D printing material). We found this very useful because we have ideas that we can now build off of.
Although, our design may differ in some places and our requirements have changed a bit these are still information we can use because the basics requirements are covered such as walking statically and dynamically and being able to walk up and down uneven surfaces. What I really liked most is that they used the two different materials depending on their needs. They used the aluminum for their bottom piece because they wanted to maximize the weight on the head and tail. Then they used the PLA filament for the foot that way the robot could walk statically and dynamically without slipping on different surfaces.
Table 1. Materials Cost
