1 of 22

Project 3 Presentation - GEARS

Team 33

Sylesh Jagannathan, Daniel Ceglio, Paul Kelson, Pradyun Srinidhi

2 of 22

Introduction: Project Overview

Natural and manmade disasters destroy communities and leave people without basic needs like food, water, medicine, fuel, and shelter
It is difficult to help people in disaster zones, because it is a challenging terrain to navigate, and it can be hard to communicate with people with different cultures
Need a way to help people in disaster zones that can overcome physical and cultural complications

3 of 22

Introduction: Project Objectives

Create Global Emergency Autonomous Response System (GEARS) to navigate disaster zones
GEARS should be able to

Transport supplies
Characterize hazards
Create a map of disaster zone
Deposit cargo container for people
Support all cultures

4 of 22

Project Management: Team Roles

Team Roles:

Paul Kelson - Time Keeper, Programmer

Pradyun Srinidhi - Meeting Coordinator, Builder

Daniel Ceglio - Encourager, Programmer

Sylesh Jagannathan - Recorder, Builder

5 of 22

Project Management: Time Management

Gantt Chart

Work Breakdown Structure

6 of 22

Project Management: Brainstorming and Metrics

Technical Requirements

Functional Block Diagram

7 of 22

Evidence Based Decision Making Process: Sensor Testing

8 of 22

Evidence Based Decision Making Process: Decision Matrices

Motor Configuration

Cargo Mechanism

Tire Configuration

Sensor Placement

9 of 22

Mechanical Design Philosophy: General Design

GEARS 1.0

GEARS 2.0

10 of 22

Mechanical Design Philosophy: Drive/Chassis

GEARS 1.0

GEARS 2.0

11 of 22

Mechanical Design Philosophy: Sensors and Placement

Closeup of Sensor Turntable

GEARS 1.0

GEARS 2.0

12 of 22

Mechanical Design Philosophy: Cargo Container Design Iterations

Top Left:

Cont. 1 CAD

Top Middle: Cont. 2 CAD

Bottom Left and Middle:

Cont 3. CAD

Right:

Cont. 3 Final

13 of 22

Mechanical Design Philosophy: Cargo Container Markings

Top from Left to Right:

Food and Water

Shelter

Medical Supplies

Bottom:

Fuel

14 of 22

Mechanical Design Philosophy: Cargo Storage and Deposition

GEARS 1.0 Cargo Deposition “Conveyor” Design

15 of 22

Mechanical Design Philosophy: Cargo Storage and Deposition

GEARS 2.0 Cargo Deposition “Claw” Design

16 of 22

Software Design Philosophy: Organizational Structure

3 Independent files containing nothing but functions

hFNC: sensors on the head of the robot
oFNC: orientation and turning
iFNC: magnetometer and calibration

Imported into Main_Driver to run full maze logic
Structure made it very easy to independently test and implement new functions

17 of 22

Software Design Philosophy: Main Navigation Algorithm

SETUP: getting the position, orientation, and maze parameters
While in loop:

Checking all the sensors for positions of walls, magnets, and IR sources
Write these to the map
Turn right when possible, then stay straight, turn left, or turn around
Orient correctly to new direction
Drive forward one grid unit

18 of 22

Software Design Philosophy: Sensor/Swivel Code

Attempted to implement full swivel vision for Ultrasonic sensor -> failed and switched to 3 point read
Code allowed for reading of IR sensor concurrent with distance readings
Magnetometer in IMU utilized by filtering out background magnetic readings.

Option 1: Full Sensor Swivel Scan

(approximation of actual wall structure in red

Sensor readings in blue)

Option 2: Three-point scan (More Accurate distance readings)

19 of 22

Software Design Philosophy: Orientation and Mapping

First iteration of turning code used motors to turn specific distance - Failed
Final iteration used Lego Gyroscope to turn ±5 degrees consistently
Variable “netTurn” keeps track of exactly how far the robot has turned in reality
Makes orientation tracking trivial, keeps robot straight when driving
With orientation constantly updated and the robot driving one grid unit per loop, mapping is trivial

20 of 22

Demo Performance:

21 of 22

Areas for Improvement

Would limit use of the front ultrasonic sensor and get new battery
Have better weight distribution, allowing for the back wheel to be able to move freely
Would also spend more time on the magnet sensing code, as detection was unreliable

22 of 22

Conclusion

In conclusion there just wasn’t enough testing using the demonstration conditions to make the demonstration successful, but the system was well thought out and its many upsides make it extremely viable for upscaling.