Fall 2017 – 3DoT Chassis Preliminary Design Document & Preliminary Project Plan

By: Elizabeth Nguyen (Project Manager), Melwin Pakpahan (Missions, Systems, and Test Engineer), Yasin Khalil (Electronics & Control Engineer), Zachary de Bruyn (Electronics & Control Engineer), Railan Oviedo (Design & Manufacturing Engineering)

Preliminary Design Document

Program Objective & Mission Profile

Written by Elizabeth Nguyen

Program Objective

The 3DoT Chassis (the name is expected to be changed) is expected to be 3D-printed as a single assembly, based on the Paperbot. It will be a toy robot with a paper shell that will resemble the mascot of CalState Long Beach (CSULB) Prospector Pete. The robot will be controlled through the arxobot app/control panel. The DC motors (GM6) and the planetary gear system will remain the same as used for Paperbot.

Mission Profile

The 3DoT Chassis will be able to (1) remotely navigate a maze while recording its path (that is determined on the day of demonstration) with its sensor shield and (2) autonomously navigate the same recorded maze path while other autonomous toy robots are present.

Source: Project and Mission Objectives

 

Requirements

Level One Requirements

Written by Elizabeth Nguyen

Program Requirements
  1. The 3DoT Chassis shall be completed by Wednesday, December 13, 2017.
    1. This requirement coincides with the last day of class and this is the projected demonstration date for all toy robots.
  2. The 3DoT Chassis shall cost no more than $200 as projected by the customer.
  3. The 3DoT Chassis will be a toy robot.
    1. This requirement is defined through the customer expectations.
Project Requirements
  1. The 3DoT Chassis shall use a 3DoT Board (based on Project and Mission Objectives).
  2. The 3DoT Chassis shall navigate through a maze with remote control through the ArxRobot App or the Arxterra Control Panel (based on Project and Mission Objectives).
  3. The 3DoT Chassis shall be no larger than 4 x 3.5 x 3 inches.
    1. These measurements were taken at the widest dimensions of the chassis since it tapers at the bottom.
  4. The 3DoT Chassis shall be able to memorize a path through the maze that is taught by the user (based on Project and Mission Objectives).
  5. The 3DoT Chassis shall be able to autonomously travel down the path that was memorized (based on Project and Mission Objectives).
  6. The 3DoT Chassis should be able to navigate the maze and avoid collisions when multiple robots are in the maze.
    1. This requirement is not completely defined because the project managers need to determine a way for the robots to avoid each other during their demos.
  7. The 3DoT Chassis shall have a chassis that is 3D printed.
    1. This is derived from a customer expectation.
  8. The total 3D print time of 3DoT Chassis’ parts shall not exceed 6 hours (based on Project and Mission Objectives).
  9. The main body of the body shall be of one solid piece.
  10. The 3DoT Chassis shall be easy to assemble.
  11. The 3DoT Chassis Paper Shell shall resemble the CSULB mascot, Prospector Pete.
    1. This is a customer expectation.

Level Two Requirements

Written by Melwin Pakpahan

System Requirements
  1. The 3DoT Chassis shall operate for no less than 20 minutes.
  2. The 3DoT Chassis shall have a maximum speed of 19.5 centimeters per second.
  3. The 3DoT Chassis shall have a custom PCB to accommodate for its sensors.
Subsystem Requirements
  1. The 3DoT Chassis shall be powered by a RCR123A Lithium Polymer battery.
  2. The 3DoT Chassis shall use a planetary gear system for mobility.
  3. The 3DoT Chassis shall have a sensor shield on the front.
  4. The 3DoT Chassis shall have a mechanism for counterweight attached to the shield.
  5. The 3DoT Chassis shall utilize two GM6 brushed DC motors.
  6. The 3DoT Chassis shall use a TCS34725 RGB color sensor to navigate the maze.
  7. The 3DoT Chassis shall use a TCS34725 RGB color sensor to detect and avoid other robots in the maze.

Design Innovation

Written by Elizabeth Nguyen

Caster Wheel

During the creativity exercise, our team determined that the caster wheel required a more innovative solution. There was a need to compensate for the uneven weight distribution caused by the smartphone resting in the front. Previous designs have used a simple castor wheel.

Based on the solutions developed from the suggested techniques (Duncker diagrams, different point of views, forced relationships, etc.), we decided not to implement them. Some were not feasible and there were other tasks that required more attention such as the custom PCB for the SAMB11 and the planetary gear system, which will be addressed.

Gear System

In continuation to the mentioned task that is considered urgent, the implementation planetary gear system is a customer expectation and a potential challenge for the team. It is aesthetically pleasing, which is why the gear system must specifically be planetary; however, this design did not work with a wooden chassis due to friction.

What has changed was allowing COTS gears since they cannot be 3D-printed concisely nor have a strong structure to work. Instead, the focus for the team is to determine an innovative design for the gear system while appearing planetary.

The challenge also discovered was for a true planetary gear system, torque comes from the middle gear, which then rotates the smaller planetary gears, allowing the wheel to turn. However, with the current chassis design, torque comes from the top gear, which will turn the rest of the gears.

Gear studies will be performed.

Custom PCB to replace 3DoT Board

A challenge provided for the team is to design and assemble a custom PCB that will replace the 3DoT Board that is used to power and control the robot. The ATMega32U4 will be replaced with the SAMB11 and there will be an implementation of the IFA on the SAMB11 Board as discussed below.

ATMega32U4 replaced with SAMB11

The current 3DoT Board v454 has components that are incorporated separately on the PCB as opposed to the SAMB11 where those components are built-in [1]. Benefits from replacing the chip would include less power for the SAMB11 because less components would be required ont he PCB and would not require the HM10 to be implemented onto the board because bluetooth is also integrated.

Implementation of IFA on SAMB11 board

Because of the replacement of the ATMetga32U4 with the SAMB11, an antenna is required for communication purposes between the users (our team) and the board itself. An Inverted-F Antenna was chosen and will communicate with the board using 2.4 GHz.

References:

[1] Design Guide of SAMB11

 

Systems/Subsystem Design

Product Breakdown Structure

Created by Melwin Pakpahan

 

Electronic System Design

System Block Diagrams

Created by Zachary de Bruyn

System Block Diagram for 3DoT Board

 

System Block Diagram for SAMB11 Board

 

Interface Definitions

3DoT Interface Definition

SAMB11 Interface Definition

Mechanical Design

Written by Railan Oviedo

For this version of the 3DoT Chassis, the customer’s biggest requirement is to have it 3D-printed as a singular piece. This varies from the previous iterations, as they had each required an assembly of the chassis first. In order to realize this, I will have to adjust the previously made 3D modeled parts and combine them in such a way that the entire chassis can printed at once.

