By: Paul Ahumada, Project Manager

Members:

Kevin Armentrout, Electronics and Control Engineer

Victoria Osaji, Manufacturing and Development Engineer

Project Overview

Mission Profile

3^rd 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(…)’.

Electronics Design

Servo Design

Motor Design

IMU Design

IMU Implementation

Schematics

Firmware: E&C

Debugging Wire Library

3DoT and IMU

PCB Schematic E&C

Schematic

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.

PCB Layout: MFG

Hardware Design: MFG

Mech-design

Verification & Validation Test Plans

validation_verification_testplans_r1

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.

vv_velociraptor_thursday-1

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.

Schedule-documents

Conclusion

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

CDR Document

PDR Document

BOM

Video

 

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.

(Link to material trade off study blog post)

Conclusion:

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

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.

 

By: Victoria Osaji, Manufacturing and Development

Introduction:

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.

References:

By: Victoria Osaji, Manufacturing and Development Engineer

Introduction:

The mechanical system we implemented was the gear train and it was designed to move the legs, head and tail. For the legs, the small gears have 10 teethes and big gears have 16 teethes. One of the small gears is actually a motor coupler as well that connects to the GM9 motor that will then drive the other gears to move.

Level 2 Subsystem below:

8. 3rd Generation Velociraptor (Th) shall control the head and tail movement with a single servo using gear trains.

11. 3rd Generation Velociraptor (Th) should control the body platform movement with a single servo using gear trains.

Motor Calculations:

To conclude, we will use 56 RPM at 3.7 Volts to drive the small gears to big gears. Since we have 35 RPM, (35RPM/60sec) =0.583 cycle per second for the big gears.

References:

http://www.engr.ncsu.edu/mes/media/pdf/gears