P18390: Translational Drift Robot
/public/

Systems Design

Table of Contents

During our system design phase we focused on both the mechanical and electrical side of our physical design as well as reaching out for funding. First, we will look at the mechanical side of the system design phase. The three Mechanical Engineering students, Stephen, Jimmy, and Rob, each designed multiple robot prototypes to allow for individual creativity and thought. After the first set of designs were made we went over each design to begin bouncing ideas off each other. We then went back on our own to come up with new designs. Now our designs were starting to have multiple similarities and this is when a final design began to be worked on.

Next, we will look at what the Electrical side Jacob and Alex, had been working on during this phase. They began planning the logic for our robot knowing the engineering and customer requirements. This was being done while they began researching what components would be used for our robot. Due to the RPM our robot would be spinning at they were challenged with finding components that could take in the information at a fast enough sample rate and not be interfered with the magnetic fields created.

We also began planning a test bed that would allow us to test our electric components before our robot was built to see how the magnetic fields would affect the components ,as well as, being able to have our components spin at known RPMs to make sure the data received was correct. Overall, we stayed very busy and kept to our tight schedule.

System Level Design Documents: Systems Level Design Documents

Team Vision for System-Level Design Phase

As a team we set very high expectations of what we wanted to get done during this phase. This was due to our competition date being so early in the second semester. We had several goals that were met during this phase. The first being beginning to work on our final design, the second being starting to outline the logic for our electrical components, and the third coming up with a design for our test bed. These are all very important steps that were crucial to have done at the end of this phase, so our project did not fall behind.

Functional Decomposition

Functional Decomposition (Electronics)

Functional Decomposition (Electronics)

Functional Decomposition (Spinning Robot)

Functional Decomposition (Spinning Robot)

Benchmarking

Customer Objectives:

  1. A translational drift robot for a BattleBot style Competition.
  2. Durable and modular for easy repairs.
  3. Accuracy in determining heading.
  4. Stable when stationary
  5. Use of absolute reference relative to the Earth's magnetic poles and operators orientation.
  6. Invertible.
  7. Complies with all NERC regulations.
Benchmarking - IMUs

Benchmarking - IMUs

Benchmarking - Motor Controllers

Benchmarking - Motor Controllers

Benchmarking - Motors

Benchmarking - Motors

Benchmarking - Wheels

Benchmarking - Wheels

Concept Development

Matlab code was used to determine motor requirements. The code used the rough mass properties of the robot (mass, Moment of Inertia, drive dimensions) and output the rotational speed of the robot and motor speed at half power and full power and the motor torque required for spin up. Once the motor requirements were set, we selected a few motors from the benchmarking table and ran them through a spreadsheet that produced a more detailed analysis of the robots spin up. The spreadsheet output a graph of the rotational speed and energy of the robot as a function of time and also gave us the necessary power requirements based on the motors electrical properties.

Matlab Motor Requirements

Matlab Motor Requirements

Spreadsheet for Motor selection page 1

Spreadsheet for Motor selection page 1

Spreadsheet for Motor selection page 2

Spreadsheet for Motor selection page 2

Feasibility: Prototyping, Analysis, Simulation

Bill Of Material (Preliminary)

Bill Of Material (Preliminary)

Total project cost poses a major risk to project success.

Above is our current bill of material (BOM). We have begun purchasing parts off of this BOM so we can begin testing. This BOM also serves as justification for the additional funding needed from the Simone Innovation Center. For the most up to date BOM click here.

The measurement range of the accelerometers, sample frequency of the magnetometer, and sensor tolerance to high impact acceleration pose a major risk to the project. A series of tests must to be run to validate the sensor functionality.

Test Plan Ouline

Test Plan Ouline

The sensors and motors will be characterized separately and then concurrently to validate proposed functionality under parasitic effects.

Sensor Test Rig

Sensor Test Rig

This test rig was developed to test the sensors under high rotational velocity. For further tests, a feedback loop-based control will be used to vary the disk speed, however the controllable drive can only reach 900rpm while the open-loop drive can reach speeds of up to 2500rpm. The Arduino is used as a tachometer, outputting the disk's rotational period.

Morphological Chart and Concept Selection

Robot Design Morphological Chart

Robot Design Morphological Chart

Controller Morphological Chart

Controller Morphological Chart

Concept Selection

Concept Selection

Concept Selection

Pugh Charts:

Pugh Analysis for Different Robot Types
Concept Manuverability Durability Damage Cost Complexity Total
Melty Brain - Baseline 0 0 0 0 0 0
Rammers + s -- s + 0
Wedges + - - s + 0
Lifters s s -- s - -3
Clampers - s - s s -2
Pugh Analysis of Controller Concepts
Concept Easy to Use Cheap Variable Input Easy to Make Ergonomic Intuitive Total
RC Controller - Baseline 0 0 0 0 0 0 0
Pre-Built Traditional RC Controller s s - + s - -1
From-Scratch Gamepad + + + + + + +5
Modified Pre-Built Gamepad + + + s + + +4
"The Wand" - - - - s - -5
The table above shows a Pugh Analysis of four different controller concepts; a traditional RC Controller, pre-built and used as a basline; a gamepad-like controller built from scratch with purchased components; a pre-bought gamepad modified to transmit instructions to the robt; and "The Wand", a Nintendo Wiimote-like controller which uses motion tilting of the controller to control the robot. This analysis shows that the gamepads are the best options.

