Hi everyone,
Although it may be a bit late, we would like to release this year’s Build Blog and Technical Binder. Both these resources are now publicly available on our website.
We tried to keep the Technical Binder simple and use it mostly as a visual aid when explaining the robot to judges, so if you have any questions or want more specifications, feel free to ask!
Wow. This is awesome!
Thanks for releasing these!
New CAD computer one day and the 254 Build Blog + Tech Binder the next? Christmas in July really does exist.
On a more serious note, I always love reading these and am forever thankful to Team 254 for documenting and releasing such an amazing learning resource each year.
One of my favorite parts of the summer. There goes an evening! (not complaining) 
I love the technical binder. That’s the prettiest FRC publication I have ever seen and one the most useful. Thank you
Can I ask a logistical question here – reading the blog (which is amazing, by the way), how were you able to accomplish just the amount of time dedication to the team during the build season? I counted a total of 3 Rest Days.
How can the mentors juggle it with work and family, and avoid burnout? How do the students handle it with homework, midterms, etc?
Our team has had to basically shut down for a week in late January because of midterm exams. Putting in 8 hours a day every single day just isn’t practical.
We were able to do what we did without a large amount of burnout mostly because we had a large enough team that the load would not be placed on just a few individuals.
During the build season we had four rest days (these are all in the blog), all Mondays, excluding the first Monday, when we just starting the season, and the last one, which was during a week off from school so the students who wanted to were able to come. After we bagged up the robot, we all took a couple of days off. Also after bag and tag, our blog posts became less frequent (as did attendance), and so days of rest were not officially noted on the blog, though Mondays were still days of rest.
Additionally, lab safety policies put a cap on occupants, so the team limited signups for the lab to 3 days per week for students, though this was only enforced on weekdays when more students wanted to come, so I would often be there 4-5 days per week during build season. This limit allowed me to choose which days I would not attend, and so I would check my schedule to align that for when I have a test (as a sidenote, Bellarmine did not have official midterms, just big tests spread throughout the semester, so we dodged that bullet). I often was at the lab between 5 and 10 most days, and since school got out at about 3, I had a daily 2 hour block for homework. Any additional homework was done in the mornings before school.
The key to balancing robotics, school, and the rest of one’s life (so as to avoid burnout) from my experience has been making a schedule and sticking to it. When I say “lab between 5 and 10” I meant it, the latest I ever left was 10:36. Schedules are also easiest to keep when they are regular, so I got into a very nice groove of school, homework, lab, sleep, repeat throughout the build season.
Some numbers to go along with this (Lab times courtesy of our sign-in system, which is in the cloud):
Not only do we have a really large team (90 students, at least 30 in the lab every night) but we also have lots of mentors to distribute the workload. I have no idea how the mentors balance robotics with work/family, they are truly amazing.
Also, builds are usually not 8 hours long. Weekday builds start at 5:30 (mentors get off work), we spend an hour eating dinner together, and then most students leave around 10 or 11pm. Weekend builds go from 1pm to about the same time but sometimes end as late as 3am. However, students will sometimes come in shifts for weekend builds.
Our school does not give that many midterms, especially to underclassmen, so we don’t take time off for that.
Despite all that, it does take a tremendous amount of time to be a member of this team, but in the end I think it all pays off!
Until the end of build I don’t think we had a single true break day. We had 3 Mondays that were “breaks” where the majority of the students and some mentors didn’t come, but we still had some mentors and students there for all of them.
We took a few true break days post ship and worked reduced numbers of hours relative to during build, but still quite a lot.
This season was infinitely better than last year. 2013 was a nightmare. It took so much work to integrate all our subsystems and to complete the hanger. We also had fewer mentors, which took a toll on us. There was a 4 day stretch during the last full week of build where I was at the lab from 4 PM until no earlier than 4 AM, with one night until around 6:30 in the morning and another where we didn’t go home. This year we didn’t have a single night that was as bad as any of those.
I’d love to get a link at your Trello board (boards?) from this season. Would you guys be willing to share a link?
We ended up ditching Trello partway through build season (due to difficulty of keeping it in sync) and went with a more analog solution.
Thanks. We had decent success using Trello for our drawing creation, review, release, and mfg workflow. We had about the same experience as you did trying to use it for our overall activities.
This is an excellent resource, thanks for sharing! Now, if only I could get the rest of my team to read this…
Good idea. :rolleyes:
We gave Trello a shot this past year and it was much easier to implement during the fall as there was more time to keep it up to date and time to check it. It almost needs its own staff of a few students to keep it up to date and clear/archive/move around old cards/boards. We found it is a great tool for the offseason when meetings are infrequent and commitment levels are lower.
I’m curious, in the Tech Binder, I’m looking at the Excel Spreadsheets…
For Seconds to Completion and Probability of Completion, are those what you think the “Average” team will do or what you think your team can do?
They are what we guessed/expected would be the average amount of time and probability for the average team in Qualification Matches.
For example, certain teams, especially in eliminations, were able to have a successful catch probability much larger than 10%, but it rarely happened in Qualifications.
To add to what Andrew said, there was significant error in those estimates stemming from the fact that on the day of kickoff we neglected to consider that there would always be up to two opponent robots with nothing to do but play defense.
Gotcha, thanks
The spreadsheet model evolved a lot over time. The version that made the tech binder is close to the “final” version we had (from near the end of build season), before we started to see the game played for real.
It was interesting to watch the model evolve over time. We initially severely underestimated pedestal lighting/ball return time, as well as the ability of the average team to acquire assists fairly quickly by inbounding. As a result, on day one, one robot hurdling, self-catching, and scoring was looking pretty tempting.
Looking over your gearbox data/render in both the blog and the technical binder I was wondering why your team chose to orient the CIM motors the way you did. I’m relatively new to gearbox design and I rather like the triangle method that west coast products and AndyMark use. I just wondering what your team’s reason was for doing it the way you did.
Is it possible that I could get a look at the .STEP file for the gearbox?