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

 

Pathfinder Fall 2016 Final Summary

Table of Contents

Project Overview

By Sabina Subedi, Project Manager

Project Objective

The Pathfinder is an autonomous rover that is self-sufficient using solar panels. The design of the Pathfinder is inspired by the twin Mars rovers “Spirit and Opportunity.” The Pathfinder will utilize navigation waypoints on Arxterra control panel to traverse through the defined course, articulating ultrasonic range finders and LiDar sensor for obstacle avoidance. Digital slip differential will be implemented for unmanned turning of the rover during it’s course. In order to save battery, the Pathfinder will integrate sensors that will send signals to the motors to stop the wheels from spinning under no load conditions.

Mission Profile

The Pathfinder must successfully navigate a 0.18 mile (roundtrip) course to and from the solar panel charging station defined by the solar panel subproject group. The mapped out course contains 2 staircases with 3 steps each, then concrete path leading to solar panels charging station. The Pathfinder shall travel up and down the steps. The Pathfinder shall avoid any obstacles along the way, using ultrasonic and LiDAR sensors. Pathfinder shall complete its mission in one evening.  The pathfinder shall conduct its mission at night for better operation of the LiDar sensor.

The Design

one

Project Features:

  • Rocker Bogie suspension system
    • High clearance chassis
    • Superior stability on uneven surfaces
    • Obstacle climbing capability
  • Pan and tilt system
    • 2 servos for the rotation of the system, one for pan & one for tilt
    • Provides live video feed utilizing a cellular phone camera
    • Enclosed to protect the phone from external environment
  • GPS Navigation Mode with obstacle avoidance

System Design: 

By Jose Alcantar, Electronics and Controls Engineer

uno

The system block diagram above generalizes how the sensors and actuators will interface through the Arduino Leonardo. First, the Bluetooth receives and transmits any data and the Arduino decodes the data and takes action. The Arduino will either receive sensor data or drive the motors, depending on the commands sent. The diagram also shows the I/O expander is used to control the motor drivers and servos.

Experimental Results:

By Jose Alcantar, Electronics and Controls Engineer

No load conditions threshold:

picture3

The plot above shows the current draw data from one motor driven by the VNH5019. The purpose of this experiment was to find a threshold for finding the current drawn at no load conditions. From the graph, the no load current draw is about 500 mA and when a load is applied the motor draws about 1.3A. The threshold is necessary to set the threshold and shut off the motors when the current draw falls below this threshold.  

Field of View test for Ultrasonic Sensor:

picture1

Purpose:

Testing the field of view on the HC-SR04 to find a suitable mounting position for the two ultrasonic sensors along the front of the rover.

Procedure:

An object was placed in front of the ultrasonic sensor about 25 inches away; the position of the object was marked and moved in increments of 5 inches until the object was out of view. When the object was no longer detected the position was marked. The angle of the field of view was then calculated.

Results:

Based on the experiment, the angle of the field of view was found to be 18 degrees when measuring an object 25 inches away. The position of the sensors was determined by considering the clearance needed on each side of the rover. When considering the solar panels, the two ultrasonic sensors need to detect obstacles at least 5 inches to each side of the chassis. This will allow the pathfinder to avoid obstacles that may bump into the solar panels.

Subsystem Design:

By Jose Alcantar, Electronics and Controls Engineer

Interface Definition:

quatro

The above table shows the main pinout from the Arduino Leonardo. The main interfacing boards are the three VNH5019 motor drivers the PCA9685 I/O expander, the Bluetooth module, the LEDS, Ultrasonic sensors and the LIDAR.

cinco

The above table shows the interconnections of the PCA96805 I/O expander. The majority of the pins control the direction pins of the 6 H-Bridges and the pan and tilt servos.

Software Design:

By Jose Alcantar, Electronics and Controls Engineer

seis

The above flowchart demonstrates how the Arduino receives the incoming data from the Arxterra App and acts based on the commands sent. When a command is sent the command, decoder determines which function to begin. Depending on the mode the Pathfinder will go into either Manual mode, GPS navigation mode or charging state. The called function will drive the motors and read sensor values to complete the requested action.

siete

The flow chart demonstrates how the pathfinder will act when avoiding obstacles. The pathfinder will read sensor values and go into either state 1, 2 or 3 depending on the reading of the sensor values. The rover will then either avoid left, avoid right or move forward.

Waypoint Navigation Mode:

ocho

For waypoint navigation mode, the Arduino reads the waypoint coordinates and current coordinates of the pathfinder. Then the distance and heading to the next waypoint is calculated the rover then begins moving to its destination while actively avoiding obstacles and continously updating coordinate data. Once the waypoint is reached the waypoint data is deleted and manual mode is activated.

For more detail on the Waypoint navigatioin algotithm see:

http://arxterra.com/waypoint-navigation/

Manual Mode Flowchart:

nueve

The flowchart shows the basic algorithm to drive the motors when the direction pad is used to control the pathfinder and pan and tilt servos.

For a more detailed explanation of the MOVE functions see:

http://arxterra.com/implementing-move-command-firmware/

Cable Tree

By Nick Lukin, Design and Manufacturing

The cable tree shows approximately where the wires outside of the main PCB will be laid out on the Pathfinder. It includes connectors for items that can be taken on and off the chassis.

cabletree2cabletree3 cabletree

Hardware Design

By Nicholas Lukin, Design and Manufacturing Engineer

Introduction

The overall mechanical design consisted of various key features that ensured the customers design requirements were met. The first feature is the pan and tilt phone system. The customer required that the Pathfinder come equipped with an electronically controlled pan and tilt phone holding mechanism. The next feature is the rocker bogie suspension system. This suspension system helped fulfill the requirement of going over rough desert terrain and makes it possible to climb up and down obstacles such as stairs and rocks. The next feature is that the Pathfinder is made out of material that can withstand desert conditions as per the requirement stated by the customer. The final feature is the seamless interfacing areas on the chassis that makes it possible to properly interface with the solar panels that will be attached to the top of the chassis.

one

Form Factor

 

Rocker Bogie Suspension System

 two

Figure 1: Exploded View

 Figure 1 shows the exploded view of the entire chassis including the rocker bogie suspension system. The system itself allows the pathfinder to go over uneven surfaces while maintaining stability and traction. There are two pivot points located in the suspension system. The middle pivot point is attached directly to the top plate of the chassis and allows the plate to stay level while traversing up and down obstacles such as stairs. The back pivot point allows for a further range of motion when going over various obstacles. Having two independent suspension sides allows the Pathfinder to go over a variety of terrain. Each side reacts independently to obstacles which allows the center of mass to stay relativity stable and low.

 

Tube Leg Design and Material

  three

Figure 2: Tube Leg Design

In order to make the Pathfinder look as close as possible to the Spirit/Opportunity rovers it was decided to make the legs of the rocker bogie suspension system out of tubing instead of plate like the previous Pathfinder designs. Not only did this make the Pathfinder look more realistic but it also added more strength to the overall design. It was decided that the material used for the design would be 6061-T6 aluminum because of its high corrosion resistance and overall strength. Figure 2 shows the overall mass properties of the Pathfinder.

four

Figure 3: Mass Properties

The overall weight of the Pathfinder is about 25 pounds as shown in figure 2. This weight it light enough to ensure that the motors do not get overworked. If non aerospace grade aluminum was used such as plain 6061 the weight would be around 32 pounds which is a 20% increase.

Fabrication of Overall Chassis

 five

Figure 3: 2-D Drawing for Fabrication

 

The first step in the fabrication process was to obtain the proper 2-D drawing in order to figure out what material needed to be machined and what needed to be welded. It was decided that the back legs, the top plate and the top side plate would all need to be cut and machined. Figure 4 below shows the machining process.

six seven

Figure 4: Machining Legs and Top Plate

 

eight

Figure 5: Fabricating Legs

 

Proper measuring tools had to be used in order to make sure the legs were the correct size and that the overall chassis would be straight when it was planted on all six wheels. Tubing needed to be cut at the proper angles (135 degrees) and welded. Special attention needed to be given while welding to ensure the metal did not warp and create an unwanted dimension.

nine

Figure 6: Final Leg Fabrication

Figure 6 shows the final leg fabrication. Each leg was nearly identical to one another. This helped achieve the goal of keeping symmetry throughout the entire design and made sure the Pathfinder would achieve the proper form factor as required by the customer.

ten