To avoid long print times—and thus a higher chance of an error while printing—the chassis’ front and back will have to be perforated so as to avoid printing unnecessary space. To comply with the boundaries made by the Prospector Pete paper structure, the Chassis size will not exceed measurements of 4 x 3.5 x 3 inches. Furthermore, the primary method of movement will be realized through the use of a planetary gear system. The inner workings of the Chassis will remain relatively the same from the previous plastic design. That is, there will be grooves to hold in the 2 DC motors and the 3DoT board, which will have a battery and circuitry for the robot placed onto it. The final aspect of the 3DoT Chassis will involve a shield placed in the front in order to allow for placement of sensors and navigation along with a castor wheel for counter-balance purposes. This shield will also serve as a stand for a phone that can be placed on the chassis.

The following images show what the general shape of the chassis looks like from a diagonal view, side view, and front view:

3DoT Chassis Diagonal View

3DoT Chassis Side View

 

3DoT Chassis Front View

 

Design and Unique Task Descriptions

Manufacturing

3D Printed Chassis

Written by Railan Oviedo

As previously stated, a singular design of the chassis can be modeled through referencing the previous models made by prior teams that worked on the 3DoT. The major goal for the completed 3D chassis design is to be able to be printed in less than 6 hours, so as to ensure that the printed chassis will not experience structural failures.

Because this version cannot be disassembled, the issue of placing the motors in comes into play. To circumvent this problem, I am planning on creating rectangular holes on the front and back of the chassis in order to easily insert the motors onto their slots. This solution would not only resolve the motor placement issue, but also reduce the necessary printing time for the chassis.    

In regards to the planetary gear system, it is imperative to make sure the gears can fit within the primary wheel’s 5.5 cm diameter. The current plan is to create a triangular gear train with 3 large gears that are each attached to a smaller gear that serves as the center focal point. This setup should result in little to no loss of rpm between the large gears, as they are the ones that will be connected to the primary wheel.

An expected completion date for a 3D model design is October 25, 2017.

 

Electronics & Control

Inverted-F Antenna

Written by Zachary de Bruyn

The 3DoT Chassis team will be implementing two varieties of “3DoT” boards. One board will consist of the heritage 3DoT ver. 4-54 board which utilizes the ATMega32U4. In order for the heritage 3DoT to communicate with peripheral devices, an additional component, the HM10, is needed to provide a 2.4GHz link between a transmitter (XMT) and the HM10. The second board, however, utilizes a SAMB11 SoC. Within the SAMB11 is the BLE device necessary to communicate at 2.4GHz, but requires the design and implementation of an antenna external to the SAMB11.

Implementation of an antenna design is dependent on the frequency at which it is to receive. Therefore, in order to implement a PCB antenna which utilizes the 2.4GHz, which bluetooth is dependent on, we are limited to only a couple of antenna varieties [1]. In short, the Inverted-F Antenna (IFA) was chosen for a couple of reasons: 1) It is similar to the design of the antenna on the HM10, which is a proven concept; 2) the IFA is isotropic allowing for reception from a wide range of three-dimensional locations, and 3) it allows for 2.4GHz reception. The expected completion date is November 1, 2017.

References:

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

[2] http://www.ti.com/lit/an/swru120c/swru120c.pdf

 

Color Sensors (TCS34725)

Written by Zachary de Bruyn

It is the goal of the 3DoT team to implement the Light-to-Digital Converted (RGB Sensor) in order to read the different colors that are imposed on the maze/roadway in order to navigate the maze autonomously. The benefit of using the color sensor is that it will allow the toy robot to use the color values it evaluates to maintain the direction on the maze. We can then implement a controlled response that will allow the toy robot to correct its direction based on interference from other undesirable colors. There is an expected completion date of November 15, 2017.

References:

[1] https://cdn-shop.adafruit.com/datasheets/TCS34725.pdf

 

SAMB11

Written by Yasin Khalil

The SAMB11 will be implemented in custom PCB to replace the heritage 3DoT ver. 454 board that utilizes an ATMega32U4.

The SAMB11 will provide all of the base features as the ATMega32U4 in the original 3DoT board. These features include a dual H-Bridge, sensors, power management (battery, usb, etc.), servo’s, and DC motors. There will also be correlating headers to that of the 3DoT to allow for seamless integration with past projects.

An expected completion date will be November 15th, 2017.

SAMB11 Reference Design Schematic


Preliminary Project Plan

Work Breakdown Structure

Created by Elizabeth Nguyen

Project Schedule

Created by Elizabeth Nguyen

Top Level Schedule

System/Subsystem Level Tasks

Project Burndown

The current graph shows a burndown from a top level view; however, it is difficult to ascertain the ideal burndown. It will be updated with the correct dates as well.

System Resource Reports

Created by Melwin Pakpahan

Project Cost Estimates

Written by Elizabeth Nguyen

A budget of $200.00 was projected by the customer. It is difficult to ascertain an estimated budget due to variances in services such as 3D printing and PCB board assembly. However, at least 50% of the budget is estimated to go towards physical parts and the rest of the budget will be allocated towards services.

Fall 2017 BiPed: Preliminary Design Document

By:

Piyush Jain (Project Manager)

Zachary Bruyn & Yasin Khalil (Electronics & Controls)

Natalie Arevalo (Manufacturing)

Melwin Pakpahan (Missions, Systems, & Test)

Program Objective

By: Piyush Jain (Project Manager)

The objective of Project BiPed is to design and manufacture a miniature bipedal robot. The BiPed shall incorporate a Theo Jansen leg design, use a single DC motor and mini servo for walking and turning, and shall use a similar joint mechanism as the 2017 Spring Velociraptor [1].

The model of the BiPed shall use the same principle mechanics as Theo Jansen models, with the design inspired by the 2017 Spring Velociraptor. The difference between the design shall be:

  1. The head shall be removed and the tail replaced altogether with a different system of allocating the mass to retain a proper center of mass.
  2. Replace clunky hip design with something more compact which has a smaller turning radius.

Mission Profile

The mission of Project BiPed is to design the BiPed to navigate a predesigned maze [1]. 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.

References:

[1] http://web.csulb.edu/~hill/ee444/2%20The%20Mission.pdf

Requirements and Verifications

Program Level 1 Requirements

By: Piyush Jain (Project Manager)

  1. The BiPed shall be finished by Wednesday, December 13, 2017. [1]
  2. The BiPed shall not exceed a budget limit of $250.00
  3. The BiPed shall be a toy robot.

Project Level 1 Requirements

By: Piyush Jain (Project Manager)