Below are snapshots of our current CAD design incorporating our specific requirements, while also choosing the optimal design with the least amount of cons.

Current CAD Model - Covered

Current CAD Model - Covered

Current CAD Model - Internals

Current CAD Model - Internals

After further discussion we decided to create our own wheels and hub assembly so that we would be able to attach them straight to the motor since it has a spinning canister.

CAD Model of Hub - Front View

CAD Model of Hub - Front View

CAD Model of Hub - Isometric View

CAD Model of Hub - Isometric View

Systems Architecture

Below is a flowchart diagram describing how the transnational drift bot will function in a typical competition, detailing possible ways which it will be affected by the opposing team.
Mechanical System Flowchart

Mechanical System Flowchart

In the following Section of Designs and Flowcharts we describe exactly how the bot will be interacting both electrically as well as what information and controls it will be receiving and transmitting

Designs and Flowcharts

Robot Electrical Block Diagram

Robot Electrical Block Diagram

This document outlines the overall electrical structure of the robot. Expected failure modes for the robot include signal loss to the transmitter, sensor failure, battery failure and electrical noise from the motors. As such the Receiver will be required to have an automatic shutoff signal to the motors and microcontroller upon signal loss. The motor controllers must also be opto-isolated from the control circuitry to avoid damage due to high back-emf. The re will be two accelerometers to measure angular velocity, to ensure robustness,
Transmitter Block Diagram

Transmitter Block Diagram

The diagram above gives a rough layout of the connections to be made to the microcontroller aboard the robot controller.
Controller Conrol Flow

Controller Conrol Flow

The flowchart above shows the logic and data flow for the robot controller. The process is repeated so long as the controller is on, sampling the inputs, configurations, and the user heading, then encoding those variables into instructions. The resulting instructions are then transmitted to the robot.
Robot Control Flow

Robot Control Flow

The flowchart above shows the data and logic flow of the robot's software. The software will be built with concurrent interrupt blocks that handle different aspects of the robot's logic. In the chart above, cylinders are variables stored on the microcontroller. The robot continuously waits for instructions to be recieved. Once instructions are recieved, they are decoded, and the instruction components are stored into variables. The robot then returns to waiting for instructions.

While waiting for instructions, the robot samples the accelerometers on a regular period, then uses the samples, combined with the time since the last sample, to calculate how far the robot has turned, giving an estimated heading. The IMU operates on a much lower frequency, so it will be sample more infrequently. Once it is sampled, the reading is error corrected with the estimated heading to produce an error corrected estimate. Based on the mode configuration, either the error corrected estimate or the base estimate are then used with the values of the inputs from the decoded instructions to determine the PWM at which each motor should be operating at. These PWMs are stored to variables.

On a separate interrupt, these stored PWMs are used with the current PWMs to create smooth transitions in the motor speeds using PID.

Risk Assessment

During this phase we realized that we would need additional funding beyond what the MSD class provided. Being a project that was created by an individual student there is no additional funding provided currently. Therefore, we reached out to the Simone Center at RIT to seek additional funding. The funding was necessary because the projected cost was over $2,500.
Risk Management Updated

Risk Management Updated

After reassessing our risks, we determined that our top risks are still sponsorship, and our fast-paced timeline. Out of these two risks obtaining sponsorship is clearly the bigger of the two since ultimately without enough funding we will be unable to create a bot in the desired featherweight weight class. With the February 17th deadline approaching we are eager to begin prototyping individual systems and prototyping the system as a whole.

We have been actively in contact with the Simone Center for Innovation and Entrepreneurship to receive sponsorship and begin in testing the subsystems as parts start to come in.

Alternative ideas if we do not receive sponsorship have been discussed, and are included in the list below:

If funding is not received the last choice, finding additional funding is the preferred option, although with the timeline it might be an obtain funding and meet the deadline.

To address the issue of our rapid timeline we are trying to be ahead of schedule and get our design completely fleshed out, so when parts start coming in we will be able to incorporate them immediately.

For the latest Risk Assessment click here.

Design Review Materials

Agenda: Agenda

Plans for next phase

Below are what everyone is planning to be working on in the following 3 weeks.

Stephen Pasek

Jimmy Kramer

Alex Howard

Rob Sokolowski

Jacob Harrell

Individual Three Week Plans
Stephen Pasek Jimmy Kramer Alex Howard Rob Sokolowski Jacob Harrell

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation