# Title Team Members TA Documents Sponsor
57 Automated metal detection robot
Jack Li
Sumukh Kenkere Vasudeva Murthy
Akshatkumar Sanatbhai Sanghvi design_document1.pdf

Jack Li (shunjie2)

HongShang Fan (hf7)

Sumukh Kenkere Vasudeva Murthy (sumukhk2)

# Problem

People usually lose something by accident, and it could be keys to the houses or cars. Sometimes these objects will be too difficult to find, and can take up a lot of free time. In another case, for some industrial regions where construction is dangerous, losing parts and seeking them will pose potential hazards for humans. Thus, robotics developed specifically for metal detection is in need. However, currently most robots used for metal detection implemented manual control to search for objects, and it takes a long time if the field of interest is large, and it still requires human control or otherwise, it will not have directional searching progress. Thus, a new automated robot design with the function of searching for potential metallic objects efficiently will potentially be needed.

# Solutions

To design a robot that can search for metallic objects within a specific field without human control, we propose to use optical camera as the eye to the robot which indicates potential candidate places (like blocks of stuffs where small objects may hide). To be more specific, we will program the robot's movement using algorithms similar to random walk, but not exactly random. The optical camera serves as a way to capture essential geometric details within the field of interest, by signal processing, we will afterwards use these signals to command how the robot will move. It thus uses the route determined to automatically search for the metallic object with a metal detector thoroughly within each of the regions divided within the field of interest. To be more specific, we want the robot to move towards places with the "most likelihood" being the host to the target metallic object. Finally, when it detects something, the optical camera again serves as a recognizer to eliminate some false positives. This solution requires signal processing, and essential programming to the robot to make it move, we may need some experiments to implement different algorithms.

# Solutions Components

**Mechanical subsystem**

This includes power, robotic arms, motors, and actuators.

For power sub-subsystem, we will consider two parts which may require different power sources. For the robot itself, we consider Lithium Polymer Batteries (Li-Po), which is lightweight, have good capacity, and sufficient voltage for most electronic components (3.7 Volts). For the metal detector, depending on the type of detector we choose at last, we will have different preparations: for example, one cheap economic "9 Function Metal Detector With Arm Rest" in Harbor Freight store uses 6 AA batteries.
Of course, the choice of the metal detector will depend on our needs once we enter deep into the project. The optical camera may have its own power methods (like cable charging), so we will not consider them here.

For the other sub-mechanical system, like robotic arms, motors, and actuators, we expect the parts to vary depending on our final design, thus, we do not have specific order information at this moment. Typically we would expect at least one robotic arm used for metal detector handling, and one small controller for optical camera. Both parts should be able to rotate freely in horizontal plane so that we have the control to search thoroughly within a flat region. Some vertical direction control may need further parts to gain advanced control. We expect to come up with the specifics regarding the robotic parts in this sub-mechanical system within our first or 2 weeks of research after the project's approval.

**Electrical control subsystem**

The heart of the design relies on our ability to translate the signals from the camera to control signals that will be sent to the robotic systems (the robotic sub-mechanical system above), and thus, we will need a microcontroller which is capable of processing data efficiently to perform the task afterwards. The microcontroller should have inputs associated with the angle of the robotic arms (angle information is needed to control the 2D movements), camera (signal processing to output a 1 or 0 signal, combining with angle signal to determine if the robot should move towards that direction). Considering 2D signal processing tasks to be performed, we will need a large enough memory for our microcontroller, although speed performance is not a key factor here since we are more interested in the accuracy of calculation. Typically we have considered using AT32UC3A3256 for most efficient and compact design for both signal processing and controls. The alternative is to process data using other interfaces (computer), and send the processed and simplified data back to the microcontroller to perform tasks we desire.

**Sensors subsystem**

The eyes for the robotic system are two components: Metal detector, and optical camera. Metal detector as we have described in the mechanical subsystem, uses the economic metal detector from Harbor Freight store (70 dollars). Since this detector has a small detection range, we may have to switch to a more advanced detector. But overall, this should not be a limiting factor for this project as we have the core to be the optimized routes determination. The metal detector serves as one determination end to receive signals to trigger detection when the object is close enough. Optical camera is used for obtaining and transmitting data to the control subsystem to generate accurate control signals for mechanical subsystem. It also serves as the second determination end along with the metal detector to eliminate false positives. We have considered cameras similar to ArduCam PTZ camera which is both economic (50 dolllars), programmable, and flexible enough (apart from horizontal control, but also vertical direction to focus) to scan a reasonable amount of spatial information.

# Criterion for success

The most essential criterion for this project is "automated" and "field navigation". Thus, the project is considered to be successful if the robot can determine the potential metallic object's direction and move correspondingly towards the possible direction without human control (although start/restart/stop functions may still need to be controlled by human of course). Then it also needs a field criterion, as for field navigation, which means the robot has such directional movements within a desirable amount of distance. We expect at least 2m radius of field of interest to be accessible to the robot, and ideally 5-10 m, or more. Overall, if the robot can search for the object "correctly" (plan to place some larger metallic objects for noises), have relatively good directional accuracy, and is absence of human control after pressing the "start" button, this project should be considered successful.

Electronic Replacement for COVID-19 Building Monitors @ UIUC

Patrick McBrayer, Zewen Rao, Yijie Zhang

Featured Project

Team Members: Patrick McBrayer, Yijie Zhang, Zewen Rao

Problem Statement:

Students who volunteer to monitor buildings at UIUC are at increased risk of contracting COVID-19 itself, and passing it on to others before they are aware of the infection. Due to this, I propose a project that would create a technological solution to this issue using physical 2-factor authentication through the “airlock” style doorways we have at ECEB and across campus.

Solution Overview:

As we do not have access to the backend of the Safer Illinois application, or the ability to use campus buildings as a workspace for our project, we will be designing a proof of concept 2FA system for UIUC building access. Our solution would be composed of two main subsystems, one that allows initial entry into the “airlock” portion of the building using a scannable QR code, and the other that detects the number of people that entered the space, to determine whether or not the user will be granted access to the interior of the building.

Solution Components:

Subsystem #1: Initial Detection of Building Access

- QR/barcode scanner capable of reading the code presented by the user, that tells the system whether that person has been granted or denied building access. (An example of this type of sensor: (

- QR code generator using C++/Python to support the QR code scanner.

- Microcontroller to receive the information from the QR code reader and decode the information, then decide whether to unlock the door, or keep it shut. (The microcontroller would also need an internal timer, as we plan on encoding a lifespan into the QR code, therefore making them unusable after 4 days).

- LED Light to indicate to the user whether or not access was granted.

- Electronic locking mechanism to open both sets of doors.

Subsystem #2: Airlock Authentication of a Single User

- 2 aligned sensors ( one tx and other is rx) on the bottom of the door that counts the number of people crossing a certain line. (possibly considering two sets of these, so the person could not jump over, or move under the sensors. Most likely having the second set around the middle of the door frame.

- Microcontroller to decode the information provided by the door sensors, and then determine the number of people who have entered the space. Based on this information we can either grant or deny access to the interior building.

- LED Light to indicate to the user if they have been granted access.

- Possibly a speaker at this stage as well, to tell the user the reason they have not been granted access, and letting them know the

incident has been reported if they attempted to let someone into the building.

Criterion of Success:

- Our system generates valid QR codes that can be read by our scanner, and the data encoded such as lifespan of the code and building access is transmitted to the microcontroller.

- Our 2FA detection of multiple entries into the space works across a wide range of users. This includes users bound to wheelchairs, and a wide range of heights and body sizes.