L1-4: The BiPed shall navigate the maze with user-defined inputs.[2]

L1-5: The BiPed shall memorize said user-defined path and navigate it autonomously.

L1-6: The BiPed shall navigate the maze in seven minutes or less.

L1-7: The BiPed shall navigate the maze without colliding into other robots.

L1-8: The BiPed will be controlled by a 3DoT board.

L1-9: The BiPed will be able to walk on cloth, linoleum, and paper.

L1-10: All electronic components shall be able to be disassembled and reassembled within 20 minutes.[3]

L1-11: All 3D printed robot components shall be printed in less than 6 hours, with no single print session taking longer than 2 hours.[3]

L1-12: Use the Theo Jansen Design for its leg mechanism.

References:

[1] http://web.csulb.edu/gobeach/depts/enrollment/dates/registration.html

[2] http://web.csulb.edu/~hill/ee444/2%20The%20Mission.pdf

[3] http://web.csulb.edu/~hill/ee400d/Project%20and%20Mission%20Objectives.pdf

 

System/Subsystem: Level 2 Requirements

By: Melwin Pakpahan (Missions, Systems, & Test)

L2-1: Operate using the Arxterra Android/iPhone application. This includes navigating the maze, with and without user input, as well as turning and walking.

L2-2: Have Bluetooth communication which will sync with the Arxterra Android/iPhone application

L2-3: Be integrated with all the appropriate libraries to communicate with all electronic devices.

L2-4: Use a gyroscope/accelerometer to help navigate its way through the maze.

L2-5: Use a proximity sensor to detect and avoid other robots in the maze.

L2-6: Design the BiPed’s feet size to be approximately 3″ by 2.5″.

L2-7: Design the BiPed’s hip size to not exceed 3″.

L2-8: Design the BiPed’s center of mass shifting system to not exceed 5″ in length and width.

L2-9: Choose a motor which will provide enough torque to support the weight of the BiPed.

L2-10: 

L2-11: Design the BiPed to be less than 1.5 pounds.

L2-12: Be powered by one RCR123A Lithium Polymer Battery which will operate for a minimum of 10 minutes before recharge

L2-13: Utilize one motor for mobility

L2-14: Utilize one mini servo for turning

L2-15: Be wired in a manner which is professional and shall not interfere with when navigating the maze

L2-16: Have two leaf springs on each foot, for stability and flexibility of the feet. [1]

 

Design Innovation

By: Piyush Jain (Project Manager)

Working from the previous semester’s built BiPed chassis, the team came up with potential problems we might encounter. With respect to the customer’s demands, our main problems were turning the Biped, while maintaining a small turning radius, and the static walk, with the feet in close proximity, all while maintaining a proper balance for the BiPed. We decided we would focus on turning the BiPed as that is the biggest challenge. From our creativity exercise, we surmised different methods of turning including : having a 3″ or less turning gears for the hips, having a joint system similar to humans, and removing the turning gear all together and attaching wheels to legs to drive the BiPed through the maze. The first two methods were thought up during the brainstorming approach, while the last one was thought up during the attritube listing. After going over all our options, we decided to design a turning gear which will be less an 3″ because that will give us the greatest control in how the BiPed turns.

 

System/Subsystem Design

Product Breakdown Structure

By: Piyush Jain ( Project Manager)

Power

The Biped shall be powered by a singular portable CR123A Lithium Polymer Battery. The battery shall power the 3DoT board, 1 DC Motors, 1 Servos, I2C, and the Accelerometer/Gyroscope.

Actuator

The actuators for the BiPed are 1 DC Motors and Servos. The DC Motor will control the leg movement for walking, while the servo will control the turning mechanism.

Communication

The Software for the BiPed will be in C++ and written in Arduino sketch. The code shall control the motor functions and communicate with the Bluetooth module. The module will be controlled via the Arxterra control panel, synched to an Android or iPhone.

Manufacturing

With the chassis prebuilt, we will focus on creating an optimal design for the hip and feet. The hip shall be able to turn with a small turning radius, to fit within the parameters of the maze, while the feet shall be designed to stabilize the structure. In addition, the center-of-mass distribution shall be manufactured as to maintain a center of balance when walking and turning.

PCB

Our design will incorporate two PCB boards. The first will be the 3DoT board, provided by Professor Hill, which will contain the microcontroller and shall control the servos and motors. The second will be the custom PCB board which shall control everything else.

Electronic System Design

System Block Diagram

By: Zachary Bruyn (Electronics & Control)

 

The Microcontroller has inputs of the battery and input sensors. The battery shall power the BiPed and the Input Sensors; accelerometer/gyroscope and proximity sensor help to navigate the BiPed thru the maze. The Actuators; DC motors and servos help to physically move the BiPed. The communication device includes the Arxterra application, control panel, Android/iPhone, and Bluetooth device give the user the ability to control the BiPed.

Interface Definition

By: Melwin Pakpahan (Mission, Systems, and Test)

The interface definition shown below defines the pins of the ATmega32U4. The microcontroller has a modest selection of programmable pins to configure. In the future, trade-off studies will be conducted to determine which resources would best suit components and how to configure them accordingly [1]

 

Note: The interface defintion will be provided by October 11th.

 

 

 

Reference:

[1] https://www.arduino.cc/en/Hacking/PinMapping32u4

Mechanical Design

By: Natalie Arevalo (Manufacturing)

The overall design of this semester’s BiPed project can be broken down into four major sections: feet, legs, hips, and center-of-mass shifting mechanism.

The project as a whole can be seen as an iteration of the Spring 2017 Velociraptor project or modification of the Velociraptor project into a BiPed. As a result, the design of the BiPed will be kept as top-heavy however the head-tail component of the velociraptor will be eliminated. Although the body of the BiPed will be kept heavy to keep its moment of inertia small, the weight will be kept confined to the center-of-mass shifting mechanism as well as the servos and motors. In addition, stability in the legs and feet will be increased by using different materials as that of the previous project for the feet as well as by making the feet bigger to better distribute the weight along to using different springs.

Feet

The size of the feet will be increased so that the weight of the top-heavy robot can be better distributed as it’s walking. Additionally, the shape of the feet was also modified to minimize the amount of material to be used in the manufacturing. Since most of the weight of the robot will be exerted on the corners of the feet, just like how the weight of humans is placed on the toes and heels of the foot, the shape was kept with four major corners.

Back of envelope design

A trade-off study in conjunction with a simulation in SolidWorks will be later conducted to determine which design will work the best for the BiPed. Furthermore, the feet will be incorporated into the BiPed so that they can hinge as the robot takes a step. To increase the stability of the feet and therefore the ankle part of the robot, a leaf spring will be used in place of a traditional spring. The leaf spring will provide the better stability while still maintaining enough flexibility for the foot to flex at every step taken.

