Fall 2016 Velociraptor (W): Final Project Document

By Lam Nguyen (Project Manager)



Table of Contents

Executive Summary of Project



Project Objectives

For CSULB Fall 2016 semester, the Velociraptor biped robot project will branch off to a new species of dinosaurs and set up a new baseline with the Theo Jansen robot design. The Velociraptor is to be a toy robot resembling a Theropodous dinosuar suborder by it’s static walking movement. The objective of this project focuses on utilizing a Theo Jansen design to produce a walking robot that will be remotely controlled through Bluetooth communication by using the Arxterra Control Panel. The robot’s application will have a 3DoT MCU board and demonstrate it’s feasibility by participating in a game with other robots.

Mission Profile

The Mission Profile of the Fall 16 Velociraptor is to participate in the game arena called Save the Robot on the last day of school, December 14th 2016 at 9:00 am. The game will involve Velociraptor chasing other toy robots through various terrains tele-robotically from the Arxterra control panel. The robot’s application of the 3DoT board MCU will demonstrate it’s walking capabilities by navigating through terrains in a game.



Project Features



DC motors

Apart from previous semester the Velociraptor’s project design had problems with servos that actuates a walking motion. DC motors were introduced to have a continuous rotation for our walking motion.

3D Model – Theo Jansen Biped Robot Model

In order to design the robot with the Theo Jansen model as the project baseline. The project used Solidworks 3D modeling to validate and verify new designs within a short period of time. Using unique applications from Solidworks the mass properties helped save time and money on both printing the parts.

1

Picture 1. Theo Jansen BiPed Robot Model

Rotary Sensor and A/D Converter

With the new actuators for the walking motion. DC motors has less precision for every full rotation, therefore by using rotary sensors and A/D converter we will be able to track each leg’s position for a stepping motion.
6

Picture 2. Rotary Sensor

8

Picture 3. A/D Converter

Experiment List/CheckList

For the Final Verification and Validation Test Plan the project was given a checklist that stated the project’s requirements and experiments to figure out the results.

velociraptor-experiment-listchecklist



System Design



System Block Diagram

2

Figure 4: System block diagram Velociraptor (W)

The system block diagram for the velociraptor group was designed in order to use an external PCB that would be able to interact with the 3dot board embedded system. The system block diagram displays the overall connections that are needed to make the controls of the velociraptor possible. For the velociraptor PCB, it will have stepper motor drivers (A3901) which will have 2 stepper motors which control the linear actuators. With the help of the actuators we will be able to change the pattern of the step. For instance if the velociraptor needs to go up an incline, it would be able to step higher and not hit its foot against the bottom of the incline. In order to have the stepper motor driver be compatible with the I2C interface, we will utilize a GPIO expander that is I2C compatible. The driver will control the linear actuators. The linear actuators will change the radius of the rotational movement which will change the motion of the leg movement. For more information on each block of the diagram, readers are advised to visit the blog post link cited below.

 



Subsystem Design



Interface Definitions

3

Figure 5. Interface Definition

The above figure is for the interface definition which is linked  to the cabling tree diagram. Both of the above figures are linked in the sense that the interface definition is an outlined pin layout from the EagleCAD schematic while the cabling tree demonstrates what the layout will look like. The EagleCAD schematic was designed by the electronics engineer and through that the manufacturing engineer is able to know how to design the PCB and have the right connections.

4

Figure 6. Cable Tree

In the cable tree diagram, there is more details regarding the connection types; the wire lengths and also the gauge sizes. The cable tree diagram that has been provided below is based on the system block diagram and follows the same format and layout.



Mission Command and Control



The command and control of the velociraptor was to be designed in such a way that both the systems and electronics engineer have a good understanding of the 3DoT library provided by Professor Hill. The library needed to be modified in order to be able to include the custom command for each senior design group. For procedures on how to create custom commands and how to create a custom telemetry commands on the Arxtera control panel, readers should visit the systems blog post on how to create custom commands as well as telemetry commands. For the telemetry we will be displaying the roll, pitch and the left right rotary sensor values. A rotary encoder will be able to tell us how much in each direction the encoder has been turned. The custom command is when we have information that is being sent to the robot from the user. The custom command that we created for static walking for instance; it lets the velociraptor know when to start walking. However, telemetry would be the robot sending back information to the user what the leg placement is. There are two separate blog posts on custom commands and telemetry commands. Both of these blogs can be reviewed in order to gain a better understanding of the commands.