Figure 7: Light/Sensor Bar

 It was a requirement that the Pathfinder was equipped with some type of lighting and ultrasonic sensors. In order to properly attach the lights and sensors to the chassis it was necessary to custom fabricate some type of holding mechanism. A light/sensor bar was machined in order to properly attach the critical lights and sensors. Figure 7 shows the final product.

eleven

Figure 8: Final Chassis Design

 Figure 8 shows the final chassis completed with the pan and tilt phone system, wheels and electrical all attached. The final design looks nearly identical to the solid works model. Careful preparation and precise fabrication achieved a design that is accurate and that meets the customers’ expectations. 

Pan and Tilt Phone System

 

twelve 

Figure 9: Pan and Tilt Phone Holder

 

In order for the Pathfinder to see where it is going and to properly connect to the Arxterra control panel the customer required that a Pan and Tilt phone system be built. The system would need to house a Samsung Galaxy S7 edge and be able to withstand a desert environment. The design of the system can be seen in figure 9. The system is controlled through the Arxterra control panel via two servos. We decided to make the phone holder out of 6061-T6 material just like the chassis. This would ensure that the phone would be properly protected and that it was light enough so the servos could move it.

thirteen

Figure 10: Pan and Tilt Exploded

It was also necessary to attach a lidar sensor to the front of the phone case. Lidar was needed in order to properly implement an autonomous driving mode system. The front plate of the phone holder was designed to leave room for the cameras of the phone, to house the lidar sensor and to properly expose the communication antennas of the phone. All these features can be seen in figure 10.

 

fourteen

Figure 11: Fabricating Phone Holder

Figure 11 shows the fabrication of the camera view holes of the front case of the phone holder. It was necessary to properly measure the distance between the top of the phone to the end of the camera to make sure that there was no interference between the metal and the camera.

 

fifteen

Figure 12: Final Product

Figure 12 shows the final build of the pan and tilt phone holder mechanism. It was necessary to utilize an off the shelf gimbal system to mechanically drive the pan motion of the holder. This part was connected to the pan servo and ensured smooth lateral operation of the entire system.

Interfacing the Solar Panels

 sixteen

Figure 13: Solar Panels Interfacing

It was necessary that the chassis and solar panels seamlessly interface as per the requirement of the customer. Proper interfacing was achieved by creating mounting stand offs on the top plate of the chassis of the Pathfinder. The solar panels would then have holes that would properly align with the mounting pads and a small thumb screw would be used in order to properly secure the connection. These stand offs can be seen on the top plate of the chassis in Figure 13. The pan and tilt phone holder would also need to come off by hand in order to properly interface. This was achieved by machining a threaded stud to the top of the phone holder stand. The customer could then easily screw the phone holder on and off by hand.

 

Figure 14: Actual Interfacing

Figure 14 shows the actual interfacing of the solar panels and the chassis assembly. The 4 thumb screws that were utilized can be seen in figure 14. It was also noticeable that the proper form factor was achieved between the solar panels and the chassis.

 

PCB Layout

eighteen

Figure 15: Final PCB Design

A custom PCB design was required in order to interface all of the boards that were utilized to control the Pathfinder. The overall function of the board was to take various pins from the Arduino and rout those pins to other boards that could directly connect to the custom PCB. Two ultrasonic sensors, a Bluetooth module, a servo driver board, a LED interface, a LIDAR connection and 3 motor driver boards would all be able to directly connect to the board. The board would also implement a buck converter in order to step down the main battery supply voltage from 12V down to 6V to properly charge the phone in the phone holder system.

Interface Design

In order to properly route all the wires from the Arduino pins to the proper locations it was necessary to lay the board out in an efficient manner. All the pins that required headers were laid out as close to the edge of the board as possible. They were also spaced apart so that room was left for whatever connectors would be used. 45 degree bends were utilized on all traces in order to maintain a clean and professional looking PCB. A ground plane was utilized for all ground connections and a power bus was used in order to properly connect VCC across all pin connections. A power plane could not be used since the buck converter would also be on the same board and would be utilizing a different voltage level at its input.

Buck Converter

 nineteen

