Spring 2018 3DoT Hexy: Final Project Summary

By:  Eduardo De La Cruz (Project Manager & Manufacturing Engineer)

Approved By: Miguel Garcia (Quality Assurance)

SpiderBot Team:

Eduardo De La Cruz (Project Manager & Manufacturing Engineer)

Raymundo Lopez-Santiago (Mission, System, and Test Engineer)

Kris Osuna (Electronics and Control Engineer)

Mission Objective

For the Spring 2018 3DoT Hexy SpiderBot project, under the EE400D program, we will incorporate Arxterra’s 3DoT Robotics microcontroller board to design, build, and remotely operate a toy for people ages 8+. Control of the 3DoT Hexy SpiderBot will be accomplished via the Arxterra Mission Control Panel and/or ArxRobot application. 3DoT Hexy SpiderBot is to navigate remotely through a custom-built maze, memorize the path it took, start over, and autonomously travel through the path it took. The 3DoT Hexy SpiderBot is to have the ability to avoid collisions if it encounters other robots in the maze. The overall project is to remain within budget of $250 and be completed by May 15, 2018.

Level 1 and Level 2 Requirements

Level 1 requirements are high level requirements and are broken up into general requirements and specific robot requirements for 3DoT Hexy. All level 1 requirements are branched out to specific system and subsystem requirements (level 2 requirements).

https://www.arxterra.com/spring-2018-3dot-hexy-level-1-and-level-2-requirements/

System Design

System Block Diagram

Due to changes in the maze printing material and the fact that we are no longer using a boost converter, the UV LEDs will no longer be used and instead IR LEDs along with Light sensors will be used to handle intersection detection. Another change that is noticeable is instead of using an 8-channel I2C expander, we are now using a 4-channel I2C expander. The color sensor was removed from the design since we are using light sensors for intersection detection. A new addition to the design is the use of a gyroscope to aid in directional turning and two LEDs to act as eyes of the spider robot. The interface matrix was updated to reflect changes. Only 8-pins from the bottom shield of the 3DoT board will be used.

https://www.arxterra.com/spring-2018-3dot-hexy-system-block-diagram/

Experimental Results/Research

UV Trade Study

The original idea for the autonomous navigation of the maze was to have 3DoT Hexy take a picture, process the image and decide its action based on the image. The camera idea was proven to be too extensive with a high learning curve, so we decided to research other methods for the autonomous navigation through the maze. We decided to look into UV sensors to detect and follow a UV marker line. Since we were not going to use 5V to drive the LEDs, we changed UV LEDs to IR LEDs since the data shows that the UV sensors can not accurately differentiate when the UV LEDs are powered by 3.3V.

https://www.arxterra.com/spring-2018-3dot-hexy-uv-sensors-study/

Motor Type selection and Testing

Factors for choosing the best-brushed motor for 3DoT Hexy included cost, size, voltage rating, and speed-torque relationship. Based on tests performed and since we are using a similar gear system from 3DoT David, it was concluded that a motor rated at 6V at no load speed of 530 RPM ( Link) will provide enough torque to drive the 3DoT Hexy’s gear system and legs. Based on our final design and tests we will be using this motor at 3.6V from the battery with enough allocation for all the sensors used. https://www.arxterra.com/spring-2018-3dot-hexy-mock-up-motor-power-under-load/

RGB sensor study

Color sensors will no longer be implemented for our projects due to a customer revision of the maze definition. According to the customer, since we plan on using UV sensors/light sensors for our line following design, it would be more optimal to implement intersection detection using a UV grid (as shown in the maze definition). Also color sensing was out of the question for robots like biped or velociraptor whom would have had difficulty reading RGB due to required placement position. If interested in reading our data/results, reference the blog post below.

https://www.arxterra.com/spring-2018-3dot-hexy-rgb-color-sensors/

Subsystem Design

Interface Matrix

Based on customer concerns with the TPS61253A 9-ball 1.2-mm x 1.3-mm WCSP package, we explored other methods to not use a boost converter and further investigate operating all electronics of the robot at the rated 3.6 V from the RCR123A battery. After improving the gear mechanism with the addition of bearings and bushings, we were able to operate the robot at 3.6V while having stable movement with weight attached on top of the robot (simulating the final weight of all devices used for the final robot configuration). Since this change occurred, we no longer will use any connections from J1 and J2 from the 3DoT board. UV LEDs will no longer be used and will be replaced with IR LEDs. Based on customer recommendation instead of using the 8-channel TCA9548A I2C model, we are going to use a 4-channel model: PCA9544A. All peripheral devices will be connected to the Custom Sensor PCB developed by Kris Osuna (Electronics and Control Engineer). The Custom Sensor PCB is connected to J3 of the 3DoT board.  Two additional extra LEDs are added to act as eyes of the spider

https://www.arxterra.com/spring-2018-3dot-hexy-interface-matrix/

Cable Tree

Based on our design, it did require a lot wires which caused some issues when integrating all of them to their final position/destination. One main problem was with the positioning of the three-light sensors. A recommendation for a design improvement is to integrate the light sensors into the custom sensor PCB and place the PCB at bottom front bracket. The issue that needs to be further looked at is the 30-degree angle needed for the IR LEDs and the positioning so they maintain that angle. Another recommendation is start the design of the robot by first thinking about the wiring route and possibly integrating 3D printing wire assist clips to ease in the final product wiring. Images and wire interfacing are provided in the blog post below.

https://www.arxterra.com/spring-2018-3dot-hexy-system-cable-tree/

Getting 3DoT David Working

Since we planned on basing our design of Spring 2016 3DoT David, the manufacturing and E&C engineers got to fixing, and analyzing the design. Below is a blog post explaining what they learned and planned on improving. https://www.arxterra.com/spring-2018-3dot-hexy-getting-3dot-david-working/

Decision on Movement Mechanism

Having had studied the klann Linkage Mechanism and the Spring 2016 3DoT David Hexbug 2 Mechanism more in depth, we decided that implementing the Hex Bug 2 design was the way to go. Reasoning behind picking this mechanism is provided in the blog post below. https://www.arxterra.com/spring-2018-3dot-hexy-decision-of-movement-mechanism/

Determining Gear Design

We decided that pursuing a 3:1 configuration would be the way to go. This is due mainly to the femur-to-gear joints. Design specifications for our 3:1 cam design is provided in the link below.

https://www.arxterra.com/spring-2018-3dot-hexy-determine-gear-design/

Improving 3DoT David Design

Since we decided to model 3DoT Hexy of Spring 2016’s 3DoT David, Prof. Hill recommended that we get in contact with the owner of 3DoT David to have access to the robot. Luckily, we were able to get in touch with the owner and were permitted to use the robot as a reference. From 3DoT David, we learned a lot about: movement dynamics, overall dimensions, and weakest points in the structural design. From the design we decided to modify: the gear capture system, gear to motor shaft connection, lift mechanism, leg joints, wire management, redesigning the top and bottom plate. https://www.arxterra.com/spring-2018-3dot-hexy-improving-3dot-david-design/

Mission Commands and Control

Final Software

The E&C Engineer was unable to get the line following code to function correctly on the arxterra app. The line following on Arduino only worked ok but due to the sensors not fitting correctly in their spot, consistent values were difficult to obtain. The sensors kept moving positions and angles. The blink custom command shows that the handle is correct and is going through, but Detect command does not work for some reason. Our team did not have a dedicated software team member which lead to extra work on the E&C Engineer. If we had another team member we could have gotten the code working.

https://www.arxterra.com/spring-2018-3dot-hexy-final-arduino-code/

 

Electronic Design

Fritzing Diagram

We used the open source fritzing software to create a prototype that will show all connections to an Arduino Leonardo. The Leonardo is used because it uses the same processor as the 3DoT board. The Leonardo provides 3.3V to the pins which is less than the 3DoT board provides, so if it works on the Leonardo it will work on the 3DoT board. The prototype will be able to move with motors connected to a dual motor driver to control the motors. Three UV sensors will be connected with three UV LEDs. The UV sensors and LEDs will help the robot navigate the maze. An I2C multiplier for the serial data is needed. An ultrasonic sensor is needed with two digital pins. The ultrasonic sensor will detect other obstacles. We were able to use an ultrasonic distance sensor with only one digital pin.