Legs

The leg design from the Spring 2017 Velociraptor project will be kept the same. The design used previously is the linkage system found in the Theo Jansen Walking Biped. The linkage system already mimics the kinetics behind walking. Furthermore, the design eliminates the need for taking into account the hinge movement of the knee since the leg rotates at the hip and creates that movement on its own. 

Leg Design Model from Wiki [1]

Reference:

[1] https://en.wikipedia.org/wiki/Jansen%27s_linkage#/media/File:Jansen%27s_Linkage.svg

Hips

 The hips as a whole are being made smaller in width so as to make them have a tighter look them. This is going to be accomplished by making gears in the hips that allowed the velociraptor to turn have a smaller radius. Additionally, the space between the universal joint and the rotating disk of the hip/leg will be made much smaller. With these two modifications, the hips will be made smaller in diameter which will decrease the distance of rotation during turning as well as decrease the time it takes the robot to turn and therefore navigate the maze. A quick Solidworks model is provided below based on preliminary talks on the optimal design.

Center-Of-Mass Shifting Mechanism

In order to modify the velociraptor design into a BiPed, the head-tail component was completely eliminated. As a result, a center-of-mass shifting mechanism had to be created in order to shift the center of gravity of the BiPed as it is turning so that the toy will not fall over during this motion. The inspiration for the mechanism came once again from the Theo Jansen Walking Biped. The weight shifting mechanism used in this robot can be seen here:

Essentially, this mechanism would be implemented in an automated version instead of a purely mechanical way. A weight will be placed as part of the body of the robot that will be slowly shifted by a motor to the opposite side of the pivot point of the BiPed as its turning. The modeling and simulation of this mechanism will be done in the future.

Design & Unique Task Description

By: Piyush Jain (Project Manager)

The BiPed shall incorporate a single 3.7v battery which shall power the BiPed through the three maze trials. The battery will be able to be recharged in between the trials. The BiPed shall use one mini servo and one DC motor to help turn and perform a static walk. The turning mechanism shall employ a small turning radius. The static walk shall ensure that the feet are kept in close proximity.

BiPed Tasks

  • Conduct trade-off study to choose the optimal DC motor and servo for given parameters. – October 11th
  • Create the fritzing diagram to test the breadboard. – October 10th
  • From the fritzing diagram create PCB on Eagle CAD. – October 16th
  • Using Arduino IDE to create control algorithm for the servo and DC motor – November 29th
  • Design Center of Mass part to maintain balance during walking, turning and stopping. – October 29th
  • Design lightweight and efficient models for the legs and hip. – October 15th
  • Configure proximity sensor to detect other robots while traversing the maze. – October 6th
  • Create Interface Diagram which is compatible with both 3DoT chassis and BiPed. – October 11th

 

Work BreakDown Structure

By: Piyush Jain ( Project Manager)

The Work Breakdown Structure displays in an easy to read manner for the tasks which need to be completed by the respected division engineers. It details the kind of work which has to be done, moving forward, in order to have a successful BiPed by December 13, 2017. The tasks were derived from the Lv 1 requirements agreed upon by the customer.

 

Project Schedule

By: Piyush Jain (Project Manager)

The Project Schedule details the project timeline from a Top-Level/Subsystem Level perspective. The Top Level consists of four main sections; Planning Phase, Design Phase, Assembly Phase, and Project Launch. These four sections help to guide the project towards mission success by breaking the work down into realizable goals.

 

The System/Subsystem Level was designed to complement the Work BreakDown Structure. It details the specific work which needs to be done by each engineer in their specific division. It allots specific time to each task such that the project will be completed by December 13, 2017. It is broken down into the Manufacturing, MST, and E&C division.

Top Level Schedule

System/Subsystem Level Tasks

 

 

 

 

Burn Down

By: Piyush Jain (Project Manager)

The Burn Down Schedule shows the amount of work needed to be completed in order for the mission to be a success. The blue linear line shows the ideal schedule for the amount of work per week.  The orange line indicates the actual work to be done. As shown, the work increases in loads as the semester progresses.

System Resource Reports

By: Melwin Pakpahan (Missions, Systems, & Test)

The Lv 2 requirement for the BiPed is to be under 850 grams or roughly 1.5 pounds. This was selected so the BiPed would be able to traverse the maze in a timely manner. A rough mass report was generated to guide us to hit our Lv 2 requirement. According to this report, we are well under the 850 grams. Our biggest item of uncertainty is the frame of the BiPed. It is estimated to come in at 300 grams, which is 200 grams less than the previous semesters’ design.

Project Cost Estimate

By: Piyush Jain (Project Manager)

The main program requirement for this BiPed is that it shall not exceed $250.00. A project budget cost was formulated with this requirement in mind. As seen by the image below, we are well below the limit of $250.00. We are able to reduce the cost of this project by obtaining several times from Hill, including the DC motor and mini servo. Also, the sensors decided will be of low cost and optimal performance. The main cost of the project will be the frame of the BiPed because we decided to incorporate a more compact, yet sturdy design. The item of most concern is the custom PCB. Even with a $10 estimate, based on a quick research, we will need to conduct a more in-depth research as to which companies can provide us a high quality, low-cost single board.

 

ModWheels Preliminary Design Document

By: Lucas Gutierrez (Project Manager)

 

ModWheels Team Members:

Project Manager: Lucas Gutierrez

Mission, Systems, and Test Engineer: Andrew Yi

Electronics and Control Engineer: Matt Shellhammer

Design and Manufacturing Engineer: Adan Rodriguez

 

 

Program Objectives / Mission Profile

By: Lucas Gutierrez (Project Manager)

Objective

ModWheels is a toy car that will navigate a multi-colored 2D maze using the Arxterra App for remote control.  The initial phase consists of having the toy car navigate the maze with user input.  ModWheels will then memorize the route taken during the initial phase and will be able to autonomously navigate the maze for the second phase.  Another rule of the maze will be to detect other robots and avoid collision.  These are the objectives stated by the customer.

ModWheels toy car is a new project within The Robot Company.  The modular design comes from the changeable paper overlay, allowing the user to swap out to their preferred design.  Color sensors will be used to detect the walls of the maze, keeping the toy car within the confines of the maze hallways.  To avoid collision, ultrasonic sensors will be used to detect the other robots within the maze.  Infrared sensors will detect the black lines in the maze indicating intersections.

Requirements

By: Andrew Yi (Mission, Systems, and Test Engineer)

Program Level 1 Requirements

L1-1: ModWheels shall be completed by Wednesday, December 13th, 2017.