Figure 16: Typical Buck Design

 The LM2596 chip was selected for the buck converter. This chip allows a maximum of 3 amps to be passed through it and has an input voltage range of up to 40 volts and can step down voltages as low as 3.3 volts. For the phone charger we designed the buck converter to output 6 volts to properly charge the Samsung Galaxy S7 edge. All surface mount components were utilized for the design and attention to detail was key during the lay out process. Per the data sheet it was necessary to place the inductor and capacitors as close to the chip as possible. It was also necessary to use the correct size power traces to prevent overheating and possible damage to the board. The buck converter was designed to output a max of 1 amps and therefore a maximum power trace of .032 inches was used. This thick trace can be seen on figure 15 at the input of the buck converter. A micro usb was used on the output of the buck so the phone could easily plug into the charger.

 

Soldering Process

 

Figure 17: Soldering the Board 

The custom PCB was soldered by hand and then was tested for proper functionality. It was noticed that there was a direct short between ground and Vcc. Initially it was thought that the soldering process caused the short but upon further inspection it was determined that the board came shorted from the factory. Two other boards that were not yet soldered were tested and they both had direct shorts between Vcc and ground.

Verification and Validation Test

https://drive.google.com/open?id=0Bzq09K9mZabrd0E4a01mUElLdlE

Work Breakdown Structure (WBS)

wbs

Resource Reports

Please refer to the Project Resources section to find the resource reports, including Mass, Cost and Power Report.

Top Level Schedule

schedule

The general top level schedule was created using the generic rubric provided on the class website. The top level schedule specific to the Pathfinder (Chassis subproject) was created using the Work Breakdown Structure above and the general top level schedule. This schedule consists of all tasks that are to be completed before the end of the semester, December 15th, 2016. The project milestones are broken down into four phases: Planning, Design, Assembly and Project Launch. The tasks within the different phases are then divided up by the divisions. All division members are assigned specific tasks that they are responsible for, per “Job Descriptions” document available on the class website. Main tasks then were broken down into sub-tasks, if applicable. All tasks include start and finish dates, as well as percent complete. 

Conclusion and Future Plans

Overall the project was a success as we were able to build a functioning rover that achieved the majority of the requirements that were established by the customer. The mechanical design worked as expected with only some small issues. One improvement that is necessary is adding stops to the back pivot point of the rocker bogie suspension system. The range of motion needs to be limited at some point in order to properly go up obstacles such as stairs. Another improvement would be to possibly get bigger wheels. The larger the wheels the better it can go up and over obstacles. I believe that the current design is sufficient for future students to build off of and improve upon.

Project Resources

 

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.

Biped 2016 Fall – Final Documentation

Introduction Project Overview

Project Objective

Team Biped will produce a two legged 6th generation toy biped robot that will replace the traditionally used servos with a dc motor and achieve static walking. By utilizing the 3Dot Board, the robot will participate in the end of semester, December 14th, 2016, game called: Save the Human.

Mission Profile

Biped shall compete, alongside other toys such as Goliath and Velociraptors, in an end of semester approximately hour long game: Save The Human. Biped should successfully walk, using Goliath’s live video feed as the field of view, from the opposite end of the room to the finish area without coming into contact with a Velociraptor. The Biped will  maneuver through multiple obstacles by turning through walls, sensing color pads, and stepping through uneven terrain placed on top of Linoleum floors.

build4

Project Features

A key component of our design is replacing the ankles with servos. The ankle servo eliminates having to use two dc motors to accomplish a pivot turn. The placement of the servos provides a strategic way to balance on on foot and then turn the entire body to face the desired direction.

 

turning

Requirements

System Block Diagram

Interface Definition

Interface Matrix and Cable Tree

 

Mission Command and Control

Software Design

Arxterra App Communication

Custom Commands

custom-comands

Electronics Design

Component Selection and Trade Off Studies

Electronic Experiments

 

Firmware

PCB Schematics

PCB Layout

lay1

lay

Hardware Design

Hardware Experiment

Hardware Selection – Trade Off Studies

 

Verification and Validation Test

Project Status

Updated Mass and Power

Cost Report

 

Vendor Item Unit Price Quantity EE Dept. /Total EE Dept. Extended Cost
1 LOWE’S Miscellaneous Hardware 54.31 54.31
2 Mouser Electronics 27.82 27.82
3 Pololu Hardware (Motor/Gearbox/ Wires) 9.55 9.55
4 Hobby People Electronics (Battery/ Connectors) 16.33 16.33
5 Oshpark Color Pad PCB 0.60 0.60
6 Oshpark Shield PCB 20.45 20.45
Total: 129.05
Allocated Budget 125.00

Schedule and Burndown

Resources

[1] Project video

[2] PDR

