## Inspiration

**Machine learning** is a powerful tool for automating tasks that are not scalable at the human level. However, when deciding on things that can critically affect people's lives, it is important that our models do not learn biases. [Check out this article about Amazon's automated recruiting tool which learned bias against women.](https://www.reuters.com/article/us-amazon-com-jobs-automation-insight/amazon-scraps-secret-ai-recruiting-tool-that-showed-bias-against-women-idUSKCN1MK08G?fbclid=IwAR2OXqoIGr4chOrU-P33z1uwdhAY2kBYUEyaiLPNQhDBVfE7O-GEE5FFnJM) However, to completely reject the usefulness of machine learning algorithms to help us automate tasks is extreme. **Fairness** is becoming one of the most popular research topics in machine learning in recent years, and we decided to apply these recent results to build an automated recruiting tool which enforces fairness.

## Problem

Suppose we want to learn a machine learning algorithm that automatically determines whether job candidates should advance to the interview stage using factors such as GPA, school, and work experience, and that we have data from which past candidates received interviews. However, what if in the past, women were less likely to receive an interview than men, all other factors being equal, and certain predictors are correlated with the candidate's gender? Despite having biased data, we do not want our machine learning algorithm to learn these biases. This is where the concept of **fairness** comes in.

Promoting fairness has been studied in other contexts such as predicting which individuals get credit loans, crime recidivism, and healthcare management. Here, we focus on gender diversity in recruiting.

## What is fairness?

There are numerous possible metrics for fairness in the machine learning literature. In this setting, we consider fairness to be measured by the average difference in false positive rate and true positive rate (**average odds difference**) for unprivileged and privileged groups (in this case, women and men, respectively). High values for this metric indicates that the model is statistically more likely to wrongly reject promising candidates from the underprivileged group.

## What our app does

**jobFAIR** is a web application that helps human resources personnel keep track of and visualize job candidate information and provide interview recommendations by training a machine learning algorithm on past interview data. There is a side-by-side comparison between training the model before and after applying a *reweighing algorithm* as a preprocessing step to enforce fairness.

### Reweighing Algorithm

If the data is unbiased, we would think that the probability of being accepted and the probability of being a woman would be independent (so the product of the two probabilities). By carefully choosing weights for each example, we can de-bias the data without having to change any of the labels. We determine the actual probability of being a woman and being accepted, then set the weight (for the woman + accepted category) as expected/actual probability. In other words, if the actual data has a much smaller probability than expected, examples from this category are given a higher weight (>1). Otherwise, they are given a lower weight. This formula is applied for the other 3 out of 4 combinations of gender x acceptance. Then the reweighed sample is used for training.

## How we built it

We trained two classifiers on the same bank of resumes, one with fairness constraints and the other without. We used IBM's [AIF360](https://github.com/IBM/AIF360) library to train the fair classifier. Both classifiers use the **sklearn** Python library for machine learning models. We run a Python **Django** server on an AWS EC2 instance. The machine learning model is loaded into the server from the filesystem on prediction time, classified, and then the results are sent via a callback to the frontend, which displays the metrics for an unfair and a fair classifier.

## Challenges we ran into

Training and choosing models with appropriate fairness constraints. After reading relevant literature and experimenting, we chose the reweighing algorithm ([Kamiran and Calders 2012](https://core.ac.uk/download/pdf/81728147.pdf?fbclid=IwAR3P1SFgtml7w0VNQWRf_MK3BVk8WyjOqiZBdgmScO8FjXkRkP9w1RFArfw)) for fairness, logistic regression for the classifier, and average odds difference for the fairness metric.

## Accomplishments that we're proud of

We are proud that we saw tangible differences in the fairness metrics of the unmodified classifier and the fair one, while retaining the same level of prediction accuracy. We also found a specific example of when the unmodified classifier would reject a highly qualified female candidate, whereas the fair classifier accepts her.

## What we learned

Machine learning can be made socially aware; applying fairness constraints helps mitigate discrimination and promote diversity in important contexts.

## What's next for jobFAIR

Hopefully we can make the machine learning more transparent to those without a technical background, such as showing which features are the most important for prediction. There is also room to incorporate more fairness algorithms and metrics.
## Inspiration

Every year roughly 25% of recyclable material is not able to be recycled due to contamination. We set out to reduce the amount of things that are needlessly sent to the landfill by reducing how much people put the wrong things into recycling bins (i.e. no coffee cups).

## What it does

This project is a lid for a recycling bin that uses sensors, microcontrollers, servos, and ML/AI to determine if something should be recycled or not and physically does it.

To do this it follows the following process:

1. Waits for object to be placed on lid
2. Take picture of object using webcam
3. Does image processing to normalize image
4. Sends image to Tensorflow model
5. Model predicts material type and confidence ratings
6. If material isn't recyclable, it sends a *YEET* signal and if it is it sends a *drop* signal to the Arduino
7. Arduino performs the motion sent to it it (aka. slaps it *Happy Gilmore* style or drops it)
8. System resets and waits to run again

## How we built it

We used an Arduino Uno with an Ultrasonic sensor to detect the proximity of an object, and once it meets the threshold, the Arduino sends information to the pre-trained TensorFlow ML Model to detect whether the object is recyclable or not. Once the processing is complete, information is sent from the Python script to the Arduino to determine whether to yeet or drop the object in the recycling bin.

## Challenges we ran into

A main challenge we ran into was integrating both the individual hardware and software components together, as it was difficult to send information from the Arduino to the Python scripts we wanted to run. Additionally, we debugged a lot in terms of the servo not working and many issues when working with the ML model.

## Accomplishments that we're proud of

We are proud of successfully integrating both software and hardware components together to create a whole project. Additionally, it was all of our first times experimenting with new technology such as TensorFlow/Machine Learning, and working with an Arduino.

## What we learned

* TensorFlow
* Arduino Development
* Jupyter
* Debugging

## What's next for Happy RecycleMore

Currently the model tries to predict everything in the picture which leads to inaccuracies since it detects things in the backgrounds like people's clothes which aren't recyclable causing it to yeet the object when it should drop it. To fix this we'd like to only use the object in the centre of the image in the prediction model or reorient the camera to not be able to see anything else.
## Inspiration

Our inspiration is the multiple travelling salesman problem, in which multiple salesmen are required to visit a given number of destinations once and return while minimizing travel cost. This problem occurs in many subjects but is prominent in logistics. It is essential that goods and services are delivered to customers at the the right time, at the right place and at a low cost, with the use of multiple assets. Solving this problem would result in improved quality of service to customers and cost reductions to service providers.

## What it does

Our project generates delivery routes for a given number of mail trucks. We receive a list of all recipients along with their physical locations. These recipients are assigned to trucks based on their locations. The sequence of delivery for each truck is then optimized to minimize each of their travel times, factoring in road conditions such as traffic and weather.

## How we built it

Our project generates delivery routes by simplifying the multiple travelling salesman problem into multiple instances of the single travelling salesman problem.

1 - Data Preperation. The list of addresses is converted into latitude and longitude GPS coordinates. The travel times between locations is acquired for and to each other location using the google maps API.

2 - Assignment of recipients based on physical location. We use KMeans clustering to group recipients based on their proximity to each other. Each truck has their own set of recipients. This step simplifies the problem from multiple travelling sales to multiple instances of single travelling salesman, for each truck.

3 - Individual route sequencing. We use the metropolis algorithm to optimize the sequence of recipients for each truck. For each truck, an initial random route is generated, followed by subsequent trial routes. The difference in route lengths are computed and the trial route is either accepted or rejected based on optimization parameters.

4 - Visualization. We use folium to visualize the locations of recipients, grouping and assignment of recipients and finally the route calculated for each truck.

## Challenges we ran into

Our two main challenges were:

1 - Our algorithm has inherent limitations that can make it unwieldy. It does converge onto optimal routes but it can be time consuming and computationally intensive

2 - Our algorithm relies on the assumption that going from point A to point B has the same travel time as from point B to point A. This is true if the path was a straight line and both ways have the same speed. However, in reality, going from point A to point B may take longer than the other way, such as different roads and speed limits. To overcome this limitation, we used the greater time requirement for our algorithm.

## Accomplishments that we're proud of

We put together a working solution for the multiple travelling salesman problem that can be applied on real world logistics problems. This problem is considered NP hard; as it is a generalization of the single travelling salesman which is also NP hard because the number of viable routes grows exponentially as more destinations are added. Overall, implementing a solution for this problem, to the level of a minimum viable product under tight time constraints was a non-trivial task.

## What we learned

We improved our knowledge on optimization for complex problems, as well as integrating mathematical solutions with APIs and visualization tools.

## What's next for ShipPy

ShipPy may be in a usable state but it can use more work. The individual route sequencing can be computationally intensive so that represents an area of improvement. For real time data, we used google maps API for travel time estimate, but this is all done prior to departure of the mail trucks. It may be possible to implement a solution that can adjust mail trucks' routes in real time should unforeseeable changes in road conditions occur.