Electronic Design

Rotary Sensor

The rotary encoder is necessary to know the position of the dc motors. Without them, the walking motion would be a disaster. They are potentiometers. The signal is converted to a digital, and it is read via I2C.

Control Algorithm Code

The C++ code is a control algorithm for the velociraptor. It moves the servo which moves the head and tail to control the center of mass. It uses DC motors and rotary encoders to control the legs properly. Overall, it controls its walking motion and its turning.



Firmware

Software Block Diagram

The software block diagram shows a detailed description of what coding blocks information were needed to implement the move commands for the velociraptor. For instance, dynamic walking was a walking style in which the customer would have liked to accomplish but unfortunately wasn’t successful. For the static walking motor commands, the velociraptor was programmed to be able move forward, move backwards, turn right and turn left. The turn commands go into details about describing how a turn occurs after the foot has been planted in a stable position while the other foot is continuously being moved until the robot is able to turn in the specified direction. Identifying the necessary components and flow chart diagrams of what the velociraptor motor commands were supposed to do, made the coding a little bit easier when it was time to implement it in Arduino.

Sample of Code:

Link: telemetry-and-custom-command-sample-arduino-code-1



PCB Schematic

Fritzing Diagram/EagleCAD Schematic

The Fritzing diagram and Eagle schematic lays out how the components connect together on the PCB. Fritzing gives you a more visual representation while Eagle shows all the details of the connections. Once the Eagle schematic is complete, the manufacturing engineer fabricates the board so that it can be coded.



PCB Layout

The PCB layout was carried out through EagleCAD. The design utilized thru-hole components and L-shaped form to integrate with the 3DotBoard.  Majority of the IC components were placed on the top layer to utilize a SMT solder paste stencil for reflow soldering. Only one IC component was placed on the bottom layer, which will be soldered through hand soldering. The picture below shows the PCB layout for the custom PCB of the Velociraptor. Decoupling capacitors were placed close to the IC components and wire sizes were adjusted to prevent problems with the power and signal lines. For PCB fabrication, OSH Park was chosen.
For more information, the blog post below will give detailed information regarding the PCB layout.



Hardware Design

To fulfill requirements, a modified version of the Theo Jansen linkage was integrated with the leg design. The continuous rotation of the linkage corresponded with the continuous motion of a DC motor. The design was created in SolidWorks to observe features such as center of mass. The center of mass was accurately calculated from a custom library of densities in SolidWorks. Subsystem components, such as the toe joint and see-saw body, were to fulfill requirements and improve the design from previous generations of the Velociraptor.

 

For more information, the blogpost below will give thorough information regarding the hardware design.


 

 


Verification and Validation Test

The verification and validation matrix is a complied version of the requirements that the velociraptor group was required meet. In this matrix below, we notice that the requirements have been labeled as either a shall, should or will. For this Wednesday velociraptor group, we were able to accomplish about half of the will requirements that were expected from us. In the figure below, readers can find a copy of the verification and validation report. Matrix has been provided below in order to give viewers a better understanding of project requirements.



Project Status



Power Allocation

For the power allocation report, the velociraptor robot consumes a total of 375mA when in complete motion. Based on a torque test performed by the electronics engineer in our group, we were able to determine that the DC motors can move a mass that is at a 1000g maximum. Due to robot size being 348g, we know that the motors will be able to successfully control the robot without stalling.

Mass Allocation

The overall weight of the velociraptor is 348g which is only using 34.8% of our maximum requirement of having it not weigh more than 350g. This therefore fulfills our requirement of the total mass and also makes it possible to have the GM9 motors supply enough torque to move the velociraptor. The final mass report which is provided in the figure will be able to provide more information about the overall weight distribution of other components.

Cost Report

The cost budget was finalized by the customer to allocate the cost to each project. In the end the customer was the deciding factor for the Velociraptor (W)  budget. In the cost report the items were provided by the customer were $0.00 and this help the project lower the budget to $46.55.



Product Breakdown Structurea

Figure 7. Product Breakdown Structure

The product breakdown structure above was categorized into 5 sections:

  1. Movement System
  2. Control
  3. Software Control
  4. Power
  5. 3DoTBoard/PCB Board