L1-2: ModWheels will be a toy robot.

L1-3: ModWheels shall cost no more than $200.

Project Level 1 Requirements

L1-4: ModWheels will use a 3DoT board.

L1-5: ModWheels shall use a peripheral custom PCB connected to 3DoT board.

L1-6: ModWheels will be able to be controlled through the ArxRobot App or Arxterra Control Panel.

L1-7: ModWheels shall navigate a multi-colored 2D maze.

L1-8: ModWheels shall stop when another robot has been detected within a 1.5 foot radius ahead.

L1-9: ModWheels should be able to avoid collisions with other robots operating within the maze.  

L1-10: ModWheels shall provide video feedback through a smartphone placed on the toy car.

L1-11: ModWheels shall weigh no more than 500 grams.

L1-12: ModWheels shall be able to memorize a path through the maze taught by the user.

L1-13: ModWheels should be able to travel down the memorized path autonomously.

L1-14: ModWheels should be able to adopt an electronic differential with dual rear motors.

L1-15: ModWheels should be able to adopt a slip differential with dual rear motors.

System & Subsystem Level 2 Requirements

L2-1: ModWheels will have a 3DoT board mounted on the chassis of the ModWheels toy car, as defined by L1-4.

L2-2: ModWheels shall use 2 color sensors to detect the walls within the maze so that it can keep itself within the confines of the hallways, as defined by L1-7.

L2-3: ModWheels shall use the ultrasonic sensors to detect other objects 1.5 feet in front of the toy car, as defined by L1-8.

L2-4: ModWheels will be controllable through Arxterra App using the HM-11 Bluetooth module on the 3DoT board.  The Arxterra App has a graphical user interface (GUI) that allows control of the toy robot, as defined by L1-6.

L2-5: ModWheels should have an area for a smartphone to be placed onto it.  The phone should have a periscope attachment on its camera and will provide live feed video via the Arxterra App, as defined by L1-10.

L2-6: ModWheels shall navigate a maze autonomously after it has cleared the maze with user input.  The autonomous route shall follow the original route without user input, as defined by L1-12.

L2-7: ModWheels will be a remote controllable toy car with a paper shell overlay. The paper shell overlay gives the ModWheels its customizability, as defined by L1-2.

L2-8: ModWheels should use the ultrasonic sensor to reroute themselves if another robot is approaching it head on.  When oncoming traffic is detected, ModWheels should direct itself closer towards a wall to allow the oncoming robot to pass, as defined by L1-9.

L2-9: ModWheels shall use a custom PCB to control the ultrasonic, infrared, and color sensors.  This PCB shall be connected to the 3DoT board aboard the chassis, as defined by L1-5.

L2-10: ModWheels shall use 2 infrared (IR) sensors to detect the black lines in the maze that indicate intersections, as defined by L1-7.

L2-11: ModWheels shall stop when another robot is detected to be 1.5 feet in front of the toy car, as defined by L1-8.

L2-12: ModWheels shall cease all motor functions when another robot is detected 1.5 feet in front of it.  It shall resume resume normal operations after the robot has left the detection area, as defined by L1-8.

Source Material:

  1. ModWheels Requirements

 

Design Innovation

By: Matt Shellhammer (Electronics and Control Engineer)

Creative Design

  • Rules of the maze.
    • Navigating the maze with other robots traveling through at the same time across many various paths has proved to be a very elaborate ConOp. One possible solution for this problem, discussed during the forced relationship and dunker diagram activities, is creating a specific rules of the maze that will be followed by all robots in the maze to ensure that no robots collide. To establish the rules of the maze our project manager is speaking with the other project managers and trying to agree upon a standardized set of rules for the maze.
  • Able to download additional maze maps quickly.
    • This solution came about from the forced relationships technique trying to force a bookcase onto the ModWheels car. This brings up the task of being able to remotely drive through the maze using the Arxterra app and then being able to then repeat that path autonomously. Doing so, after changing the maze in ModWheels memory it can quickly and easily memorize and follow new mazes and routes.  
  • Sense other robots within the maze to avoid collisions
    • Yet again, during the dunker diagram activity, one of our big concerns was navigating the maze while other robots are also within the maze. Another technique for avoiding other robots within the maze was to add a sensor, such as an ultrasonic sensor, to use to detect and avoid obstacles within the maze. We will be using an ultrasonic sensor on ModWheels to achieve this awareness.
  • Making turns within the maze
    • In a maze, making accurate turns is something of great importance, since a poor turn can cause you to veer off the desired path. Two different possible approaches to this problem were discussed. The first approach discussed was to design a car that has wheels that can rotate 360 degrees allowing the car to never have to turn, the wheels will rotate and the car will stay in place. Since the ModWheels chassis relatively fixed, this approach isn’t really viable, however we did discuss another more possible approach, using encoders. Both of these approaches were a result of the attributes listing creative solutions activity.
  • Navigating within the maze
    • To navigate throughout the maze there must be certain sensory devices on the vehicle that allow it to be aware of its surroundings. The solutions developed to help ModWheels be aware of its surroundings is IR and/or color sensors to help detect the rooms of the maze. These sensors could also later be used as an additional tool to gather information when making a turn within the maze.

Source Material:

  1. ModWheels Creativity Presentation

 

Systems/Subsystem Design

By: Andrew Yi (Mission, Systems, and Test Engineer), Matt Shellhammer (Electronics and Control Engineer), and Lucas Gutierrez (Project Manager)

Product Breakdown Structure

By: Andrew Yi (Mission, Systems, and Test Engineer)

The ModWheels car is broken into 6 sections for the Product Breakdown Structure (PBS).  The visuals consist of a smartphone with periscope attachment feeding live video back to the user.  The motors, wheels, and servo are the main parts of the mobility of the toy car.  Bluetooth and the Arxterra app allow for mobile control of the toy car.  The color and ultrasonic sensors will aid in detecting walls (color) and robots (ultrasonic).  The paper overlay and 3D printed plastic allow for customization of the ModWheels toy car.  A singular 3.6V RCR123A battery will power the ModWheels car and its peripherals.

 

Electronic System Design

System Block Diagram

By: Andrew Yi (Mission, Systems, and Test Engineer)

 

The System Block Diagram (SBD) gives a visual of how the different components of a system are connected.  The motor drive on the 3DoT will power the dual RWD motor, which in turn controls the rear wheels.  The color sensors on the custom PCB assist in wall detection (in maze) and in detecting other robots within the maze.  A periscope will be attached onto the camera of a smart phone and placed on the ModWheels car.  This will give live feed video back to the user.  The servo allows for turning of the front wheel and controls the steering of the toy car.

 

Interface Definition

