Ben Huckell

The Drivetrain

We chose to use a timing belt to supply each wheel with power from two motors, geared using a 2:1 ratio. We chose this design to maximize the speed we were able to travel at, while still meeting our basic torque requirements to travel up inclined surfaces.

The Crossbar

To make our microcontroller, H-Bridges, and QRD 1114 light sensor array circuitry accessible, we designed a crossbar to allow for easy debugging. With this design, all electrical components were easily seen and accessed, and the downtime due to any major electrical changes was minimized. The crossbar also assisted in reinforcing the linear slide structure which guided the claw carriage.

The Claw

Our main strategy relied on picking up the infinity stones from their platforms. This required our claw to be able to hold onto the collected stones until we have reached our home area, then release the stones into their respective holes. We used a small servo motor connected to two meshing gears with 5 inch arms to complete this task.

The Winch

To raise and lower our claw carriage to match the appropriate height of the infinity stones, we used a winch or spool mechanism. To raise the claw we would simply spin the winch motor which would wrap the string about the spool, providing a tension force parallel to the supporting rails.

The Code

We designed an object-oriented state machine to control our main program flow. Each state represented a distinct task that the robot was required to complete. For example, we had one "Line Following" state which simply kept our robot centered on a continuous strip of black tape, using input data collected from our QRD Light sensor array. The following video shows one of our practice runs, where we were able to successfully collect three infinity stones.

The World

The following image captures a top view of the gazebo simulation world that our robot operated in. Our robot (in white) is shown at its starting position on the road and the "parked cars" are represented by the blue rectangles placed throughout the course at various "parking locations". Our objective was to navigate the roads, and collect the license plate information of all parked cars along our path.

Camera Input

The operation of our robot relied solely on the camera input feed it received from the virtual world. Within the gazebo simulation, a camera mounted on the top of the robot facing forwards continuously fed our system with an image feed. The following image shows an example of the frame we would recive back.

Demo Run

The following video shows a captured demo run of our finished robot. A top down view on the right portion of the screen shows the robots progress through its path, whereas the left portion of the screen shows the world through the eyes of the robot. There are a few other key points worth noting below.

Within the gazebo simulation world, we had to deal with the constraint that output commands were discrete in nature, meaning there was only a finite set of commands that we could give. In our case, this meant that we could not publish "go forward" and "turn left" commands at the same time. The result is that our robot looks very jittery as it travels. Its worth noting that this is simply a limitation of the platform the simulation was running in.

Bounding boxes can be seen throughout the video. Parked cars are represented with blue bounding boxes, pedestrians with red (or green) depending on their position, and the roaming truck with a yellow bounding box. The identification of these objects of interest were what we used to make decisions within our code.

At the very end of the video, all captured license plates are printed to the terminal in the top left corner of the screen.

Z-Score Calculations

To make well informed decisions, I needed to reduce all of the projected statistics into one single number. But the tricky part was comparing metrics that are so fundamentally different. How would one compare stolen bases to strikeouts? Walks to home runs? Lets look at an example with two different hypothetical players, with their Home Run and Batting Average projections for the following year.

If we consider a hypothetical league that only considers Home Runs to score points, it would be very easy to determine the better choice. Player A is likely to get more Home Runs than Player B - therefore I would choose Player A. However, if we were to introduce a league where both Home Runs and Batting Average were included, it becomes much less clear who the better choice is. This is where the concept of a Z-Score comes in.

Performance Metric - Z-Score

A Z-Score is a common statistical variable which measures the number of standard deviations a number is away from the mean of a data set. This allows players to be compared, in each category, to the other players in the league. By measuring the number of standard deviations a number is from the mean of all players in the league, we can directly compare Home Runs to Batting Average and, by extension, Player A to Player B. The following is the Z-Score formula.

• X = Raw Value
• μ = Mean of Data Set
• σ = Standard Deviation of Data Set

Once we are able to directly compare a player's performance to all other players, category by category, we can then sum each players individual Z-Scores from each category, to get one "overall" Z-Score. This is exactly how I am able to convert multiple numbers across many different categories, into one, meaningful number.

Data Collection

There are countless websites which offer free player projections, organized by category. For my projections, I used Python's BeautifulSoup library to scrape fangraphs.com for its "Steamer" fantasy baseball projections. Once I gathered all the data for each player, I saved the content into a Microsoft SQL server for easy table manipulation later on. The following images show the Steamer projections, as well as the saved table within Microsoft SQL. Saving all of the information here made the data very easily accessible from the Visual C# program I used to calculated performance estimates.

Now that I have gathered all of the statistics I need, the only remaining problem was ensuring that my main program worked for a variety of fantasy league formats. Some fantasy leagues are points-based, some are rotisserie-based, each includes different required positions to fill, and many determine winners based on custom-selected categories. The program needed to include some functionality for the user to define the specifications of their league, and the calculated Z-Score would be specific to their setup.

Define League Specifications

To make sure that my program was robust enough to handle a variety of possible fantasy baseball leagues, all parameters involved in the Z-Score calculation are based on the league parameters that the user enters. The User Interface of this league selection screen is shown in the image. Users can name their league, set their roster composition, and determine which metrics are used to calculate points, including the relative weight of each metric involved. This is done for both hitters and pitchers.

The Results

The following table is custom generated for each set of parameters defined by the user. It reduces all of the available player statistics and projections into one number (the "Score"). Taking personal bias out of the equation, players are compared simply in reference to each other, and ranks are clear.

For the past three years, I have tasked this program with selecting my teams in my annual fantasy league. Simply basing my player picks on their overall Z-Score, I have won twice, and finished in second place once.