Project

# Title Team Members TA Documents Sponsor
15 Survivor Identification and Retrieval Robot
Karun Koppula
Zachary Wasserman
Zhijie Jin
Xinrui Zhu proposal
The maze solving robot would attempt to solve mazes in a static environment and implement a learning algorithm to improve performance. It would have to detect obstacles and navigate around them to search for and identify the goal position. It could be extended to retrieving an object somewhere in the environment and return it to the start position. It is a proof of concept for search and rescue operations for autonomous learning systems. We would like to have it be able to quickly learn in a variety of different layouts.

Due to the computational complexity of the image processing algorithms, we would use a Raspberry Pi for algorithmic implementation, but create a circuit/PCB for robotic control.

Object Recognition
For the item retrieval and maze solving robots we would need to implement object recognition that is capable of recognizing a specific set of objects in non-static lighting environments
We need to be able to identify the walls/objects of the environment that the robot is operating. We will use laser/sonar sensors in combination with visual data.
It needs to be able to recognize obstacles and understand the possibilities of navigating around it.

Boundary Space Recognition/SLAM
We need to constrain these robots to work in a closed environment and therefore need a method to understanding the position of the robot with respect to the boundary
We could also use some image processing feature to identify the boundary with markers or physical barriers.

Manipulation
For the item retrieving and maze solving robots we would need to be able to manipulate the objects in question
We decided that a high degree of freedom robotic manipulator was out of the question and would prefer to use a simple claw/clamp, or suction/magnetic pull to interact with objects. We feel that to be able to pick up arbitrarily sized objects would be beyond the appropriate complexity of the project, so we would constrain the types of objects that need to be picked up with to work easily with the manipulative system

Control/Path Planning
We would likely build a circuit to automate the control that drives the motors or even moves the robot from point A to point B
We will need some sort of path planning algorithm to explore the environment
We would speak to the appropriate resources about how to implement these algorithms
Prof Girish Choudary
Prof Steve LaValle

Reinforcement Learning
In order to improve the performance of the robot with successive iterations navigating the maze, we will need to implement a reinforcement algorithm.
Relevant Resources
Prof Girish Choudary

Hardware - for much of the hardware component, Yuchen suggested that we speak to the machine shop about fabrication at least in terms of robotic design.
Motors/Wheels
Chassis
Motor Control Boards - we would be designing this circuitry to control the motors by linking the battery and the control inputs. As an extension of complexity in this area we would design a circuit that given an input and current state of the robot drives the robot to that location. This would allow us to include a microprocessor on the designed board and increase the functional capabilities. (DESIGN)
Raspberry Pi - for high level control of robot and algorithms (USE)
Sensors - for this we need camera(s) whether we do monocular or binocular vision would be an issue to discuss. We could also use laser rangefinders/lidar package to to SLAM for the obstacle detecting and avoiding robots. We could use sonar as well for distance sensing. We would need an IR camera or sensor for the human identifying robot. We could use pressure sensors or a scale to detect that the robot has correctly picked up or put down the objects in question. We would also need a sensor to check that the robot is stuck and burning out its motors.

Environmental Constraints
Since robust image-processing identification of objects in the environment is not the focus of this project, would would likely constrain lighting conditions to standard well lit levels.
We are also not designing a robot that can climb over obstacles, since complex dynamic is not the focus of the project. We would constrain the environment to a flat/drivable surface. Obstacles would be moved around.

Cloud-controlled quadcopter

Anuraag Vankayala, Amrutha Vasili

Cloud-controlled quadcopter

Featured Project

Idea:

To build a GPS-assisted, cloud-controlled quadcopter, for consumer-friendly aerial photography.

Design/Build:

We will be building a quad from the frame up. The four motors will each have electronic speed controllers,to balance and handle control inputs received from an 8-bit microcontroller(AP),required for its flight. The firmware will be tweaked slightly to allow flight modes that our project specifically requires. A companion computer such as the Erle Brain will be connected to the AP and to the cloud(EC2). We will build a codebase for the flight controller to navigate the quad. This would involve sending messages as per the MAVLink spec for sUAS between the companion computer and the AP to poll sensor data , voltage information , etc. The companion computer will also talk to the cloud via a UDP port to receive requests and process them via our code. Users make requests for media capture via a phone app that talks to the cloud via an internet connection.

Why is it worth doing:

There is currently no consumer-friendly solution that provides or lets anyone capture aerial photographs of them/their family/a nearby event via a simple tap on a phone. In fact, present day off-the-shelf alternatives offer relatively expensive solutions that require owning and carrying bulky equipment such as the quads/remotes. Our idea allows for safe and responsible use of drones as our proposed solution is autonomous, has several safety features, is context aware(terrain information , no fly zones , NOTAMs , etc.) and integrates with the federal airspace seamlessly.

End Product:

Quads that are ready for the connected world and are capable to fly autonomously, from the user standpoint, and can perform maneuvers safely with a very simplistic UI for the common user. Specifically, quads which are deployed on user's demand, without the hassle of ownership.

Similar products and comparison:

Current solutions include RTF (ready to fly) quads such as the DJI Phantom and the Kickstarter project, Lily,that are heavily user-dependent or user-centric.The Phantom requires you to carry a bulky remote with multiple antennas. Moreover,the flight radius could be reduced by interference from nearby conditions.Lily requires the user to carry a tracking device on them. You can not have Lily shoot a subject that is not you. Lily can have a maximum altitude of 15 m above you and that is below the tree line,prone to crashes.

Our solution differs in several ways.Our solution intends to be location and/or event-centric. We propose that the users need not own quads and user can capture a moment with a phone.As long as any of the users are in the service area and the weather conditions are permissible, safety and knowledge of controlling the quad are all abstracted. The only question left to the user is what should be in the picture at a given time.

Project Videos