By: Matt Shellhammer (Electronics and Control Engineer)

To know how all of the external components will interface with the 3DoT board the table has been created to know what connections will be required for each of the individual components. This table can then be used to configure the interface matrix between the 3DoT board and the external components.

Mechanical Design

By: Lucas Gutierrez (Project Manager)

This Illustrator file shows the first and foundational model to which ModWheels will develop from.  This two dimensional vector file is converted to a .dxf file which is readable by Laserworks, a software interface for the Kaitian laser cutting and engraving machine.  Once correct settings in Laserworks are enabled, optimal settings for a certain material, the laser cutting and engraving machine cuts and engraves the material (1/8″ 3-ply birch) from which the car can be assembled.

Design and Unique Task Description

By: Matt Shellhammer (Electronics and Control Engineer)

Electronics and Control

  • Trade study of various ultrasonic sensors to determine the best fit for our application.
  • Trade study to determine if we tune two separate motors to drive straight at 40 percent power, will they continue on that same path when the power to the motors is increased (e.g. 50 percent, 60 percent, 70 percent, etc.).
  • Trade study to test maze configurations (1 to 4 cells) using the 3DoT board, and determine the optimal hedge distance and ideal sensor layout.
  • Perform a power system analysis to lay out a power budget for our system (determine current draw for all of the components).
  • Determine configuration to be used for I2C communications.
  • Create Fritzing diagram for custom PCB.
  • Customize Arxterra app / dashboard for specific ModWheels applications.
  • Breadboard testing of turning mechanism & sensors.
  • Determine how sensors will be used for navigating the maze (e.g. line follower, wall follower, room detection).
  • Develop software for: room detection, path memorization, autonomous navigation of the maze, etc.

 

Manufacturing

  • Create Solidworks model of ModWheels chassis from the current 2D model of the ModWheels chassis.
  • Design method for mounting sandblaster front wheels chassis and servo onto the current ModWheels chassis.
  • Design method for mounting PCB and sensors onto the current ModWheels chassis.
  • Design cell-phone mount for ModWheels chassis.

 

Preliminary Plan

By: Lucas Gutierrez (Project Manager)

ModWheels Team Members:

Project Manager: Lucas Gutierrez

Mission, Systems, and Test Engineer: Andrew Yi

Electronics and Control Engineer: Matt Shellhammer

  • Fritzing Diagram
  • Electronic Motor Study
  • Printed Circuit Board (PCB) Design & Test
  • 3DoT Firmware

Design and Manufacturing Engineer: Adan Rodriguez

  • Eagle CAD for PCB layout
  • SolidWorks for ModWheels 3D model
  • Manufacture Chassis, 3D printed parts, and laser cut parts
  • Assemble ModWheels

Work Breakdown Structure

By:

Project Schedule

By: Lucas Gutierrez (Project Manager)

Top Level Schedule

This layout provides the layout of due dates for the ModWheels project.

System/Subsytem Level Tasks

This layout provides the layout of due dates and assignments for engineers for the ModWheels project.

BurnDown Schedule

This layout provides the burn down for the ModWheels project.

Systems Resource Report

By: Andrew Yi (Mission, Systems, and Test Engineer)

Power Allocation Report

The power report is an overview of the power requirements of each physical component.  The MST team is currently working with Professor Hill to finish the power chart for the 3DoT board.  Once that task is finished, testing can begin on components to get test data.

Mass Allocation Report

This report shows the mass of all the physical components used in the toy robot.  There is quite a large amount of contingency because the rules of the maze has not been defined yet.  Once those are defined, then the correct amount of sensors and components can be chosen.

Project Cost Estimate

By: Lucas Gutierrez (Project Manager)

The cost report shows the current cost of components against the budget set by the customer.  A larger pool of money was given towards the PCB board and components because of the uncertainty of certain sensors being required (maze rules).  In case of laser cutting, money has been set aside to account for those costs.

Spring 2017 Mini Pathfinder Final Blog Post

 By: John Her (Project Manager)

Moses Holley (Electronics and Control)

Edgardo Villalobos (Manufacturing-Solar Panel)

Johnathan Chan (Manufacturing-Chassis)

Adan Rodriguez (Mission, Systems, and Test)

Executive Summary

Project Objectives

The Mini Pathfinder project for Spring 2017 is a scaled and modeled after NASA’s 1997 Sojourner rover of the Pathfinder mission. It will utilize the 3Dot board and a custom PCB. It is to be remotely operable with a fully functioning rocker bogie suspension system. It will be able to provide speed and battery telemetry to the user via the arxterra app and have a solar panel that charges the battery.

Mission Profile

Our mission is a scaled version of the Pathfinder project. We will remotely traverse a course of 27.8 meters in length. The course will have 3 stairs it will descend and 3 stairs it will ascend with each stair being 27mm. During this course the Mini Pathfinder will demonstrate electronic differential turning, solar charging, proper rocker bogie mechanics and provide telemetry.

System Design

The Mini Pathfinder will use the 3Dot and a custom PCB for the extra motors and the encoders.

Figure 1. System Block Diagram

Subsystem Design

Modeling Results

Interface Definitions

We have three interface definitions for three different IC’s. The first is for the 3Dot board. The next two are for the custom PCB that will have the two extra motor drivers and the digital io expander for the rotary encoders.

Figure 2. Interface Definitions for the 3Dot Board

Figure 3. Custom PCB IC Motor Driver Interface Definitions

Figure 4. Custom PCB IC Rotary Encoders Interface Definitions

Cable Tree

Our cables will be routed from the motors and encoders through the suspension and into the electronics box. The solar panel will have a mount with a hole where the cable will connect so that it can charge the battery.

Figure 5. Cable Tree

Mission Command and Control

Figure 6.

Figure 7.

Electronics Design

After the trade off studies, we have decided on micro metal gear motors and hall effect sensor based rotary encoders. To control the extra motors not connected directly to the 3Dot, we will be using a custom PCB that is base on the adafruit motorshield which houses a PCA9685 and two TB6612FNG motor drivers. In addition to the motorshield, we will also implement a MCP2301 I/O expander to take the digital input from the rotary encoders. The power for the extra motors will be supplied from the battery boost on the back of the 3Dot board so that we can access the same voltage that is supplied to the motors on board the 3Dot.

Figure 8. Adafruit Motorshield (PCA9685)

Figure 9. Adafruit Motorshield (TB6612FNG)

Firmware

After discussing our project flow chart with an fellow Electronics and Control Engineer, Forest Nutter, we decided to redesign our flow chart. The initial image is the beginning stages of an overall view of the project.

Figure 10. Firmware Flowchart

PCB Schematic