https://www.arxterra.com/spring-2018-3dot-hexy-prototype-fritzing-diagram/

PCB Schematics

The PCB schematics included in the blog post below are for the custom sensor shield designed by the E&C engineer. The schematic must contain these parts: 1-to-4 I2C multiplex, connection to UV sensors, connection to LEDs connection to ground and power and connection to the ultrasonic distance sensor. The UV sensors, ultrasonic sensor, LEDs and booster are not going to be directly to the schematic. https://www.arxterra.com/spring-2018-3dot-hexy-spiderbot-schematic/

PCB Layout

Two PCBs were designed by the E&C engineer: a sensor shield and a booster shield. The booster shield was discarded for a variety of reasons. 3DoT Hexy has been improved and can move with the load at 3.7V. We will no longer be using the UV LEDs at 5V instead we will be using IR LEDs at 3.3V. E&C suggests learning Eagle CAD and starting this process as early as possible due to the fact that the PCB design process undergoes multiple reviews before getting the green flag to print.

Booster Shield Layout

https://www.arxterra.com/spring-2018-3dot-hexy-booster-shield-layout/

Sensor Shield Layout

https://www.arxterra.com/spring-2018-3dot-hexy-sensor-shield-layout/

Custom PCB Assembly

https://www.arxterra.com/spring-2018-3dot-hexy-custom-pcb-assembly/

Bill of Materials (BOM) Report

This post shows all the parts needed to create the custom shields for the 3DoT. It also includes the cost of items that will not go on the shield but is needed to make 3DoT Hexy work correctly.

https://www.arxterra.com/spring-2018-3dot-hexy-electronic-component-bom-and-order/

Hardware Design

Blueprints/Mechanical Sketches

The blueprints show the dimensions of all parts designed in solidworks. These should aid the manufacturing engineer in designing 3DoT Hexy if the solidworks files are not available.

https://www.arxterra.com/spring-2018-3dot-hexy-mechanical-drawings/

3D Models

The 3D models give detailed explanations of why things look the way they are. We went through 4 revisions of our design before producing a design we were satisfied with.

  https://www.arxterra.com/spring-2018-3dot-hexy-3d-model/

Prototype Part Adjustment/Modifications

This post gives a quick run through of all the things we modified and learned from creating the prototype. For the most part it would play to the teams advantage if the manufacturing engineer has to his disposal tools such pliers, different types of screwdrivers, rotary power tools, drills, power saws, etc.  

https://www.arxterra.com/spring-2018-3dot-hexy-prototype-part-adjustments-modifications/

Assembly

The purpose of this blog post is to demonstrate how all parts designed in Solidworks were put together along with other outsourced materials. We will be assembling two  models of our robot: the prototype and the final model.

https://www.arxterra.com/spring-2018-3dot-hexy-assembly-prototype-final/

Project Status

Resource Report

This blog post covers 3DoT Hexy’s Resource Report which include cost, power and mass.Values for the battery and 3DoT board were initially estimated based on the final blog post of 3DoT David. Values for each component or device are updated as the project is further developed

https://www.arxterra.com/spring-2018-3dot-hexy-resource-report-cost-power-mass/

Updated power budget can be found by clicking the link below.

https://www.arxterra.com/spring-2018-3dot-hexy-power-budget/

3D Print Times

Print time quotes were obtained from two sources: Ridwan and Long Beach Makers. Parts for prototyping were printed with a .3 mm layer height for quick production.

https://www.arxterra.com/spring-2018-3dot-hexy-3d-print-times/

Product Breakdown

This document follows the Work Breakdown Schedule (WBS) developed by Eduardo De La Cruz (Project Manager and Manufacturing Engineer). This PBS is split into five sections to outline the major components of 3DoT Hexy. The five sections are electronic hardware, software, movement, manufacturing, and power

https://www.arxterra.com/spring-2018-3dot-hexy-product-breakdown-schedule/

Work Breakdown Structure

The diagram is broken down into task each division engineer will be responsible for in the production of the final product. These assignments are based of the task matrix we developed as a class. Engineers can use this diagram as a reference for what they need to do. https://www.arxterra.com/spring-2018-3dot-hexy-work-breakdown-structure/

Project Schedule

The project schedule was generated using excel’s Gantt project planner. The project schedule mirrors the time frames and due dates established in the task matrix. The goal is to provide a visual reference of how far or close one is from reaching their deadlines for a given task. A majority of our task were completed past established due dates. Despite this, we were able to complete the majority of our task. A burndown is included that shows how close we were to completing all our task.   

https://www.arxterra.com/spring-2018-3dot-hexy-project-planning-and-scheduling/

Final System Integration and Test

Most of the tests were conducted prior do the day of the final (05/15). Tests performed include ultrasonic ranges, light sensor value readings, and arxrobot communication to the pro micro board. Assembly and disassembly were performed on the day of the final.

https://www.arxterra.com/spring-2018-3dot-hexy-final-system-integration-and-test/

Preliminary Design Review (PDR)

The preliminary document is a progress report made half way into the semester that covers everything we have done. As of the preliminary design, we had not yet created a prototype of our design. It is very important that the team is able to get a prototype ready by the PDR day in order to get feedback by the professor.

https://www.arxterra.com/spring-2018-3dot-hexy-preliminary-design-review/

Conclusion

There were still a lot of things that needed to be done by manufacturing and E&C to make the final product perfect. For the most part we were able to control the spider as an RC toy. More time needed to be invested in autonomous control in order for the spider to have been able to navigated through the maze autonomously. Things that the next generation can improve on are:

1. Substituting the brass bushings used to pinch the gears for a more stronger material that doesn’t warp when tightened.

2. Exploring ways to reduce the play in the legs (wiggle) will make the design more sturdy.

3. Reducing the scale of the robot, in order for it to fit in a maze room

4. Method of hedge/line detection for autonomous navigation. For the most part we spend an extensive amount of time pursuing UV line detection only to end up with IR detection. It would be interesting to explore alternative methods of hedge/line detection that don’t involve IR.

5. Wire Management. As explained by the professor it is best to design a project based on the wire positioning. MST and Manufacturing should get together and agree on a design that looks good and keeps in mind how all wires will be routed.

6. Removing the driving gear and just connecting the motors to either one of the two gears that connect to the 30T gears will achieve the same results. This  will eliminate the need of the additional gears.

Lessons Learned

For the most part we learned a lot about what to expect from EE400D. Below are some helpful tips to help the next generation get a head start.

https://www.arxterra.com/spring-2018-3dot-hexy-lessons-learned/

Resources

PDR Power Point

UPDATED-3DoT Hexy_ Preliminary Design Review (1)

Project Schedule and Burndown 

Planner Final2.0

burndown

Verification and Validation Documents 

Master-Verification List-and-Test-Procedures_3DoT_Hexy_5_15_18 Verification_Test_3DoT_Hexy_Spring2018_Final

Verification_Test_3DoT_Hexy_Spring2018_Final

AssemblyDisassembly

Solidworks files 

Final SolidWorks Files

Frtizing Diagram 

Hexy-Fritzing

Eagle CAD files 

Sensor Shield

Arduino Code 

Hexy

BOM

Sensor-Shield-Final

Sample Waiver 

Request for a Waiver of Program Requirement

Project Video

https://www.youtube.com/watch?v=z3S46hI10LI&t=1s

 

Spring 2018: Biped Micro FOBO Final Blog Post

By: Miguel Gonzalez (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

BiPed Team:

Miguel Gonzalez (Project Manager)

Jeffery De La Cruz (MST)

Jorge Hernandez (E&C)


Mission Objective

By: Miguel Gonzalez (Project Manager)


Goal for this project is to design and manufacture a BiPed Robot. This robot will be slightly similar to the BiPed robot that was created in Spring 2016 and another bipedal robot named FOBO, created by Jonathan Dowdall. Our design will be based on FOBO but will be much smaller in size that implements micro servos for walking and turning. For sensing its surroundings, the robot will utilize ultrasonic and Infrared sensors. Other key differences between the FOBO and our micro version of FOBO are that:

  1. The head of our robot shall house a 3DoT board, servos controller shield, and a sensor shield.
  2. The movement of our robot will be conducted via SG90 micro servos that will replace the clunky and oversized Hitec HS-805BB servos.
  3. The legs of our robot will have a more efficient method to mount and utilize its servos for weight reduction and for longer walking steps.
  4. Our robot will utilize Bluetooth technology for user to robot communication and movement control
  5. The robot’s power system will be changed from heavy LIPO batteries to a single Samsung 18650 battery located near the robot’s center of mass.

The mission of Project BiPed is to design the BiPed to navigate a predesigned maze. The BiPed shall be able to navigate the maze with user input from the Arxterra App/Control Panel. The BiPed will be able to memorize the user-defined path and will be able to navigate it autonomously. In addition, the BiPed will acknowledge other robots while traversing the maze and avoid collisions using its sensors. To learn more about the mission objective you can take a look here. For preliminary maze designs and definitions take a look here.

Project: Level 1 Requirements

By: Jeffery De La Cruz (MST Engineer)

Verified By: Miguel Gonzalez (Project Manager)


Will:

L1-1: Micro FOBO will stand on its own without any physical help.

L1-2: Micro FOBO’s electronic components will be easily assembled and disassembled.

L1-3: Micro FOBO will have 2 legs.

L1-4: Micro FOBO will be a toy robot based on the design of the FOBO by Jonathan Dowdall.

L1-6: Micro FOBO will fit within the classroom cabinets shelves. 28”x13”x14.5”

L1-7: Micro FOBO will utilize a 3DoT board or Sparkfun Pro Micro 3.3V/8MHz.

L1-8: Micro FOBO’s part components will be 3D printed using the material carbon fiber PLA.

L1-9: Micro FOBO will not exceed a print time of 7.80 hours. Upon approval of the waiver.

Shall:

L1-10: Micro FOBO shall not exceed a cost of $250 to construct.

L1-11: Micro FOBO shall be 60% or less of the overall size of Jonathan Dowdall’s FOBO

L1-12: Micro FOBO shall detect intersections in the maze.

L1-13: Micro FOBO shall be able to perform static walking.

L1-14: Micro FOBO shall produce 90 degrees turn.

L1-15: Micro FOBO shall be guided through the maze with the use of the Arxterra application.

L1-16: Micro FOBO shall record the path of the maze.

L1-17: The Micro FOBO shall traverse the maze using the recorded path.

L1-18: Micro FOBO shall be able to traverse cloth, paper, and linoleum materials.

L1-19: The Final Biped shall be completed by May 10th, 2018.

Should:

L1-20: Micro FOBO should step over a square rod 1cm tall, 1 cm wide by 10 cm long

L1-21: Micro FOBO should be able to perform dynamic walking

System/Subsystem: Level 2 Requirements

By: Jeffery De La Cruz (MST Engineer)

Verified By: Miguel Gonzalez (Project Manager)


Will:

L2-1: Micro FOBO will be connected via Bluetooth to the app on an android phone.

L2-2: Micro FOBO dimensions of the robot will need to be small enough to fit in a 4in by 4in box for maze purposes.

L2-3: Micro FOBO will use SG90 micro servos.

Shall:

L2-4: Micro FOBO shall use UV/IR sensors to detect intersections.

L2-5: Micro FOBO shall use the color of the maze to establish if it needs to turn. black (0,0,0) green (0,255,0) for line following.

L2-6: Micro FOBO shall use a battery that outputs 3.7V nominal.

L2-7: The user shall use the Arxterra application to move the robot forward, backward, left, and right.

L2-8: Micro FOBO connectors shall be able to connect and reconnect all the wiring in less than 10 min.

L2-9: Micro FOBO wiring shall be nice and clean with the use of terminal blocks, contact pins, 2.0mm PH series JST connectors, and barrel connectors.

L2-10: Micro FOBO shall play a musical tune when the maze is completed.

L2-11: Micro FOBO shall have indicating LEDs to demonstrate either a left or right turn.

L2-12: The Micro FOBO shall record the path of the robot on the 3DoT board or the Sparkfun Pro Micro 3.3V/8MHz to navigate the robot through the maze.

L2-13: Micro FOBO shall use a 3D printed chassis and leg components.

L2-14: Micro FOBO shall measure within 4.5” x 3.25” x 7.25”.

L2-15: Micro FOBO shall weigh no more than the allocated mass of 460g.

L2-16: Micro FOBO shall detect objects 8 inches from it.

Should:

L2-17: Micro FOBO should be able to see other robots to avoid a collision. The robot will stop completely and wait for clearance. (Ultrasonic sensor)

L2-18: Micro FOBO should take a bow at the end of the maze as a victory celebration.

System Block Diagram

By: Jorge Hernandez (E&C Engineer)

Verified By: Miguel Gonzalez (Project Manager)


After looking at all the constraints and requirements for the robot our group came up with a system block diagram that could help us visualize how the robot’s components interacted with one another. This diagram made it clear to understand where initial designs should be made and provided great insists on some challenges we would have in the future. Below we link the blog post to the system block diagram the group made.

Work Breakdown Structure

By: Miguel Gonzalez (Project Manager & Manufacture)


When working on a team project it’s important to break down the project into general tasks and assign them to team members. Typically a chart is created to easily visualize how the work is divided among team members, this called a WBS (Work Breakdown Structure). Here we link to our post demonstrating and explaining our WBS.

Product Breakdown Structure

By: Jeffery De La Cruz (MST Engineer)

Verified By: Miguel Gonzalez (Project Manager)


Fig.1 Product Breakdown Structure

Based on System Block

Sensor Suite

  • The color sensor will be able to detect colors and its data input range Ex, black (0,0,0) green (0,255,0) for line following.
  • Will be able to see intersection sign on the maze and differentiate its color from the path lines.
  • Shall be able to see other robots to avoid a collision. The robot will stop completely and wait for a command. (Ultrasonic sensor/IR)
  • The robot should have to indicate LEDs to show where the robot plans to make a turn (left or right)

Smartphone App

  • Will allow usage of the app to navigate the robot through the maze through forward, back, left, and right commands.
  • Will record the path of the robot in 3Dot board to navigate robot without the user controlling it.
  • The robot will be connected via Bluetooth to the app on an android phone.

Chassis

  • The wiring for the robot shall be nice and clean with the use of terminal blocks, contact pins, 2.0mm PH series JST connectors, and barrel connectors.
  •  All connectors shall be able to connect and reconnect all the wiring in less than 5 min.
  • Dimensions of the robot will need to be small enough to fit in a 6in by 6in box for maze purposes.

Battery

  • The robot power management system will use two 1000mAh 2S 20C Lipo Pack rechargeable LIPO batteries.

Interface Matrix

By: Jeffery De La Cruz (MST Engineer)

Verified By: Miguel Gonzalez (Project Manager)


After verifying the product breakdown structure we began listing the interfaces for the 3DoT Board that were going to connect to our sensors and motors.

Prototype Fritzing Diagram for Biped

By: Jorge Hernandez (E&C Engineer)

Verified By: Miguel Gonzalez (Project Manager)


With the product breakdown structure and the interface matrix completed we began the prototyping the circuit and making connections to the servos and sensors. The Fritzing application allows a physical breadboard design to be created digitally. By designing a digital version, and verifying its functionality we can have a smooth transition to creating the PCB.

Mechanical Drawings

By: Miguel Gonzalez (Project Manager & Manufacture)


This blog demonstrates the process of developing all the parts for the Micro Fobo and the unique ways we solved issues throughout the building process.

Resource Reports (Power, Mass, Cost)

By: Jeffery De La Cruz (MST Engineer) and Miguel Gonzalez (Project Manager and Manufacturing )


Fig.2 Power Report

Fig.3 Finding the Center of Mass

Summary of Experiments / Rapid Prototyping Completed and Software Tests

By: Miguel Gonzalez (Project Manager & Manufacture)


It has been approximately eight weeks since the start of the semester and most of the first month consisted of mainly research and write-ups. But after the first month, we began experimenting with small components and sections of our BiPed. We started by looking at the legs of our robot as we knew that making the robot walk on two legs was a crucial part of our design. We created a copy of the 2016 Fall ROFI design and just focused on the legs of that robot. This initial design consisted of having 6 servo motors operating the leg and foot. Using the blog post on that robot and using help from projectbiped.com we were quick to get the robot’s leg to move. If you would like to see images and videos of the robot when it’s operating, you can view our drive folder here. In this configuration, the robot’s leg is very robust and can do very intricate movements while maintaining the robots balance. The issue with this design is that nearly 70 percent of all the weight of the robot consists of the legs alone. We knew that if we can decrease the weight on the robot we could have easier walking movements that in theory can speed up its walking speed. Our secondary design for the robot was to reduce the number of servos operating on the legs by only having four servo motors instead of six.

Fig.4 ROFI vs FOBO

Fig.5 Original Size vs Micro Size

This newer design would remove both the knee servo and middle leg servo on both legs. Theoretically, the newer design should remain functional and provide the ability to take longer strides when walking. It is important to note that the designs for the new leg designs have been modeled and 3D printed but the test will take place on March 17, 2018. This experiment will allow us to verify that the legs can perform walking movement and maintain a higher walking speed than the six-servo design.

Concluding Thoughts

Resources

Project Video(To be updated):

PDR: EE400D Design Presentations

Project Libre Excel: Burndown

Verification and Validation Documents: https://www.arxterra.com/spring-2018-project-biped-verification-and-validation-pass-fail-matrix/

Solidworks Files: Micro FOBO

Fritzing Files: Fritzing-20180331T202552Z-001

EagleCAD files (zip folder): Copy of EagleLibraries | 400-D gerber-20180518T192139Z-001 | ServoShield2Eagle-20180518T192149Z-001

Arduino and/or C++ Code:  Walking and Turning | Remote_Control FOBO

Bill of Materials: https://www.arxterra.com/spring-2018-biped-preliminary-budget/ Budget Table pdf

3D print Time: https://www.arxterra.com/spring-2018-biped-3d-print-time/

List of all our blog post: https://www.arxterra.com/news-and-events/members/3dot-robots/biped-generations/biped-generation-5/

Goliath Spring 2018 – Final Blog Post

By: Ernie Trujillo (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

Goliath Team:

Ernie Trujillo (Project Manager)

Ryan Nguyen (MST Engineer)

Tai Nguyen (E&C Software Engineer)

Milton Ramirez (E&C PCB Engineer)

Daniel Guerrero (M&D Engineer)

Introduction

This document provides resources to all major tasks that were completed by the Goliath team in the Spring 2018 semester. It also provides a summary of the objectives placed by the customer and links to other documents on detailed topics.

Executive Summary

Mission Objective

The goal was to redesign the Goliath tank and follow a concept design from the Goliath 303 Tank while retaining the same goal as the Fall 2017 semester. The Goliath Tank needed to navigate through a 2-D maze made from cloth. The first time through the maze the robot is remote controlled through the Arxterra App  while recording every decision made in the maze and the second time it would play-back the unique path that was recorded. The final objective was to test the robot avoidance software of the robot and see how it overcomes having other robots in the way of its path through the maze.

Project Requirements

Work by Ryan Nguyen (MST Engineer)

Level 1 General Requirements

  1. The robot shall be completed by May 15.
  2. The robot that is to be designed shall be done in such a way that it is relatively inexpensive, less than $250, preferably a laser cut model or 3D printable design.
  3. Since robots are to be operating through the maze simultaneously, the design should ensure that collisions are to be avoided in all situations.
  4. When printing 3D models for the project, any prototype print shall obey the 2/2/2 rule and shall take no more than 6 hours in sum. Projects may request a waiver with justification.
  5. Robots shall utilize a version 6 3DoT boards powered by the 3.7V RCR123A battery. Projects may request a waiver with justification.
  6. The robot will be designed in such a way that there are no dangling or exposed wires. Connectors will be used between all electronic and electromechanical components. Jumper wires will not be used, ribbon cables are preferred; the gauge of wires should be consistent with the current.
  7. Good construction techniques: all moving and rotating parts shall use bushing or bearings, hinges shall be interlocking and include a latching mechanism. No gaps shall be greater than 1 millimeter, immediate access shall be provided to all external connectors (USB, switches).
  8. The robot shall record the user’s input and be able to repeat the previous route defined by the user. The software algorithm is defined in 400D E&C lab sequence.
  9. During teaching mode, ArxRobot app via mobile devices shall be used to teach the robot to navigate the maze.
  10. During the playback mode, the ArxRobot app shall transmit live video feed and telemetry to the Arxterra control panel, including battery level.
  11. The Robot disassembly time shall be 10 minutes. Projects may request a waiver with justification. All 3Dot boards will be clear of electronics, motors will be disconnected, all sensors will be disconnected.
  12. Reassembly time shall be 10 minutes. Projects may request a waiver with justification. All teams will be allowed to use a cable tree as well as an assembly diagram as necessary. All robots will be tested after reassembly to confirm its functionality.

Goliath Level 1 Requirements

Project:

L1 – 1 The Goliath will drive on flat surfaces, such as cloth, paper, linoleum.

L1 – 2 The Goliath shall be operational for 1-hour duration.

L1 – 3 The robot shall be a scale replica of a Goliath 302 Tank. The scale factor will be 1:11.5 with a mean

square error (MSD) over all three axis (x, y, z) of no greater than 10%.

L1 – 4 The total cost of the goliath shall be no greater than $200.

L1 – 5 The Goliath shall have easy access to charging and programming hookup.

L1 – 6 Goliath shall house a custom PCB and use control telemetry shall to navigate the maze.

Program:

L1 – 7 The Goliath should make tank noises.

L1 – 8 Goliath shall detect and avoid other robots in the maze.

Goliath Level 2 Requirements

System:

L2 – 1 The mass of the Goliath shall not exceed 400 grams. Goliath L1-3

L2 – 2 The Goliath shall be smaller than 5x4x3 inches. Goliath L1-3

L2 – 3 Goliath shall use IR range finder to detect objects. Goliath L1-7

L2 – 4 Goliath’s final version shall be printed with ABS plastic. General 3

L2 – 5 The Goliath shall be power by a single 3.7v RCR123A battery. General 6

Subsystem:

L2 – 6 Main PCB shall have two UV sensors, UV LED, Gyro, and connectors to range-finder. Goliath L1-6

L2 – 7 Arx-robot App will have different operating control modes and direction pad to control Goliath’s

movement. Goliath L1-6

L2 – 8 Goliath shall have 4 x 10 mm cut out on back of Goliath to provide access to charging and

programming hookup. Goliath L1-5

L2 – 9 The Goliath will not have any electrical parts mounted outside. General Level 1-7

L2 – 10 The Goliath should have a latched lid. Interlocking mechanism. General Level 1-8

L2 – 11 The Goliath shall detect objects 10 inches in front. Goliath L1-8

L2 – 12 Goliath will have all-terrain tracks. Goliath L1-1

L2 – 13 The Goliath shall have 10 gears. Goliath L1-1

L2 – 14 The Goliath shall have 2 motor(s), located in the back of the chassis. Goliath L1-1

System Design

Work by Ryan Nguyen (MST Engineer)

System Block Diagram

Figure 1 – System Block Diagram for the Goliath Tank.

The system block diagram illustrates how components of the Goliath communicate and connect with each other; from the control panel that uses Wi-Fi to talk with the mobile app to the wheels and treads. More detailed specific components such as the HM11 Bluetooth model is added, and various parts on the PCB parts are laid out; more items are expected when the E&C engineer completes trade off studies.

System Resource Reports

Figure 2 – Spreadsheet for expenditures for the Goliath Tank.

Figure 3 – Spreadsheet for the mass of the components.

Figure 4 – Spreadsheet for the power consumption of the components.

These tables represent the three resource reports (Cost,  Mass, and Power) that were made for the Goliath Tank.

 

Manufacturing Design

Work by Daniel Guerrero (M&D Engineer)

Initial Design

Figure 6 – Preliminary sketches for the Goliath Tank.

The initial designs of the Goliath Tank were modeled after the 302 Goliath Tank, however close to half way through the semester the customer suggested that we follow the design of the Goliath 303 Tank.

Rapid Prototyping

Throughout the semester the design of the Goliath Tank made drastic changes. The progression of the design for the Goliath Tank can be researched in the following link:

Final Design

The final design is not a perfect model. There were still modifications that the M&D Engineer could have made, if more time was allotted, to make the Goliath Tank better (such as a design that maintains the treads better). Provided are the STL files to the Goliath Tank that was used on the day of the Verification Testing (day of the final).

Goliath Tank STL Files

PCB Design

Work by Milton Ramirez (E&C PCB Engineer)

In order to make the interior of the Goliath Tank less cluttered a custom PCB was created for the sensors. The components that were designed within the PCB were the I2C expander, two UV Sensors, and the gyro. For further information proceed to the blog post on the system schematic and the custom shield layout:

Provided are also the Eagle files for the Custom Shield PCB:

Goliath Custom PCB

Software

Work by Tai Nguyen (E&C Engineer)

Line Following

Before the robot can navigate through the maze, the first objective that must be accomplished is having it follow a line. Even though UV sensors were used, the IR capabilities were being utilized to follow a black line. For further information on the software application to line following proceed to the following blog post:

Robot Detection

To avoid collisions, the Goliath used a ToF Range Finder that would detect any objects that were in front of its path. The following blog post goes into detail on how the Range Finder works and how collisions with obstacles are avoided:

Final Code

The final code is provided in a zipped folder with all the libraries required and code to navigate through the maze:

Goliath Code

Verification Test Plan

Work by Ryan Nguyen (MST Engineer)

The verification test plans were a was to evaluate how well the final project did in terms of mission and customer objectives. One of the main objectives of the MST Engineer is to create these plans. On the day of the final the tests plans were given to Professor Hill and he would evaluate whether the project passed or failed a given objective. Provided are the Verification Test Plan for Goliath:

Spring 2018 Verification Test Plan V2

 

Lessons Learned

For students that proceed to take this class the following is advice that is offered in order to ensure that the project is successful:

  1. Ask anyone who has taken this class and this will be one of the first things they say, make sure you do research prior to beginning the project. This website has years of knowledge that was done by other students. Utilize it and you will do yourself the favor of saving time. I’ll get into more detail about this point but time is your most valuable resource to this class.
  2. Make sure that prototyping the design begins immediately! The biggest issue that the Goliath team had was that the first fully built tank was not given for the rest of the team to work on until extremely late in the semester. As one would expect, the first design will have serious issues that need to be fixed (For our team it was that the treads were having trouble staying in place). If the first design was completed weeks in advanced then modifications could have been made to resolve the problem.
  3. In terms of 3D printing, make sure that you rely on multiple services to create your prints. Maker’s Society is a great place to start but also see if you can find anywhere else as it does take time to get prints done and the quicker you can receive them the faster the robot can be built.
  4. For the PCB, before sending it to be manufactured double check that every trace on the PCB is mapped correctly and that there isn’t any connection missing. We were unable to use our PCB due to small oversights in the circuit schematics, so make sure multiple people from the team look over the PCB Layout.
  5. Start working on the software early. There is a lot of trouble shooting that goes into writing the software and every time a new component is implemented there is a high possibility that things will not compile.
  6. If the E&C Engineer has not taken EE444 he/she will be at a slight disadvantage. Two students from my section had taken that course the semester prior and it was evident that both were very knowledgeable on how to implement the software and how to tackle the objectives that were placed in regards to navigating the maze. That does not mean it is impossible to be a successful E&C engineer, I believe all people in that position have to follow the same lab sequence that is offered in that class, but you will need to work much harder.
  7. When Professor Hill was talking about how designing the 3DoT board was going he brought up a point that resonates with me still as I write this. For any task, you will give it an expected time to accomplish. Once you have that time you want to double it, then you double it once more and that is close to the real amount of time that it will take to complete that certain task. My point is that this class is not as straightforward as you will map it out to be. Always be prepared for set backs and unforeseen obstacles. Time will go by quicker than you imagine and if you squander it the project may not turn out successful.

 

Project Video

Created by Ernie Trujillo (Project Manager)

More Info

If you are interested in researching further into our project check out the Preliminary Design Review done for the Goliath Tank:

Resources

www.arxterra.com/goliath-fall-2017-final-blog-post/

 

Pathfinder Final Blog Post – Spring 2018

By: Jordan Smallwood (PM)

Approved By: Miguel Garcia (Quality Assurance)


Pathfinder Team:

Jordan Smallwood (PM)

Diane Kim (E&C)

Mohamad Yakoub (MST)

Adolfo Jimenez (Manufacturing)

Executive Summary:

By: Jordan Smallwood (PM)

Mission Objective:

Figure 1: Final Course Outline

The Spring of 2018 Pathfinder will follow the path laid down by previous Pathfinders. The mission will begin in front of the CSULB library where the rover will exit its cocoon state. The rover will then proceed to begin its journey through campus, a 0.09 mile journey to its charging station. There will be 10 predefined GPS checkpoints along the way and the rover will traverse a flight of stairs. Once the rover has arrived at the charging station it will begin to track the sun and provide the Arxterra user with up to date battery level conditions. Specifically the Pathfinder will demonstrate the following:

  • Custom solar panels capable of tracking the sun and exhibiting optimum orientation so that battery charge takes the least amount of time.
  • The rover will be able to enter and exit a cocoon state. The term cocoon state implies that the solar panes will fold up so that in the event of a dust storm the solar panels will not become damaged. This state will be entered if the rover is in launch, a dust storm or whenever the rover is operating over steep terrain.
  • The rover will be able to communicate with the Arxterra app providing information like battery level, panel angles, panel voltages and charging current.
  • The solar panels will have a form factor identical to those of the Spirit and Opportunity Mars Rovers.
  • The rover will exhibit a 6-wheel slip differential for turning and traversing rough terrain. Since the robot will be climbing over random objects, some wheels will not require the same speed as other wheels and this needs to be considered while operating the rover.
  • Demonstration of GPS navigation with obstacle avoidance.
  • The course mapped out by F’16 and S’17 will be the same course for S’18.
  • There shall be no modification to the rover that stands in the way of high desert operation.

Project Requirements:

By: Jordan Smallwood (PM)

Level 1 Requirements:

  1. The pathfinder shall travel a 0.09 mile course. This course includes going up a set of 3 stairs at a 45 degree incline and another set of 3 stairs with a decline of 45 degrees.
  2. Pathfinder should launch from a cocoon state
  3. The Pathfinder should enter and exit the cocoon state by Arxterra app user input.
  4. Pathfinder shall allow the user to enter the “articulate state” program module which should be available once the Pathfinder has exited its cocoon state. This sequence should direct the solar cells at the proper orientation to allow max charge of the battery.
  5. The Pathfinder shall update the user with information about GPS location, battery level and charge current when in the “Articulate state”. The Pathfinder should update the user with panel angles.
  6. The overall solar panel system will be a scale model of the Spirit and Opportunity Mars and Rovers.
  7. No design decision shall preclude operations in a high desert environment. (Amboy, California)
  8. The Pathfinder will use high-side detection and correction. Consequently, wheels under a no-load condition shall be considered and power to that motor shall be decreased.
  9. A 6-wheel electronic slip differential shall be implemented.
  10. The Pathfinder should demonstrate obstacle avoidance while making its journey through campus using the ultrasonic sensors.
  11. Rocker bogie mechanism shall be improved by implementing and operationally verifying a differential gear-box system as opposed to the differential bar.
  12. The Pathfinder shall be designed for easy assembly and disassembly.

Level 2 Requirements:

1.1: The power budget and battery will meet the requirement of the determined course. The actual distance traveled shall be used to verify the requirement.

1.2: In order to travel up these stairs our mass report along with our motor mock up shall verify that this can be accomplished.

2.1: To perform the cocoon state function the solar panels will be mounted to worm gears attached to DC stepper motors to ensure smooth operation.

3.1: The Pathfinder should communicate via Bluetooth with the Arxterra user and should have an interface allowing the user to enter/exit the cocoon state.

4.1: The articulate state module should adjust the positions of the solar cells using a proportional controller.

4.2: The proportional controller should accept the charge rate as an input and should output changes in orientation.

5.1: While communicating with the user via Bluetooth on the Arxterra app the Pathfinder shall respond with packets of information related to this information

6.1: The side and rear panels shall be capable of position orientation to enter and exit the cocoon state and also optimize battery charge.

6.2: The solar panels should enter the cocoon state when the Pathfinder falls.

7.1: These panels will be constructed of aluminum such that the rover can operate in the harsh desert conditions typical of Mars.

8.1: A software program shall be used ensuring that the wheels are spinning at the same rate.

8.2: Shaft/Rotary encoders shall be used to determine the speed of the wheels

8.3: Current sensors shall be used to determine the load on the wheels

8.4: To conserve energy, the rover shall stop rotation of a freely moving wheel using the current sensors

10.1: The rover should not make any attempt to climb an object that it is unable to clear

11.1: The differential gear box will be constructed of three miter gears, three machined shafts, six mounted bearings and shaft collars.

11.2: This mechanism will be mounted on top of the Pathfinder and enclosed in an aluminum box.

12.1: The design of the aluminum box of the Pathfinder shall be designed for easy access to the electrical components.


System Design:

System Block Diagram:

By: Mohammad Yakoub (MST)

Figure 2: System Block Diagram for Pathfinder Project

The system block diagram describes the overall interconnections of all the peripheral systems. At the heart of the system you will find the Arduino Mega which controls virtually every device in the project. This is controlled via the Arxrobot app through bluetooth communication.


Work Breakdown Structure:

By: Jordan Smallwood (PM)

Figure 3: Work Breakdown Structure for Pathfinder Project

The work breakdown structure describes the major responsibilities of each engineer working on the project. The Electronics and Control division has been divided into two main categories, software and hardware. The Manufacturing division was primarily responsible for the overall fabrication of the Pathfinder and detailed SolidWorks model. And finally the Mission, Systems and Test engineer is responsible for the integration of all these different divisions.

 


Product Breakdown Structure:

By: Mohammad Yakoub (MST)

Figure 4: Product Breakdown Structure for Pathfinder Project

 


Resource Reports:

Final Power Report:

By: Mohammad Yakoub (MST)

Figure 5: Final Power Allocation Report

Power Report

 


Final Mass Report:

By: Mohammad Yakoub (MST)

Figure 6: Final Mass Report

Mass Report

 


Final Cost Report:

By: Jordan Smallwood (PM)

The first cost report includes all purchases that were made by our team for our current project. It does not include cost of material that was purchased from previous semesters.

Final Cost Report

The second final cost report includes past purchases from previous semesters that were used in the making of our current design.

Final Cost Report 2

 


Interface Matrix:

By: Diane Kim (E&C)

Figure 7: Interface Matrix describing pin location’s of system and peripherals

The interface matrix describes the various signal locations for the Pathfinder’s system diagram. Having a good description of where signals are coming in and out is extremely beneficial throughout the course of project design. Many times throughout the semester this document will be referred to and when coding this can often solve many problems.


Mission Command & Control:

By: Jordan Smallwood

The Pathfinder is connected to the Arxrobot app via Bluetooth communication. In addition, the Arxrobot app is connected to the Arxterra Control Panel to expand the capabilities of the Pathfinder. This method of controlling the phone that controls the rover is ideal for GPS navigation, telemetry, and video feedback without the need for including additional sensors and devices. More information regarding the interconnections is described here.


Software Design:

By: Jordan Smallwood (PM)

No-Load:

The Pathfinder has been equipped with 6 high-side current sensors capable of detecting current draw up to 5A to each motor. While these sensors are only calibrated for the motors spinning in one direction a level shifter can be implemented such that we can detect up to 2.5A in both directions. These sensors are used to detect whether or not a load is present on the motors. The difficult task is knowing when to turn the motors back on. To do so we had to implement a pulse motor routine that would turn the motors on for a moment and check the current. This was all done with software by inserting a 2-state FSM in a timer interrupt.

Figure 8: No Load FSM

One of the major issues with this technique is that whenever you turn on a motor from an off state the current required to move the shaft is much greater than normal operation. Therefore you have to wait a moment until you can measure the current to allow the motor to stabilize. This technique has been accomplished and more information regarding this concept can be found here.


6 Wheel Electronic Differential:

A six-wheel differential was implemented in software and hardware with the use of pin change interrupts and quadrature hall effect sensors. While pin change interrupts are more tedious to manage, they offer a significant bonus as virtually every pin can be configured to operate in this manner. The Pathfinder will be completing turns as well as traveling over random objects and this is vital to move forward and avoid unnecessary drag on the other wheels. The process involves 6 unique controllers that track a set pulse delay. More information regarding the 6 wheel differential can be found here. And here.


GPS Navigation:

Due to time constraints and non-software related issues, the Pathfinder is currently unable to perform GPS navigation. However, access to GPS information regarding latitude, longitude and heading can be extracted from the Arxrobot application onto the Arduino. Furthermore, these values can be modified to produce distance to checkpoints and required turn. Although this feature is currently not functional it is definitely feasible.


PCB/Hardware Design:

By: Diane Kim (E&C)

Chassis PCB:

Figure 9: Layout of Final Chassis PCB

The final chassis PCB makes the following connections:

  • Motor Drivers (3)
  • Motor Current Sensors (6)
  • Shaft Encoders (6)
  • Ultrasonic Sensors (2)
  • HM-10 Bluetooth
  • LEDs (2)
  • Servos (2)
  • Fan
  • Stepper Motor Driver STEP
  • I2C connection (SDA and SCL)
  • LM2596 Buck Converter

For more information regarding the final chassis PCB please visit this link.


Solar Panel PCB:

Figure 10: Layout of Custom Solar Panel PCB

The solar panel PCB contains the following systems:

  • Current Sensors (6)
  • Stepper Motors (3)
  • GPIO Expander

For more information regarding the solar panel PCB please visit this link


Final Mechanical Design:

By: Adolfo Jimenez (Manufacturing)

Chassis Design:

Figure 11: Final Design of Pathfinder

The final chassis design is similar in nature to previous semesters with the exception of a few major upgrades. The previous design had radial bearings on the rocker mechanism which was not properly installed. We have upgraded the design to include the use of thrust bearings since the load is axial.

In addition to the rocker bearings we have installed a gear-box differential to provide fluid motion transfer from one set of wheels to the other. The previous design involving a differential bar seemed to have many issues that were addressed in previous blog posts.

The new chassis also expands the total room for electronics tremendously. The size of the overall box is 14″ x 9″ x 3″. This is plenty of room for proper wiring and placement of electronics.

More information can be found here. ONCE FINAL DESIGN APPROVED NEED TO INCLUDE LINK


Final Solar Panel Design:

When it came time to design the new solar panels many different ideas presented themselves. We considered opening and closing the solar panels with the use of a winch/pulley system, however the customer did not approve. Ultimately we wend with a worm-gear with DC motor system. The issue with this design is that there is no support for the miter gear on the worm-gear.

For more information please visit this blog post.

 


Verification and Validation:

By: Mohammad Yakoub (MST)

Please refer to the link within the resources section for further information.


Pathfinder Improvements:

By: Jordan Smallwood (PM)

  • Rocker’s are free to rotate about the bogie mechanism with the installation of thrust bearings
  • Gearbox differential allows rocker-bogie mechanism to move the way it was intended.
  • Magnetic hall effect sensors on the motors allow for speed control
  • High side current sensors provide a means of determining load on a motor.
  • Enlarged electronics box provides shelter for delicate electronics that would otherwise be destroyed in a desert environment.
  • DC Fan with filter built into electronics box
  • Quick removal of lid for access to electronics
  • Power distribution system securely fastened to electronics box with in-line fuse
  • Wiring harnesses throughout for a clean design

Experiments Conducted:

  1. Solar Panel Charging
  2. Stepper Motor Study
  3. Motor Mock Up
  4. Solar Panel Trade-Off Study
  5. Buck Converter Efficiency
  6. Ultrasonic Field of View Test

Schedule:

By: Jordan Smallwood (PM)

Figure 11: Schedule for Pathfinder Project

Burndown Chart:

Figure 12: Burndown Chart for Pathfinder Project

The Pathfinder project was one of the largest in terms of what needed to be accomplished and size. Many modifications needed to be made to the Pathfinder before tests could be performed to determine whether or not we would meet our requirements. Towards the end it became more and more difficult to get things done due to the complexity of the remaining tasks which is why you see the slope of the ‘actual’ line going to zero. If you want your project to be successful it is paramount to get the robot up and moving before the semester’s break that way you’ll have plenty of time to make modifications in the last month or so.


Final Thoughts:

By: Jordan Smallwood (PM)

The Pathfinder project will have to wait until another semester to make it’s course through campus going up stairs and following commands from the Arxrobot App. Due to some very unfortunate design flaws the PCB was destroyed and we did not have the time to regenerate a new one. Since the Pathfinder is made of aluminum it is very important to ensure that all electrical systems are insulated.

Our design flaw was without a doubt something you wouldn’t have anticipated. The concept was to mount the Arduino to the Pathfinder chassis to secure the electrical system to the body. What we didn’t realize was that by using metal bolts we grounded the entire chassis. When attaching the battery terminals to the switch, the positive lead was set down for a moment which allowed for a short to take place. Needless to say the PCB didn’t respond well to this high current.

A new PCB will be fabricated and the Arduino will be mounted with plastic to prevent any shorts from taking place.

In the end, the Pathfinder has seen some major upgrades and there is no doubt that this robot will be a great piece of equipment to showcase for the EE department. Future modifications that can be made are:

  • Upgrade the chassis to include housing for micro-sojourners
  • Redesign solar panel folding system
  • Chassis/Panels should be made of lighter material such as carbon fiber

Resources:

  1. PathfinderEagleFiles
  2. Resource Report
  3. Final Arduino Code
  4. Link to Google Drive
  5. Master Test Case
  6. Verification Matrix
  7. Atmel Datasheet
  8. Final Video

Spring 2018: Biped Software Diagrams

By: Miguel Gonzalez (Project Manager & Manufacturing)

Approved By: Miguel Garcia (Quality Assurance)


One of the most helpful things to do before you start writing code is to create a flowchart and a software block diagram. These diagrams will help you understand the overall construction and function of the code. In this blog post, we will be looking at the diagrams our team created to visualize how the Micro FOBO should function. These charts introduce tasks the software must complete reaching mission success.

Related requirements:

Level 1

L1-12: Micro FOBO shall detect intersections in the maze.

L1-13: Micro FOBO shall be able to perform static walking.

L1-14: Micro FOBO shall to produce 90 degree turn.

L1-15: Micro FOBO shall guide the Micro FOBO through the maze with the use of the Arxterra application.

L1-17: The Micro FOBO shall traverse the maze using the recorded path.

Level 2

L2-5: Micro FOBO shall use the color of the maze to establish if it needs to turn.

L2-10: Micro FOBO shall play a musical tune when the maze is completed.

L2-11: Micro FOBO shall have indicating LEDs to demonstrate either a left or right turn.

L2-16: Micro FOBO shall detect objects 8 inches from it.

L2-17: Micro FOBO should be able to see other robots to avoid collision. Robot will stop completely and

wait for command. (Ultrasonic sensor)

L2-18: Micro FOBO should take a bow at the end of the maze.

Software Block Diagram

The software block diagram can be thought of as individual code modules that work together to create the overall software system for the Micro FOBO.

Fig.1 Micro FOBO Software Block Diagram

As you can see in figure 1 the left block represents the “main code” section. In this section, you will find all the functions and call to functions the robot utilizes for the completion of tasks. This section houses the main code that runs in a loop calling on subroutines to make readings or to simply perform a task. The middle section of the block diagram represents all the available “functions/subroutines” the robot has available. Some functions include Walking forward, turning, and taking measurements. It is clearly visualized from the arrow movement that the main code of FOBO has the ability to call subroutines and functions located in the middle section of figure 1. Finally, looking at the right part of the chart we can see the “actions” section which is the code that runs after certain functions are run. For example, if Turning Left is run then the action of blinking the left LED antenna will be performed.

Software Flow Chart

Although the software block diagram is a useful tool for understanding the subroutines and actions of the robot it can still be difficult to use as a template for writing code. For this reason, we make software flow charts. We can use the block diagram above to make the flowchart that you see below.

Fig.2 Micro FOBO Software Flow Chart

As you can see, this flowchart is a visualization of how the code runs showing all it’s decision procedures and actions it takes whether its tests are true or false. Instead of reading the chart from left to right like the previous diagram we read this chart from top to bottom. As we can see the first thing the code will do when starting up is check for a Bluetooth command if not command is present it will proceed to check if the IR sensor is triggered. A yes answer will cause the code to run the “turn” function which causes the program to ask “which direction.” Once instructions are received the program will perform the next action and blink the corresponding LED. If the IR sensor is not triggered then it will check the ultrasonic sensor. If triggered, Micro FOBO will assume there is a robot crossing in front of it so it is instructed to wait until it’s cleared. The program will loop back every 10 seconds to check if the path has been cleared. Once cleared the program will proceed to take a step forward. At every step, the robot will ask itself if it has cleared the maze. If the answer is false then the program loops back up to the beginning. It is quite apparent that by using these two diagrams we can fully understand the behavior of the robot and how its code should be written to produce the desired functions. In the next few weeks, our E&C engineer will be utilizing these diagrams to write the code necessary to have Micro FOBO navigate through the maze and achieve all customer requirements.

References

  1. https://www.arxterra.com/fall-2016-biped-updated-systemsoftware-block-diagrams/
  2. https://www.arxterra.com/fall-2016-velociraptor-w-software-block-diagram/
  3. https://www.arxterra.com/fall-2016-solar-panels-software-block-diagram-update/

Spring 2018 3DoT Hexy: Final System Integration and Test

By: Kris Osuna (Electronics and Control Engineer) & Raymundo Lopez-Santiago (Mission, System, and Testing Engineer)

Verified By: Eduardo De La Cruz (Project Manager and Manufacturing Engineer)

Approved By: Miguel Garcia (Quality Assurance)

Introduction

This blog post covers 3DoT Hexy’s final system and test. Most of the tests were conducted prior do the day of the final (05/15). Tests performed include ultrasonic ranges, light sensor value readings, and arxrobot communication to the pro micro board. Assembly and disassembly were performed on the day of the final.

Update: 05/15/18

The additional test which include the assembly and disassembly were performed. The final time for disassembly was 5 minutes and 10 seconds. The final time for assembly was 7 minutes and 18 seconds. This was timed using a cellphone. Conditions included having the customer present and assembly/disassembly performed by both manufacturing and E&C engineers. Rules and instructions developed for assembly/disassembly can be found below.

Testing

Sensor Testing 

Ultrasonic testing (Parallax Ping) was conducted for the requirement of detecting non-navigable obstacles at a distance of no less than 10 cm and no more than 25 cm at a viewing angle (cone) between 30 degrees and 40 degrees facing forward. As seen in Fig. 1, a test was setup to confirm that 3DoT Hexy can detect obstacles within the defined range and conditions. Apart from the robot stopping when an object was detected, two red LEDs were configured to turn on as an additional indication that an obstacle is detected.

Figure 1: Ultrasonic sensor range detection test. Gif can be found below:

Light sensors: Adafruit Flora Si1145

Three light sensors were used for this project. A test was conducted on a maze provided by the customer. A snip of the maze can be seen in Fig. 1. The test included obtaining IR values when the robot is seeing black lines, white lines, and green lines. The distinguishing of color was big enough that line following should be possible. A limit of 310 was placed in the code. The limit will treat whitespace and green lines the same and will not be affected by it. Values on the whitespace gave a minimum of 331. Values on the black lines gave a maximum of 300. Values on the green lines gave a minimum 322 and a maximum 369.

Figure 2: Placement of light sensors

Figure 3: IR and visible spectrum values recorded with the maze values.

Figure 4: Maze value reading set up.

Arxrobot Communication

As a requirement, the robot shall be controlled remotely via Bluetooth using the Arxrobot phone application. Code tested by the E&C was implemented on the pro micro board. Success criteria were determined to be having the 3DoT Hexy respond to commands from the Arxterra App. I suggest connecting to Bluetooth in an empty space because too many devices try to connect to the app.

Figure 5: A simple LED blink custom command was used to confirm connection to Arxterra App. Gif of the test can be found below 

Conclusion

Most of the test conducted were related to the software and sensors used. All mechanical tests were conducted prior to these tests. The bearings added to the gears helped with the ease of movement with only 3.6 V allocated from the battery. Since we did not have the 3DoT board, all testing was done using a Sparkfun 3.3V 8MHz Pro Micro board.

Fig. 6. All components integrated and working together.

Fig. 7. Originally Hexy would turn around when an object is detected. Gif of the testing can be found below: 

Resources

  1. Ping Code and Wiring
  2. Si1145 Code and Wiring
  3. https://www.arxterra.com/wp-content/uploads/2018/05/Assembly2FDisassembly.docx
  4. https://www.arxterra.com/wp-content/uploads/2018/05/DisguisedBeneficialBrownbear-mobile.zip
  5. https://www.arxterra.com/wp-content/uploads/2018/05/DelayedBigheartedJaeger-mobile.zip
  6. https://www.arxterra.com/wp-content/uploads/2018/05/JaggedOblongBighorn-mobile.zip

Spring 2018 3DoT Hexy: Final Arduino Code

By: Kris Osuna (Electronics and Control Engineer)

Verified By: Eduardo De La Cruz (Project Manager and Manufacturing Engineer)

Approved By: Miguel Garcia (Quality Assurance)

Introduction

The purpose of this post is to share the links for the 3DoT Hexy Code and explain the structure for use in the future. There are two separate codes to be explained. AutoHexy does not use the 3DoT firmware and does not run through the Arxterra app. Arx_Hexy_Automatic does use the 3DoT firmware and was run with the Arxterra app. The 1-to-4 I2C on our custom PCB only had one working channel for some reason, so we used the Adafruit TCA9548A 1-to-8 I2C multiplexer breakout board.

Related Requirements

Level 1 Requirements 

  • The robot will need to navigate remotely through a custom-built maze (built by AoSa image), memorize the path it took, start over, and autonomously travel through the path it took.
  • The robot shall avoid collisions if it encounters other robots while navigating through the maze. This involves detecting the robot, retracing steps back, and moving to a room that allows the other robot to have a safe passage.
  • The robot shall use a v6.43 3DoT board.
  • The robot shall demonstrate the capabilities of the 3DoT micro-controller for DIY hobbyists.

Level 2 Requirements

  • The robot shall use a single RCR123A 3.7 V, 650mA rechargeable Li-ion battery to power the 3DoT board, which will power the drivetrain and all attached peripherals.
  • The robot shall use 3 UV sensors connected to a custom PCB.
  • The robot shall use a HC-SR04 ultrasonic sensor to handle robot avoidance.
  • Ultrasonic sensor shall have a range of 0.5-meter radius to detect and respond accordingly to other robots.

Code Layout AutoHexy

Setup and define – We are using a dual motor driver that needs to have its pins defined. The Arduino Leonardo was used intermittently due to malfunctions of the promicro, so changes in pin definitions had to be made. pingPin is used for the ultrasonic sensor. LeftEye and RightEye are declared on digital pins to be controlled. We are reading from three sensors so each must be declared. tcaselect is used to identify the channels in the I2C.

Figure 1: Declaring pins 

 

Setup – Since we used an eight channel I2C the specific channels that will be used need to be selected and checked for data transmission. If there is no data transmission on the selected channel the program stops here.

Figure 2: Check that selected channel on the I2C are receiving information

Main Code – The main loop calls the functions

Figure 3: Main loop calls the functions

Functions:

clearLED ()

Function turns off the LED eyes.Figure 4: Turns off the eye LEDs

 

Ping ()

This function measures the distance and the only change from the manufacture code made was to detect a certain range. When the robot detects an object 10 to 25 cm away the robots turns the LEDs on and stops the robot from moving until the object leaves. When the object leaves the LEDs turn off and the robot begins walking.Figure 5: If an object is detected in the 10 to 25cm range 3DoT Hexy will turn on its eye LEDs and stop moving until the object is removed

ReadSensors()

Figure 6: This function reads the IR values for the channels being used

 

Decide ()

This function goes through the line following possibilities. The first check is to keep going straight when only the center sensor is on the line and it should go straight. Second check is when the robot is drifting to the right and the left sensor is on the black the robot turns left until the center sensor goes over the black line. The third check runs when the right sensor is over the line and turns right until the sensor get back on the line. The forth check is when the robot is at an intersection it was going to be implemented with the virtual maze but I was unable to implement it in time.

Figure 7: Run through the options of what to do based on the IR values

Code Layout Arx_Hexy_Automatic

The code layout is similar to AutoHexy, but it incorporates the 3DoT training and firmware. I tried to set up a custom command for setting the Ping function but I was unable to get the code to function correctly.

Figure 8: Detect Handler was supposed to have the robot run through the maze autonomously when detect custom command was called.

Figure 9: The blink custom command was used to test arxterra app connection and was going to be used to celebrate completing the maze.

Libraries Required

  1. 3DoT Library
  2. Adafruit Si445 Library

Conclusion

I was unable to get the line following code to function correctly on the arxterra app. The line following on Arduino only worked ok but due to the sensors not fitting correctly in their spot, consistent values were difficult to obtain. The sensors kept moving positions and angles. The blink custom command shows that the handle is correct and is going through, but Detect command does not work for some reason. Our team did not have a dedicated hardware and a dedicated software team member which lead to extra work. I believe if we had another team member we could have gotten the code working.

Resources

  1. 3DoT Arduino Help
  2. Link to Code: Hexy

Spring 2018: Biped Action Code

By: Jorge Henandez (Electronics & Control)

Verified By: Miguel Gonzalez (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)


At first we were given the task to complete a previous ROFI biped. Not knowing how many of the integration systems worked, research was required. Most of the wires were cut from ROFI so this process took around 1 and a half to 2 weeks to even get ROFI functional. Once an Arduino Mega and the shield provided from last semester were connected properly, along with the external power source, it was finally time to have ROFI moving.

Robot POSER, which is a beta robot poser provided from projectbiped.com, allows new action sequences and servo calibrations to be created for ROFI/ FOBO.  The application controls the robot via a USB cable from the Arduino Mega (Uno for FOBO) to a laptop or desktop computer. The folder containing the application also has 3 actions (walk, static walk, and turn right) so you can get the robot moving once it is calibrated. To see us calibrate ROFI click here ROFI Calibration .

Similar steps were taken to get FOBO walking and used a FOBO servo centering program, provided from projectbiped.com, along with the FOBO poser to get our calibrations for each servo. Having our own unique calibrations, we saved a frame action which allowed us to bring Micro FOBO back to its center servos which are listed below.

Fig.1 Action Frame Calibration

FOBO calibration

Walking Action:

The walking action looks like the following, which moved the servos in a walking motion for a continuous loop until asked by the user to stop.

Another action was loaded onto FOBO Poser to make the biped mimic walking. Below is the sequence of the frames as it controlled the servos in 10 frames to adjust it walking while maintaining its balance.

Fig.2 All Action Frames

References

  1. https://drive.google.com/open?id=1tc26z7_5NyqFinNxEK91PzSnA_zeO6-v
  2. https://drive.google.com/open?id=1QH7lymwSedcqScjL0sX_gTmvqSDlX_yu