[3] CDR

[4] Eagle Design

[5] Biped Code

[6] Solidworks 

[7] Animation/ Simulation

[8] PCB layout

Fall Biped 2016- Hardware Alternative Updates

By: Alan Valles (Electronics and Control)
Approved by: Ijya Karki (Project Manager)

Table of Contents

Introduction

The purpose of this document is to provide suggestions for the next iteration of the design of the PCB shield for the Biped. These improvements are based on feedback and experience in the manufacturing, design and build of the PCB.

Analysis

The engineering method is an iterative process. There are several suggestions and improvements that can be made to Biped schematics in [2]  to improve performance of the system.

The Schematics since CDR were not revised much. However, after the realized PCB system was put together and tested, there are several updates that I would make for the next revision of the shield. I would add pin headers for the I2C bus. This would allow for flexibility in future iterations for the Biped Project. In the future, I also would have changed the design to incorporate locking headers like the Ph-series of battery and motor connectors for the rest of the external peripherals. These will allow for more secure connections. The combination of jumper wires and pin headers was not a fixed connection and caused major amounts of headache due to contacts not connecting. It lead to perplexing troubleshooting in order to see if bugs were software related or hardware related.

33

Figure 1. Circuit System.

Next, I would add a protection circuit to prevent reverse current in the event of reverse polarity. The chosen lm1084 does not have this built into it. However, the battery was hooked up with reverse polarity the first time. The LM1084 was a robust chip because after reversing polarity of input the LDO still held up fine and output 5V to the rest of the systems. TI offers some quick suggestions to mitigate this issue, by using a protection diode or FET as shown.

34

Figure 2. NMOS FET in the Ground Return Path.

Next, The Ext- connection was not solidly grounded on the PCB, rather it created a GND connection on the 3Dot board itself. To correct this issue, traces and or vias to GND plane can be created near the connector of the Battery for stronger connection to GND. Finally, another issue was that 3.3V and Ext+ were being paralleled on the PCB that was ordered. After discussion and analysis, the president and I were able to fix this by isolating the connecting point by cutting a copper trace. The GND connection on the shield was never connected to EXT- connection on the 3dot. A small wire was post manufacturing. But the future shield should tie these point together at some point.  Also the SDA and SCL lines were crossed for A2D converter so that would obviously be fixed in next iterations.

35

Figure 3. After PCB in Production.

These are some of the changes that were recognized after our PCB was in production that should be fixed for the next iteration.

Conclusion

In conclusion, the pin headers for encoder connector, and other external peripherals would be changed to a locking style, a reverse current protection circuit would be added and various clean up work would be done such as tying GND to Ext-.

Reference

[1] http://www.ti.com/lit/an/slva139/slva139.pdf

[2] http://arxterra.com/fall-2016-biped-updated-schematics/

 

Fall Biped 2016- Color Sensor Design

By: Alan Valles (Electronics and Control) Approved by: Ijya Karki (Project Manager) Table of Contents Introduction  The purpose of this blog post is to explain the function and design of the custom PCB color sensor that was made. Analysis This color sensor was made to meet our requirements and detect color pads below. Two version […]

Fall 2016 Solar Panels: Project Summary

By Inna Echual (Project Manager)

Table of Contents

Project Overview

Executive Summary

Project Objective

The design of the Fall 2016 Pathfinder project was taken directly from NASA’s Mars Exploration Rovers, Opportunity and Spirit. The Pathfinder will be designed to be self-sufficient using solar panels, as well as implement the solar deployment mechanism employed by the two aforementioned rovers. The solar panels should able recharge the Pathfinder’s battery allowing it to traverse rough terrain. The solar panels must also articulate to track the sun, maximizing the amount of solar power received.

Mission Profile

The project will be demonstrated by parking the Pathfinder in the Central Quad on California State University, Long Beach located at 33°46’40.7″N 118°06’48.9″W.  In addition to the location near the defined travel course, the parking spot was chosen as it had low traffic and free of shading. The parking spot is indicated in Figure 1.

unnamed-1

Figure 1: Pathfinder Charging Spot

img_7656

Figure 2: Pathfinder Charging Spot (Magnified)

Project Features

  • Customized Solar Panels

    This will be done using 5 strings in parallel of 30 solar cells stringed together in series to fit the customized solar shape of the aforementioned rovers (see compare our layout in Figure 3 with Spirit’s layout in Figure 4).