Since the 3DoT only has a single motor driver chip that is capable of driving two motors, we needed to make a custom PCB to interface with the 3DoT that will allow for 4 additional motors and also be able to take digital input for the rotary encoders. We modeled the motor driver off of the adafruit motor shield version 2.3. The motor shield consisted of the PCA9685pw PWM driver and two TB6612FNG dual motor drivers, which is what the 3DoT uses. The PCA9685pw allows for control of PWM outputs through the I2C bus, which is available through the 3DoT, so that we could properly control the motor drivers. For the digital IO expander, we chose the MCP23017 due to it having 16 digital IO channels for our rotary encoders, which use two digital outputs per wheel for a total of 12 outputs.

Figure 11. Custom PCB Schematic

Our first schematic design had many errors that were easy to point out and a few that were only seen if looking very close. Fabian, previous EE 400D student, pointed out the schematic flaws and  gave recommendations. One of the mistakes I made was in forgetting the pull up resistors for the I2C communication. The I2C needs the pull up resistors because most of the devices are active low. Throughout my ICs and the voltage in, (VCC and VBoost), I forgot to place decoupling capacitors for circuit protection and for clean signals. My first completed schematic looked great with labels on the wires. By simply clicking the name of the wire and looking closely, I connected the TB6612FNG dual motor driver outputs to each other which caused them to short. My project manager, Jon Her, advised that we start from scratch. After the irritative process the above image is the finish schematic. It was a tough process, but having the schematic looked over and over ensured that we have a potential working PCB.  

PCB Layout

After the electronics and controls engineer(ENC), was finished with the schematic on EagleCAD, it was suggested that we try to make a printed circuit board(PCB) out of it and mount the PCB onto the 3DoT board like a “shield” because it was a level 2 requirement(See Figure 1). On the EagleCAD, requirements for the power lines had the size of 16mil. Data routes had 10mil. And there was a 20 drill size for vias. All of the lines had a 45 degree turn so that it doesn’t lose its connection when it is printed and powered up. The top and bottom planes of our PCB are ground copper poured planes. After placing all of the parts on the specified size of the layout, we made sure we used the DRC several times to make sure it completed all the requirements. We also ordered the parts and components before the PCB was made, so that it would arrive in a timely manner.

 

Dimension on 3dot board

Figure 12. Dimensions of the Custom PCB Shield

 

Completed PCB Design

Figure 13. Screenshot of the Routing Diagram

Figure 14. Final product with top and bottom ground copper poured planes in red and blue

We created a custom PCB for our 3Dot board(see figure 3). After we did a final DRC on our final PCB, we then sent it to the president, customer, and Fabian for approval. We had to revise our board several times before it was approved, but once it was, it was sent to 4PCB to be manufactured. We then purchased the stencil from OshStecil. The next steps are to use the stencil and put solder paste on the top layer of the custom PCB. Then we will put the parts and components in its respective places. After, we will heat the board up using a heat gun so that the components will attach onto the board.

Hardware Design

Chassis

To ensure that the 3Dot sat correctly into the chassis, small cutouts were made to allow the Bluetooth module room along with a few pins that were sticking out from the battery holder. A channel was also cut out to allow a wire to access the battery boost on the underside of the 3Dot. There were also channels cut out to allow access to the usb port and the power switch on the 3Dot.

Figure 15. Inside the chassis

To allow proper rocker bogie mechanics, a three beveled gearbox was utilized. Each gear has 16 teeth to allow for a 1:1 gear ratio from the left side of the suspension to the right side.

Figure 16. The rocker bogie gearbox

Solar

As a requirement, the Mini Pathfinder was to have a Solar Panel charge the battery on the 3dot board. To accomplish this, the solar panel needed to be scaled to the rover, while also being able to supply enough voltage and current. The solar cells also needed to be encapsulated. The model of the solar panel was closely modeled after the Sojourner Rover.

Figure 17. Solar Cell on the Mini Pathfinder

With the help of the chassis manufacturer for the mini pathfinder, we were able to scale the size in which the solar panel needed to be. The model was scaled using schematic renderings of the real Sojourner that were found on the internet. The size of the solar cell needed to be around 122x52mm.

Once the size of the panel was found, I needed to find solar cells that were able to charge the 3dot battery and that would fit that size and then encapsulate them. To meet this, I used a 5V 200mA already encapsulated cell that was bought in store. The size of the solar cell was 120x70mm, which fit the requirement of size.

Figure 18. 120x70mm 5v 200mA Encapsulated Solar Cell

 

A micro usb was attached to both the positive and negative leads of the solar panel.

Figure 19. Wiring Diagram

 

After finding the type of solar cell I’d be using, a way of holding the cell onto the rover needed to be found. Using Solidworks, I was able to create a holder to house the cell in place with a hole in the bottom to allow for the micro usb plug to pass through to connect to the 3dot board through the outside. This holder allowed for easy replacement of the cell, if needed. The cell could easily be removed by sliding in and out.  

Figure 20. Solar Cell Holder

Figure 21. Solar Cell in Holder

In conclusion, the solar cell needed to be tested more in order to observe how long it really took to charge the battery. Overall the solar cell was a success in looks and functionality as far as charging.

Verification & Validation Test

Verification and validation can be viewed at this link.

https://drive.google.com/open?id=1D4-kNlP_zy35XqHd-88Zd2Wl2X3w6gr05WJnChsNDzU

Project Status

Power Allocation

Figure 22. Power Allocation based on maximum battery current discharge at any given time.

Mass Allocation

Figure 22. Mass allocation

3d Print Allocation

Figure 23. 3d Print time allocation

Cost Report

While we were able to get many parts and pieces for free, what cost the most was the custom PCB parts and the rotary encoders.

Figure 24. Costs of the project

Burndown and Percent Complete

With all our tasks still left to finish and the progress we made on the project. We finished at %62 completion and remained behind schedule.

Figure 25. Project Burndown with completion at 62%

Concluding Thoughts

If there is anything I would change knowing what I know now, it would to ensure that progress is made consistently every week and that the project schedule be updated at every opportunity. Meeting up with Professor Hill is always a good idea as well. He has valuable input, and tries to help. The lectures may not cover everything but that is why there is so much documentation on Professor Hill’s website. I would also suggest reading over all the material and not taking any other classes that require a lot of time, as this class will already eat up all your time.

Project Resources

Project Video: https://youtu.be/HVbv6seOrCA

 

CDR:https://drive.google.com/open?id=1jm68b_I-lYIxEX2KnLQ9umSzJKdmA3KJs0HE2ciRDsY

PDR:https://drive.google.com/open?id=1ROLFfi2FNQnKXeBWZFecfNi36JnrB8bCFhlLQb2EYzE

