Upcoming Events:

Robotathon Steering Committee - How It's Made Part 2

Matthew here. This is the last of three posts. In this post, I’ll talk about some of the challenges we’ve faced and will face, and how we plan to tackle them.

Field Logistics

A logistics challenge we’ve faced in previous Robotathons was how to store the field during and after competition. Last year, I kid you not, we bought half inch thick, 8 by 4 feet planks of wood for the field. It was very hard to move around without getting splinters and annoying to setup and disassemble.

This time we’ve learned our lesson and are using modular foam boards with a smart connection scheme. This will allow us to compactly store our field (sans the structures) in the storage closet.

Another issue was that we would leave the field out in the IEEE commons for extended periods of time. A snap together module field will make the assembling and disassembling process a cinch. An issue might be our centerpiece, the Tower of Power. The ME and ECE students in charge of designing this structure will need to keep in mind a solution that will allow it to drop in place work with minimal effort.

Sourcing Judges

Sourcing judges is a recurrent problem, often due to the fact that Professors or Corporate representatives run on tight, always changing schedules. Usually, we won’t know which professors will be able to make the competition until two or three weeks prior.

Ordering Parts in a Timely Manner

There are two variables that we want to maximize for this problem. Ordering the minimum amount of parts needed for the teams (optimizing cost) and getting the parts to the teams as soon as we can (optimizing lead time). There’s no perfect solution for this, but my current idea is to order parts (plus some spares) based off of the RSVP turnout prior to kickoff. If we have an RSVP open at the beginning of the semester, and keep it open up until the Monday of the week of Kickoff and order immediately, we can probably get the parts 1 or 2 weeks into the competition, right about when the teams finish their second checkpoint, the Design Approval checkpoint.

Encouraging Participation, Increasing Diversity, Building Community

There were a lot of suggestions in our Robotathon 2019 Evaluation meeting this semester about how to improve turnout and the overall experience of Robotathon. I’ll list a couple of issues and how we intend to address them.

Frustration in working with software and embedded systems

Definitely something that I and many others in ECE have experienced. To help, we’re releasing a dedicated Robotathon Guide that gives lots of insight and help on how to do various tasks that should make your experience smoother and easier. Additionally, we’ll be updating our RASWare documentation to make examples easy to run, and function interface purposes clear and useful.

Checkpoints and Deadlines piled up too quickly

We know that university, and especially freshman year, is a rough time for students as classes ramp up the work. To address this, we’ll be relaxing deadlines and penalties for turning in checkpoints late. We have 10 checkpoints this year, corresponding to each stage in the development of your robots.

We recognize that it seems a lot, but we think that breaking down the project into chunks will shorten the total amount of work to build a competitive robot in the long run by putting together the relevant infrastructure.

Each task we expect to take from 2-5 hours in weekly commitment per person, increasing linearly with the challenge number, so the overall workload shouldn’t be debilitating. This doesn’t include attending tech talks or learning independently, which is dependent on your personal commitment to learning robotics.

A good suggestion for keeping on the top of things is to set up meeting times with your group - ideally twice a week. Try to schedule one of the days during our Office Hours/Tech Talks/Checkpoints to get the most value out of the mentors.

Setting up the development environment was very rough

To tackle this, we’re going to be spending this summer updating our guides and processes for setting up your development environment. Our end goal is that the students, whether on Windows or Ubuntu/Linux (and MacOSX), should be able to install the packages they’ll need with only a few clicks, and be able to get going in working in a matter of minutes.

Rules in general changed a lot at the last minute

We will not update any rules (unless it’s bracket matching, which depends on turnout) prior to the Competition date. Starting back in Spring 2020, the Robotathon Steering Committee designed and evaluated our ruleset for fairness and playability. We will take a final vote at the end of the semester, and if approved, these rules are sealed for eternity.

The field was rough, and the robot got stuck

This actually happened to my team back in Fall 2017. This is generally a result of rushed and quickly designed competition fields (see Fall 2019). Since we have been designing the field through the Spring semester, and will dedicate the entire month of September to build it, expect a polished product by competition. Bring up any concerns, and we’ll address them.

People dropping out and teams disbanding

Attrition is the number one problem we’ve faced in past Robotathons. It’s usually due to classwork, getting behind in checkpoints, fighting with software development, or maybe even the teams have an argument or can’t meet up often enough. We’ve addressed a few of these reasons up above, but here are a couple more ideas we’re thinking of:

You can join our slack at utras.slack.com and message me (@RoboticFish) or the other co-lead (@Burak Biyikli) or email me at matthewjkyu@gmail.com.

Author: Matthew Yu