snapchat-406817528

Figure 3: Fall 2016 Solar Panels 

spirit_rover_cleaned

Figure 4: Spirit Rover Panels

  • Panel Proportionality

    The solar panels will be configured to be identical to the form factor of the solar panels on the Opportunity and Spirit rovers (see Figure 5).

proportionaliry

Figure 5: Form Factor Consideration

Experiments Checklist

  • Experiments on Solar Cell Cutting and Efficiency to determine stringing
  • Back of the Envelope calculations to determine stringing and layout
  • Experiment using MPU 6050 to determine rover balance
  • Experiment using DC motor as a stepper motor with an encoder
  • I2C – test communication between Arduino Uno and Arduino Mega
  • Sun tracking with photo resistors

 

 

System Design

System Block Diagram

sbd_updated

Figure 6: Updated System Block Diagram from CDR

Updated System Block Diagram from CDR brief.

Subsystem Design

Interface Definition

Interface Matrix

screen-shot-2016-12-17-at-6-09-53-am

Figure 7: Interface Matrix

Interface Control Document

As defined in the mission profile, the Pathfinder will be allowed to travel a course on the upper campus of CSULB. This system is designed to replicate the Spirit & Opportunity Mars Rovers. The program objective is to be self-sufficient. In order for this system to be successful with it’s mission, the two systems; Chassis & Solar Panel, must work together with one another. The Solar Panel will be in charge of supplying power to the battery, and the Chassis will then be able to use this battery and travel the course.

The Interface Control Document will be used to provide an outline for the responsibilities aligned with each system. It also sets out the interfacing requirements to help move the design forward for each of our systems in the following disciplines: Mechanical Interfacing, Power Transactions, and Control Mechanism & Data Transfer. It also includes some constraints, assumptions, and possible risks involved in these factors.

Interface Control Document

Mission Command and Control

Software Block Diagram

screen-shot-2016-12-16-at-2-20-18-pm

Figure 7: Software Block Diagram

The software block diagram in Figure 7 explains an overall understanding of what the Solar Panel system’s software entails. It also includes a portion of the Chassis system and how we are interfacing with one another electronically, along with a legend on the bottom left to help detect what the different colors mean.

Software Block Diagram Update

Electronics Design

Motor Trade-Off Study

DC Motor With Encoder Experiment

I2C Communication Experiment

Creating a Port Expander Using IC MCP23017

Firmware

 

PCB Schematic

fritzing1

Figure 8: Fritzing Diagram for Motor Driver

fritzing2

Figure 9: Fritzing Diagram for I2C Communication

bread1

Figure 10: Breadboard for Motor Driver

sche

Figure 11: Schematic

PCB Layout

PCB Layout

Hardware Design

Folding Mechanism Trade-Off Study

Mechanical Design

Choosing Panel Thickness / Stress Tests

Verification and Validation Test Plan

Verification Test Plan

Project Status

Power Allocation

screen-shot-2016-12-17-at-10-01-34-am

Mass Allocation

screen-shot-2016-12-17-at-9-47-54-am

Cost Report

screen-shot-2016-12-17-at-11-04-33-am

Concluding Thoughts

Lessons Learned

  1. Being the project manager helped me learn a lot about group and project management. Because this project is an integrated project with the Thursday class, it was very difficult to coordinate meeting times together or even contact the other group, therefore our project would fall back at times.
  2. It is hard to manage the conflicts among cost, schedule and performance. Our pathfinder team was having trouble on getting all the parts we wanted on time. Because we were short on time, there were sacrifices we had to make in terms of which parts of the project we wanted to get working depending on how many requirements it could fulfill.
  3. I learned too late that I should be stricter on tasks I wanted to get done to keep the project on schedule.

Resources

[1] Project Video

[2] Critical Design Review (CDR)

[3] Preliminary Design Review (PDR)

[4] Project Schedule

[5] Verification and Validation Documents

[6] SolidWorks Files (zipped)

[7] Fritzing Files (zipped)

[8] EagleCAD Files (zipped)

[9] Ardino / C++ Code

[10] Bill of Materials

[11] Final Interface Control Document (dated 12/13/16)

References

[1] Spirit Rover Cleaned: https://commons.wikimedia.org/wiki/File:Spirit_Rover_Cleaned.jpg