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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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:
Increasing Diversity - One of the ways to get members interested in the organization is to give them specific roles in the team. We’re looking at expanding recruiting to non ECE majors (typically the majority are ME, ECE, and CS, we see opportunities in ASE, Liberal Arts, and so on) to diversify the starting skill set and expand ideation. For example, an Art major can provide technical painting skills to decorate their robot, making it stand out in competition and winning the Best Aesthetic Design award.
Promoting Relationships - We’re also looking at those who want to form a team with other people they know. We encourage this, as existing relationships can improve retention, but we also want to match people with new acquaintances. Additionally, we want to improve relationships with mentors, other teams, and the RAS leadership. We want you to stay after the organization and participate in all of our other robotic committees. That’s why we’re looking at ideas like checkpoint competitions, a post kickoff smore party, and the Final Countdown work night.
Reducing Scheduling Conflicts - This is a two part solution. On the leadership side, we want to make office hours and mentors available as much as we can to the teams. We’ll do this by encouraging mentor weekly checkups on your progress - please feel free to tell them any concerns! - and putting checkpoint deadlines and tech talks together during the week instead of on the weekends when more people are accessible. On the team side, we also want to ask participants to provide a rough schedule of their academic affairs, so we can match you up with people who have similar schedules and can meet up more often.
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