Project Libre:https://drive.google.com/open?id=0BwLPwnTqIptrcWEwalpwLS1oVzA

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

Verification and Validation:https://drive.google.com/open?id=1D4-kNlP_zy35XqHd-88Zd2Wl2X3w6gr05WJnChsNDzU

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

Fritzing Files: https://drive.google.com/open?id=0BwLPwnTqIptrc2xkWm5tYVdiM0U

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

Arduino Firmware: https://drive.google.com/open?id=0BwLPwnTqIptrQldiNFI1cDg3cW8

 

 

Spring 2017 Mini Pathfinder Encoder Testing

By: Moses Holley (Electronics and Control)

Introduction

The objective of this test was to gain an understanding of how RPM encoders work along with the Arduino code to manipulate them. We need the shaft encoders to detect wheel slippage and control the differential turning for the Mini Pathfinder.

Subsystem Relation

The RPM encoder test was first implemented using the OSEPP Motor Encoder. In this test, We gained an understanding of how the two A3144 hall effect sensors on the chip detect the rotating magnets. Then with the Arduino code converts the rotations in to RPMs. This test was used to measure the speed at which the wheels will turn at the 3dot output voltage of 5 volts. The n20 motors are rated at 6v at a speed of 32 rpm. We used an Arduino Uno because the 3Dot was having trouble uploading at the time.

Figure 1. Test Setup

Figure 2. RPM output

Arduino Code

Average RPM reading Code: This code waits for 10 readings then gets the avg of the RPMs.

// read RPM and calculate average every then readings.

// This code was retrieved online and we manipulated the reading[index] to get the correct readings.

const int numreadings = 10;

int readings[numreadings];

unsigned long average = 0;

int index = 0;

unsigned long total;

 

volatile int rpmcount = 0;//see http://arduino.cc/en/Reference/Volatile

unsigned long rpm = 0;

unsigned long lastmillis = 0;

 

void setup(){

Serial.begin(9600);

attachInterrupt(0, rpm_fan, FALLING);

}

 

void loop(){

if (millis() – lastmillis >= 1000){  /*Uptade every one second, this will be equal to reading frecuency (Hz).*/

detachInterrupt(0);    //Disable interrupt when calculating

total = 0;  

readings[index] = rpmcount * 5.45;  /* Convert frecuency to RPM, note: this works for one interruption per full rotation. For two interrups per full rotation use rpmcount * 30.*/

for (int x=0; x<=9; x++){

  total = total + readings[x];

}

average = total / numreadings;

rpm = average;

rpmcount = 0; // Restart the RPM counter

index++;

if(index >= numreadings){

 index=0;

}

if (millis() > 11000){  // wait for RPMs average to get stable

 

Serial.print(” RPM = “);

Serial.println(rpm);

}

lastmillis = millis(); // Uptade lasmillis

 attachInterrupt(0, rpm_fan, FALLING); //enable interrupt

 }

}

 

void rpm_fan(){ /* this code will be executed every time the interrupt 0 (pin2) gets low.*/

 rpmcount++;

}

 

RPM Code: This code gets the RPM of each reading.

// read RPM

// This code was retrieved online and manipulated the RPM.

volatile int rpmcount = 0;//see http://arduino.cc/en/Reference/Volatile

int rpm = 0;

unsigned long lastmillis = 0;

 

void setup(){

Serial.begin(9600);

attachInterrupt(0, rpm_fan, FALLING);//interrupt cero (0) is on pin two(2).

}

 

void loop(){

if (millis() – lastmillis == 1000){  /*Uptade every one second, this will be equal to reading frecuency (Hz).*/

detachInterrupt(0);    //Disable interrupt when calculating

rpm = rpmcount * 5.45;  /* Convert frecuency to RPM, note: this works for one interruption per full rotation. For two interrups per full rotation use rpmcount * 30.*/

Serial.print(“RPM =\t”); //print the word “RPM” and tab.

Serial.print(rpm); // print the rpm value.

Serial.print(“\t Hz=\t”); //print the word “Hz”.

Serial.println(rpmcount); /*print revolutions per second or Hz. And print new line or enter.*/

rpmcount = 0; // Restart the RPM counter

lastmillis = millis(); // Uptade lasmillis

attachInterrupt(0, rpm_fan, FALLING); //enable interrupt

 }

}

void rpm_fan(){ /* this code will be executed every time the interrupt 0 (pin2) gets low.*/

 rpmcount++;

}

// Elimelec Lopez – April 25th 2013

 

Conclusion

Although we gained a lot of understanding of how the RPM encoder works we will not use this model for our design. The shape of the OSEPP encoder is catered to a DC motor placed of it to be very close to the rotating magnets. We will have a different design that has the DC motor encased in the wheel which requires that the rotating magnet rotate around the motor. When we decide what kind of encoder will be used there will be an updated blog post.

Spring 2017 Mini Pathfinder Bogie Degrees of Freedom

By: Johnathan Chan (Manufacturing-Chassis)

Intro

Since the Mini Pathfinder has to be able to climb up stairs as large as the wheels, we need to ensure that the bogie suspension has enough of an angle to pivot to overcome the stairs. Measuring the angle of the pivoting bogie will help us determine if it can do this.

Measurements

We were able to measure the degrees of freedom by laying the suspension flat on a piece of paper and making a mark of where it is when it is flat. Then we marked where it is completely up. After we used a protractor to measure the degrees of freedom which is 87 degrees.

Figure 1. Flat on the Ground

Figure 2. Suspension all the way up

Figure 3. Angle of which the suspension from flat on the ground to all the way up

Conclusion

With the suspension we created, the rover will be able to maneuver through obstacles the size of its wheels.

Spring 2017 Mini Pathfinder Motor no Load Current and Voltage Test

By: Moses Holley (Electronics and Control)

Introduction

In this test, I will be testing the n20 motors at various voltages. The motors are rated for 6 volts, but the operating boosted voltage on the 3Dot board is 5 volts. The battery is rated at 3.6 volts, should we tap directly into the battery, but is typically fully charged at 4.2 volts [1]. The discharge cutoff voltage is at 2.75 volts, but wanted to test it at a slightly higher output of 3 volts.

Figure 1. Applying Voltage to the Motor

Results

Figure 2. Voltage and Current Results

Conclusion

There is no significant change in the current draw from the different voltages on all the motors. Since the 3Dot motor connectors will use the 5 volts from the boost converter, we will most likely utilize the same voltage output so that all the motors will spin at the same rate. This is an easier solution than programming the onboard motors to spin at the same rate that the other motors.

References

[1] http://www.batteryspace.com/prod-specs/1389-RCR123A36.pdf