The PBS was worked with Paul Auhmada from the Velociraptor (Th) class. The movement system pointed to the mechanical design, servos, and dc motors. The Controls had attributes for sensors. The Software Control had communication and control algorithm code applications. The 3DoTBoard/PCB board was for the external PCB board unique to each projects design.



Work BreakDown Structure

aa

Figure 8. Work Breakdown Structure

The Work Breakdown Structure allocated the task to different divisions of the team. This semester this project the system engineer and the electronics and controls engineer had a huge learning curve therefore there were difficulties to push the project forward in a short period of time. Therefore the system engineer role were covered by both PM’s of each Velociraptor. The electrical and controls engineer role was assisted by their division manager.



Project Schedule

The project schedule indicates the number of tasks needed to follow in order to complete the project. Unfortunately the project reached some obstacles in the electronics and mechanical design.aaaa

Figure 9: Project Schedule

The burndown structure shows two different graphs where the orange line indicates the tasks remaining to complete the project and the blue line indicates the expected tasks completed. As you can see the path diverged early in the semester, where our systems engineer had reached some obstacles in the task. This problem ended up affecting the rest of the divisions due to time.

The project is marked as 80% complete and needed to implement the feet design of our robot and the control algorithm with the rotary sensor.

aaa

Figure 10: Burndown Structure



Conclusion

The Velociraptor this semester had face many problems to move the project foward. The Theo Jansen Linkages designs was set but when the group assembled our first prototype we noticed that the feet design was one of the issues in having the robot balanced when stationary. There was problems with every division and the delays caused other work to be pushed back. The control algorithm used to move the robot forward and turn was not completed by the final project demonstration. The foot design was one of the biggest problem that needed to be implemented to have the robot balanced when the robot walks.

Future Projects:

  1. The manufacturing engineering should start on the mechanical design as soon as possible if not then the manufacturer will face bigger problems towards the end.
  2. The electronics and controls engineer should learn C++ from the start to be prepared for coding tasks.
  3. The system engineer should not only focus on the requirements but also be ready to think about all factors. Know that the system design is the baseline of the project, therefore if something is changed from the system’s side then there is a possibility this could affect other divisions.



Project Resources

[1] Project Video: https://www.youtube.com/watch?v=1fSIvmpCkRk

[2] Critical Design Review: critical-design-review

[3] Preliminary Design Review: preliminary-design-review and preliminary-design-review PowerPoint

[4] Microsoft Project : projecct-schedule-1

[5] Verification and Validation document: verification-and-validation-test-plan-results

[6] Solidworks File: https://www.dropbox.com/s/9mycah24zwdqag8/Velociraptor.zip?dl=0

[7] Fritzing Files: fritzing-diagram

[8] EagleCAD Files: eaglecad

[9] Control Algorithm Code: control-algorithm

[10] MatLab Code for Torque studies: matlab-code

[11] Complete Bill of Materials (BOM): bill-of-material

 

Fall 2016 Velociraptor (W): Analog to Digital Converter

By: Taylor Farr (Electronics and Control)

Approved by Lam Nguyen (Project Manager)

Table of Contents

Introduction

I chose to use the Adafruit ADS 1015 analog to digital converter. This will be used to convert the analog signals from the rotary converter to digital ones. This ADC communicates via I2C, so this satisfies our level 2 requirement.

Materials

  • 3382 Series 12mm Rotary Position Sensor
  • Adafruit ADS1015
  • Screwdriver
  • Breadboard
  • Wires
  • USB Cable
  • Laptop
  • Test Code
  • Arduino
  • protractor

Procedures

  1. Connect the ADC to the breadboard.
  2. Connect Vcc to the 3.3 volt pin on the Arduino and breadboard.
  3. Connect ground to one of the ground pins on the Arduino.
  4. Connect SCL and SDA to the SCL and SDA pins on the Arduino.
  5. Connect the Vcc of the rotary encoder to the Vcc on the breadboard.
  6. Connect ground of the rotary encoder to ground on the breadboard.
  7. Connect the signal output of the rotary encoder to the A0 pin on the ADC.
  8. Upload test code to Arduino and open the serial monitor.
  9. Using the screwdriver and protractor, move the position of the ADC to different angles and observe the digital readings on the screen.

Results

Angle (degrees) Bit reading
0 1
45 115
90 222
180 550
225 667
270 827
350 1101

Conclusion

