Search and Rescue Robot With Teensy 3.2 Board

Outline

This project documents a Search and Rescue Robot I built with a team of 7 engineers for a robotic design class. The goal of the robot was to autonomously complete an obstacle course that simulated a search and rescue mission. Through careful project management, meticulous design, and rigorous testing, our robot proved the best performance compared to other teams.

Motivation

Research has shown an exponential increase in natural disasters correlating to the rise in climate affecting emissions. And the danger associated with search and rescue missions highlights a need for automation. This was the purpose driving our SaR robot development.

The Course

Consisted of a ramp, 3 foot wide chute, 1 foot tall wall with a 6 inch step, and a med-kit drop-off zone

Limitations

1. Budget max of 700$
2. Built and ready for presentation within 2 months
3. Maximum weight of 40 lbs. and width of 3 ft.
4. Able to survive a drop from a height of 1 foot
5. Able to complete the course without human input

Technical Skills

1. Mechanical Design -- CREO Parametric , Finite Element Analysis , Rapid Prototyping , Electro-Mechanical Systems
2. Project Management -- Risk Analysis , Budgeting , Scheduling
3. Manufacturing -- Metal Fabrication , Additive MFG , BOM Documentation , Design for MFG
4. Software -- C++ , Arduino IDE , Sensor Automation

This instructable is only a showcase of the Search and Rescue Robot project. Custom CAD files and specific fabrication and assembly instructions are not provided

The main materials/tools/software used are a Teensy 3.2 board, teensyduino IDE, a 3D printer with PLA filament, aluminum and steel metals, and off the shelf wheels, bearing, collars, hardware, etc.

The methods used that contributed towards our groups success included diving up the labor, analyzing risks, creating a team production philosophy, and scheduling important milestones.

This effort put into planning and management allowed us to meet each milestone on time, anticipate certain risks, and make decisions more efficiently.

The creation of this robot was inspired by simplistic design rooted in first-principles thinking.

(CAD components are unavailable)

Drivetrain

The drivetrain was designed as the main mechanism to traverse the wall obstacle. I conducted a theoretical analysis to determine the wheel size and the required motor torque.

Upon testing, I found that slipping against the contact point was a larger issue than expected. So, I conducted a slipping analysis using equations (1) and (2)

This showed me that a wheel of radius = 20 in. would be required to completely eliminate the chance of slipping. A 40 in. wheel, however, was impractical for our application, and I decided to test other solutions, such as customized treads and a one way bearing on the rear wheel.

Additionally, I found that a 40 in. wheel would require a minimum torque of 36 ft-lbs. to surmount the wall. Looking at the Mini-CIM motor graph,

the max torque is well above the requirement. Thus, these were chosen to be used with a belt and hub adapters to drive the wheels.

Finally to solve the slipping problem, rubber blocks were added to the wheel. These applied the torque from the wheel entirely into a normal force when climbing the wall.

The final assembly featured 18 in. wheels.

Chassis

The chassis length was determined by the geometry while traversing the wall obstacle, based on wheel radius.

A modular back leg extension was added to compensate for varying wheel sizes.

Load-bearing Components

I conducted a Finite Element Analysis in CREO to determine the component strengths required during operation. The forces subjected to these parts included weight from the robot assembly and the impulse produce from a 1 foot drop.

I determined the component materials based on the max force expected.

Electronics

Because the robot had to complete the course without controller input, I integrated proximity sensors for spatial estimation and photo sensors for light navigation. The below sensor layout provided the best coverage.

The electronics layout included the Teensy 3.2 board and a 5V battery, several sensors (not depicted), a controller receiver, 2 motor controllers, 2 mini-CIM motors, a servo for the med-kit system, a 12V battery for larger electronics, and a fuse box.

Software Architecture

The software was coded in Arduino's C++ language. It had 2 modes: open-loop for hardware testing and closed-loop automation mode.

Open-loop simply used inputs transmitted by a remote controller to drive the mini-CIM motors and servo. This mode allowed me to physically test the robot on the obstacles and make design changes if needed.

Closed-loop was the main mode for the final demonstration. I developed this automated mode by tackling each obstacle individually, then put each block together with transitions. The code had a function for each obstacle:

1. autoRampToChute() - navigate to the front of the ramp using the autoLight() function ==> procedurally align itself to be straight to the ramp ==> drive straight while guided by the proximity sensors ==> if side prox sensors produced a value greater than the proximity threshold (the robot is too close to a chute wall), then it would turn in the other direction
2. autoWall() - drive forward slowly to climb each step and overcome the wall ==> drive fast to dislodge back leg from the wall

Unfortunately, this function is entirely timing based and was still a work in progress. I would've liked to incorporate other sensors (e.g. line sensor, more prox sensors, etc.) for better spatial estimation and not need to rely on a hard-coded procedural algorithm.

1. autoMedkit() - navigate to basket using autoLight() function ==> stop at a proximity threshold ==> actuate the servo to release the med-kit

These individual functions were put together in the autonomous() function. Each function would break and proceed to the next based on proximity and light data received from the sensors caused by certain course characteristics.

---

We were the only group to finish the entire course in open-loop, proving our robust mechanical design. We were also able to finish half of the course autonomously - the robot got stuck while traversing the wall obstacle - the best performance compared to other groups.

Given more time, I would've like to develop a more robust autonomous program. The algorithm wasn't very good at transitioning between obstacles. Despite software troubles, the mechanical hardware was reliable and sturdy. The robot could survive several drop tests from up to 3 feet height and completed the entire course, with controller input, at a 100% success rate.