From The table of results, we can see the digitized results of the rotary encoder. The ADC is a 12 bit analog to digital converter. The voltage on our PCB is about 3.3 volts. This is why we do not read the full span of the 11 bits (211 = 2048). Now that we know the range as well as the specific values of the encoder at specific angles, we can use this to update the control algorithm for the velociraptor.

Fall 2016 Velociraptor (W): Interface Matrix Update

By Gifty Sackey (Mission, Systems, Systems Engineer)

Approved by:

– Lam Nguyen (Project Manager)

– James Lee (Division Manager for Mission, Systems, and Test


Table of Contents

Introduction


In this current block post, the interface matrix along with the eagle card documents have been provided and discussed in order to allow future 400D students to have a smooth transition when building upon the robot. The interface matrix excel document was designed based off the EAGLE CAD design which was designed by my groups electronics engineer. The EAGLE CAD allows us to have an idea of what our PCB will look like before actually printing it. With the help of this computer software, tracing the design is not tedious because we are able to see the components that are used and their respective wire connections. For the diagram below, the components are placed in columns and have their connections to the 3DoT board listed in each row section by the pin name. For instance with our GPIO expander, we notice that the SCL is connected through the IC1-12 pin while the SCA pin is connected at the IC1-13 to the GPIO expander.


Matrix Interface Link


Matrix Interface Link: interface-definition


Cable Tree Diagram


Along with the interface matrix, each project group is required to design a cable tree diagram which is another visual presentation of the system block diagram but with more details regarding the connection types; the wire lengths and also the gauge sizes. The cable tree diagram that has been provided below is based on the system block diagram and follows the same format and layout. This diagram was made possible through draw.io which served as the tool to design our diagram.

4

Diagram 1: Cable Tree


Conclusion


These diagrams that have posted above in this current blog post are the cabling diagram and interface diagrams. Both of these documents from above were previously presented during our presentation for the critical design review. Subsequently they have been revised to ensure that the velociraptor group produces excellent documentation materials.


Resources


[1] https://drive.google.com/file/d/0BzIcuzRpcmk4S252NEc5Sld5MU0/view

Fall 2016 Velociraptor (W): Software Block Diagram

By Gifty Sackey (Mission, Systems, and Test)

Approved by:

– Lam Nguyen (Project Manager)

– James Lee (Division Manager for Mission, System, and Test)

Table of Contents

Introduction

The purpose of this blog post is to discuss and summarize the control functions that will be required in the programming of the robot. It will cover the software block diagram and introduce the set of tasks that the software had to accomplish. For the mission profile for the Velociraptor shall participate in the Game Arena and statically walk. The software flow chart that is attached, allows users to see how the Arxterra firmware will be modified and the programmed through the 3DoT board.

Software Block Diagram – (Old)

software-block-diagram-old

Diagram 1. Software Block Diagram

Software Block Diagram – (Updated)

software-block

Diagram 2. Software Block Diagram Updated

In the event that a command is sent via Bluetooth from the ArxRobot App, the command decoder and handler functions will be executed on the action. The software block diagram, allows readers to gain an insight on the inputs that the robot functions will be taking as well as the outputs. For this blog post, I will be explaining in detail how the velociraptor will perform when the right motor is the only thing allowed to move. When the velociraptor is being moved and controlled by a single motor, the velociraptor is making a turn. In the case of the right motor moving, this indicates that the velociraptor is turning left. A turning left subroutine code would then be initiated as well as servo commands. In order for the velociraptor to be able to make a complete turn, it would have to shift its center of gravity over the left leg by moving the servo 30 degrees from the neutral position so that the it is balanced over that specified foot.

For the velociraptor to achieve static walking, the control codes will be designed such that both motors will be moving out of sync. While both motors are moving out of sync, as engineers, we need to make sure that the revolutions per minute (rpm) should have different values for both motors while having both legs be 180 degrees apart. The servo would then be moved over the left leg but then both motors would be required to move 180 degrees at the same rpm value and then stop in order to complete a step. At this point, the velociraptor needs to maintain balance so it needs to shift the servos at a 60 degree angle in order to ensure the center of gravity is on the right leg. At this point, the robot must move both motors 180 degrees forward to complete a step. The robot would then repeat this process until a different command is called from the Arxterra application.

Fall 2016 Velociraptor (W): Validation and Verification Test Plan

By:

– Lam Nguyen (Project Manager – Velociraptor Wednesday)

– Paul Ahumada (Project Manager – Velociraptor Thursday)

– Gifty Sackey (Mission, System, and Test Engineer)


Introduction


The final validation and verification test plan was written to verify the requirements for the Velociraptor through the Validation and Verification Matrix.

Link: verification-and-validation-matrix

Verification & Validation Test Plan

Below are the validation and verification test plan that supports our level 1 and 2 requirements.

Link: verification-and-validation-test-plan-results

Fall 2016 Velociraptor (W): Center of Mass

By Aaron Choi (Manufacturing Engineer)

Approved by

-Lam Nguyen (Project Manager)

-Tim Haddadian (Division Manager for Manufacturing)

Table of Contents

Requirements

Level 2-10 The center of gravity on the axis of the head and tail shall be controlled by one servo while being placed over the foot

Introduction

The center of mass is crucial for the design of the Velociraptor. To fulfill the Level 2-10 requirement, the center of mass should be placed over the foot. To observe the center of mass, the SolidWorks model of the design is required.

Library of Density

To observe an accurate center of mass, the mass of each observed through SolidWorks. There is no direct way to edit an object’s center of mass. However, a material can change its mass through density. Figure [1] below shows the example of a custom density for a material. The mass was either given from datasheets or weighed through a weight scale. The GM9 [1] and SG90 [2] mass were given through their respective datasheet. The volume of each Solidworks file were observed through the Measure tool in Solidworks. Then the density was calculated with mass divided by volume. Then the units were converted to match kg/m^3. Certain materials contained their density, such as Birchwood [3].

figure-1

Figure [1]

Density of the 7.4 Li-Po battery.

table-1

 

Table[1]

The table shows the density used for each custom material in Solidworks.

Center of Mass of Velociraptor

From the custom library of densities, the accurate center of mass was found. Then moving the head and tail through Solidworks, the head and tail were shifted at an angle. The angle found was 35 degrees.

figure-2
Figure [2]

The black and white dote represents the center of mass.

Conclusion

In conclusion, the center of mass was observed over the foot at 35 degrees. This was calculated by subtracting 65 degrees, found through Solidworks, to 90 degrees. This meets the Level 2-10 requirement.

 

Reference

[1]  https://solarbotics.com/product/gm9/

 

[2]  http://www.micropik.com/PDF/SG90Servo.pdf

 

[3] http://www.engineeringtoolbox.com/wood-density-d_40.html

 

 

Fall 2016 Velociraptor (W): Control Algorithm Code #2

By: Taylor Farr (Electronics and Controls)

Approved by:

– Lam Nguyen (Project Manager)

– Ryan Daly (Division Manager for Electronics and Control)


Table of Contents

Summary


The code for CDR utilizes IR sensors as rotary encoders. This was an okay method because it allowed for us to move the DC motors exactly 180 degrees. This is method could be improved with rotary encoders. We chose to use rotary potentiometers that can move a full rotation. Our PCB is powered by 3.3 volts, which means that the potentiometer value will vary between 0 and 3.3 volts. This is an analog signal, and our PCB only communicates via I2C.

[Link to A/D converter test]

We used the Adafruit ADS1015 to accomplish this. The test plan revealed that a span of 0-3.3 volts equates to a span of 0-1100 bits. This test proved flaws which improved the previous code, and allows for more precision in controlling the DC motors. This way, turning right and left will be more accurate. The option to move the motors at an angle of 90 degrees will keep the motors in place while the other leg moves continuously.


Code Description


The intent of the code is simple. Both legs will start off 180 degrees out of phase with the left leg forward and right leg in the back. The servo will move the head and tail to the left. The motors will both move 180 degrees to complete a step then stop. The head and tail will shift over the right leg. The motors will move 180 degrees again, then stop. The head and tail will shift to the left again. This completes the move forward subroutine.

Since the old encoders only move 180 degrees, turning would be impossible. The reason is that the legs cannot be moved to a position where all the center of mass can be placed on one leg without falling over. With the precision of the rotary encoder sensor, I can move the leg so that it is standing straight up. Once this movement is accomplished, the other leg will run continuously to turn. A similar process is used for turning the opposite direction.


Conclusion


Utilizing the rotary encoders and the I2C A/D converter allows for motors to be easily controlled. We can now position them with greater accuracy than the optical encoders. Figures 1 and 2 show the code used with comments.

23

Figure 1: First part of the control algorithm

24

Figure 2: Second part of the control algorithm


Resources


Fall 2016 Velociraptor (W): Hardware Design

 

By Aaron Choi (Manufacturing Engineer)

Approved by

-Lam Nguyen (Project Manager)

-Tim Haddadian (Division Manager for Manufacturing )


Table of Contents

Requirements

Level 1-2 requirement states that the Velociraptor budget shall not cost more than $102.

Level 2-1 The center of gravity on axis of legs shall be controlled by one servo. The head and tail shall not exceed [data to be calculated] degrees in order to avoid the robot from tipping over.

Level 2-3 The Velociraptor shall have two legs mechanism [Theo Jansen or UCI] in standing position to support the mass of robot with 50% margin.

Level 2-4 The Velociraptor should control the center of gravity on the axis of the H/T should be controlled by one servo.

Level 2-7 The Velociraptor shall have a foot design that uses [springs or struts] to maintain foot angle at minimum 6.5 degrees when not in contact with ground.


Introduction

For the Wednesday Velociraptor, the  Theo Jansen leg mechanism shall be implemented to meet the Level 2-3 requirement.  For the materials utilized, Birchwood is chosen to fulfill the Level 1-2 requirement and based off trade-off studies- [1].

Design

For the design, a simple CAD program called Linkage was used to model the walking path of the design. The CAD program, created by David Rector, allows users to design two dimensional mechanisms and simulate the movement of those mechanisms [2]. From this CAD program, the Jensen leg mechanism were used to model and observe the walking path. Linkage allowed users to adjust the lengths of each linkage. From experimenting the lengths, the finalized leg design for the Velociraptor was chosen. This design was chosen to increase the vertical height of the legs while maintaining the walking motion.

figure-1

Figure [1]

The figure above shows the Theo Jensen leg mechanism.

figure-2

Figure [2]

The figure above shows the design used for the Wednesday Velociraptor.

 

PDR Demonstration

Figure [3] shows the design that was presented for the Preliminary Design Review demonstration. This design did not contain a head and tail, however the Theo Jansen leg mechanism was implemented.

figure-3

Figure [3]

The design presented for PDR.

 

Some issues occurred during demonstration. The DC motors used did not provide enough torque for the Velociraptor to walk. The shaft of the DC motor constantly slipped in the shaft of the rotation piece of the Velociraptor. The linkages were not stable enough. To fix the unstable linkages, another linkage parallel will be added.

 

CDR Demonstration

Figure [4] shows the design that was presented during the Critical Design Review presentation. The outer shell, foot design with toe joint, and head and tail were included into this design. The DC motors used were the GM9, which were chosen from trade-off studies from Taylor Farr. The HS-322HD servo was used to control the head and tail. The servo installed was to fulfill the Level 2-1 requirement. An outer shell was implemented for a see-saw design for the Velociraptor to shift the mass forward when walking on incline. This would balance the robot when walking on incline surfaces. To control the platform, a servo will be implemented which meets the Level 2-3 requirement. The passive toe joint was used based off research [3] and to meet the Level 2-7 requirement. The ankle of the foot was positioned at the tip of the triangle for the leg. This helped match the walking motion of the Velociraptor. The additional linkages were able to stabilize the links unlike the PDR model. This improved the balance of the robot with stable legs.

figure-4

Figure [4]

The body design presented for CDR.

figure-5

Figure [5]

The leg and foot design presented for CDR

The model failed to walk without falling backward or forward. The head and tail were unable to move due coding. A solution given by Professor Hill was to move the GM9 motors on the outside. This was to ensure that the center of mass would be directly over the foot for the Velociraptor.

CDR Demonstration 2.0

Figure [6] shows the design that was presented for the Post CDR demonstration The GM9 motors were moved to the outside to shift the center of mass easier. The feet length of the robot were also increased to increase the surface area of contact. An issue with the previous design was that as the robot walks, the ankle at which it walks did not match the walking motion of the robot. Rather than using the HS-322HD servo, the SG90 servo was installed.

figure-6

Figure [6]

The body design presented for Post CDR demonstration.

 

When presenting the design, the robot could not walk forward without balancing by itself. One addition that would be able to solve this issue is add traction material to the bottom of the foot. The spring of the toe joint was unable to support the mass of the robot, causing the robot to fall when balancing. To resolve this, further experimenting with springs will be carried out.

 

Game Arena Design

Due to time constraints, Paul Ahumada’s physical model was implemented for the Game Arena and test plans. For this design, a body was used that could utilize both Ahumada’s design, and the Velociraptor leg design. Ahumada’s design revolved around using gear trains to rotate the leg.

figure-7

Figure [7]

The top robot is the Thursday Velociraptor. The bottom robot is the Wednesday Velociraptor.

 

Post Game Arena Design

Figure [8] below shows the design shown to the customer after the Game Arena and Validation plan was finished. The Jansen linkage installed onto the body of Ahumada’s design [4]. Although the Velociraptor could not statically walk without tipping over, the walking motion did show that the robot could move forward.

figure-8

Figure [8]

The design with the modified Theo Jansen linkage.

 

Conclusion

The hardware prototypes implemented subsystem designs which derived from the level 1 and level 2 requirements. The issues that were faced were due to center of mass. The Velociraptor could not balance well due to the center of mass. Additionally, the body would continuously sway. A possible solution would adding an additional linkage that attaches from the body to the rotation shaft of the motor that would help stabilize the robot.

 

References:

[1]http://arxterra.com/material-trade-off-study/

[2] http://blog.rectorsquid.com/linkage-mechanism-designer-and-simulator/

 

[3]http://ocean.kisti.re.kr/downfile/volume/icase/JOJDCV/2011/v17n7/JOJDCV_2011_v17n7_659.pdf

[4] http://arxterra.com/mechanical-design/

Fall 2016 Velociraptor (W): System Block Diagram

By: Gifty Sackey (Mission, System and Test Engineer)

Approved by:

– Lam Nguyen (Project Manager)

– James Lee (Division Manager for Mission, System and Test)


Table of Contents

Introduction


The system block diagram describes how all the signals connect to all the components and communicate with the 3DoT board. Aside from the 3DoT board, which was provided by Professor Hill, there is an external PCB which is designed by the electronics and controls engineer and fabricated by the manufacturing engineer. On the Velociraptor our shield will have a stepper motor drivers (A3901) for 2 stepper motors. These two devices are the linear actuators that will change the pattern of the step. For instance if the Velociraptor needs to go up an incline, it would be able to step higher and not hit its foot against the bottom of the incline. In order to have the stepper motor driver be compatible with the I2C interface, we will utilize a GPIO expander that is I2C compatible. The driver will control the linear actuators. The linear actuators will change the radius of the rotational movement which will change the motion of the leg movement.

Design 1

3dotboard

Diagram 1: First design for System Block Diagram

Design 2

In our final design of the System Block Diagram we had added a color scheme to the one below. Following from the external battery on the shield (external PCB layout) the colored lines indicates the voltage level before going stepping down in voltage for certain regions of the schematic. The orange lines indicate the 7.4V battery going through the LM7805 LDO. The blue line is connected to the 3DoT board which powers the 2 DC motors and the servos. The blue line also steps down again though the LDO on the 3Dot board dropping down to 3.3 V. This in part will power all of the sensors on the external PCB board.

2

Diagram 2: Finalized System Block Diagram

External Power Supply

The Velociraptor is required to participate in the end of semester game alongside with other robots. The Velociraptor will be designed to last a duration of the game which is 1 hour. Two external batteries will be used in addition to the battery power provided through the 3DoT board. The external battery of choice is the YPG 850mAh 7.4V 25C 2S Li-Po Battery which will be stepped down by the LM7805 LDO to 5V at 1.5 amps maximum. The output of the LDO is connected to the external battery connection on the 3DoT board.

Balance – IMU

Above the stepper motor connections are the legs of the Velociraptor (Figure 1). The orientation movement of the robot will be sensed by the IMU. The IMU is connected to the PCB via I2C interface and its purpose is to measure the angles and acceleration in x, y and z directions. By incorporating the IMU in our design, we are able to determine if the velociraptor is unbalanced. The control algorithm that will be implemented for the velociraptor will be a closed loop algorithm which is always checking against a calculated value that corresponds to the velociraptor’s balance.

Position Tracking – Rotary Sensor

The connections of the DC motors controlling the legs need to be connected to the rotary encoders. Since the rotary encoders are not I2C compatible, they require a connection to an A/D converter. In the case of the velociraptor, a 12-Bit ADC converter type of ADS1015 has been chosen.

Bluetooth Commands/Telemetry

The Arxterra Control Panel is made up of the controls that our software and firmware will be using to control the velociraptor. The velociraptor robot will be able to receive commands through two main modes, community mode(laptop) or remote control mode(phone). 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 control the robot. The 3Dot board is embedded with an HM-10 Bluetooth module which aids the communication of the software to the robot. A software block diagram for the velociraptor can be viewed to gain a better understanding of the software controls for the velociraptor. This Bluetooth module is compatible with either an Android or Apple iPhone. Users are required to have a membership account with the Arxterra company in order to achieve this communication platform necessary to have the robot receive commands. For the velociraptor group, the goal is to modify the existing move command code in the 3DoT library and in turn have the velociraptor be able to turn left, turn right, walk up and down inclines and lastly statically walk.

Embedded in the 3DoT board is a TB6612FNG motor driver which will be needed to drive two GM9 motors that will be used to control the legs. Each motor will be attached to each leg mechanism of the robot. The motor driver’s purpose is to receive low current control signals from the 3DoT board and output a higher current signals. These signals can drive the motors that move the legs.

Conclusion

In the end the first thing we needed to consider was how much torque we needed to move our robot. Once we had the mass figured out we could determine the amount of current needed to power the robot. After that we account for all of the actuators, sensors, and other electronic devices so that our robot is fully functional. If our design changes then

Resources

[1] http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/04%20Robot%20Block%20Diagram.pdf

Fall 2016 Velociraptor (W): Custom Telemetry Commands

telemetry-pic3 By: Gifty Sackey (Mission, System, and Test Engineer)

Approved by:

– Lam Nguyen (Project Manager)

– James Lee (Division Manager for Mission, System, and Test)

Table of Contents

Introduction

Inaddition to the custom command for static walking that was created for the Velociraptor (W) group, we also created four additional custom telemetry commands. For the telemetry we will be displaying the roll, pitch and the left right rotary sensor values. A rotary encoder will be able to tell us how much in each direction the encoder has been turned. The custom command is when we have information that is being sent to the robot from the user. The custom command that we created for static walking for instance; it lets the Velociraptor know when to start walking. However, telemetry would be the robot sending back information to the user what the leg placement is.

Telemetry Commands

Similar to the custom commands being set up on the Arxterra App, the telemetry commands are also set up in the application. Both the custom commands and telemetry are set up in the developer mode which can be accessed on the main menu. Once the Arxterra app is open and the developer mode has been started, click on the gear icon that is right below the camera image. Select custom command and telemetry configuration from the drop down menu that pops up. By clicking on the “+” sign that pops up,  the user is able to create the telemetry commands for the roll, pitch, rotary left and rotary right commands.

telemetry-pic1

Diagram 1: Developer mode with gear icon

telemetry-pic2

Diagram 2: Possible Option List : Select Custom Command & Telemetry Configuration

 Key Commands

For each of the commands created, the user would need to assign a specific hexadecimal value to it. For the roll, pitch, rotary_r and rotary_l commands, the hexadecimal values that were assigned were 0x41, 0x42, 0x43 and 0x44 respectively. A figure of the assignments can also be found below this section of the blog.
telemetry-pic3

Diagram 3: Telemetry command hexadecimal assignments

Once the custom telemetry commands have been created in the Arxterra app, there are a few additional lines of code that would need to be included in the Arduino code in order to be able to receive values. In the Arduino code, the user would also need to define the variable names with their respective hexadecimal values. A Packet ID would also need to be created to in order for the program to know that it is the start of a telemetry command.

telemetry-pic4

Diagram 4: Arduino assignment of custom telemetry commands

telemetry-pic5

Diagram 5: Packet ID created for each telemetry command

Testing

For the figure 6 below, hard coded values of roll =35, pitch = 10, rotaryLeft = 23 and rotaryRight = 46 were created in order to test the telemetry commands and determine if any values were received on the control panel. Unfortunately for the Wednesday velociraptor group, the electronics engineer was unable to include his actual coding commands for the sensors with the telemetry code. As a result, the only way the Wednesday velociraptor group was able to test the telemetry code was through hard coded values and not by actually receiving the senor values.

telemetry-pic5 telemetry-pic6

Diagram 6: Telemetry code testing

For figure 7, viewers are able to see the hard coded telemetry values of roll =35, pitch = 10, rotaryLeft = 23 and rotaryRight = 46 being displayed on the control panel.

telemetry-pic7

Diagram 7: Arxterra Control Panel displaying the telemetry output

Resources

  • None