I've had among my friends, peers, and professors a number of WWII veterans - mostly American, some Canadian, and some German. Whether it was allied airmen shot down over Europe or German soldiers captured near the Rhine, captors would often say: "
für dich ist der Krieg vorbei" - for you, the war is over.
(photo recon Spitfire: https://commons.wikimedia.org/wiki/File:Spitfire_MkXIX_Reconnaissance_(3635937207).jpg)
So Groundhog Day finds us muttering, with a mixture of disappointment and relief: "
Für uns ist das Spiel vorbei" - for us, the game is over.
Disappointment because we want the students to be competitive. We expect to be back next year but this year is thoroughly cooked, and I can't pretend to be happy about that.
Relief because by season's end it became pretty apparent how far we were from being able to field a nominally competitive robot. It's no fun - and very nearly unsporting - to take a noncompetitive robot to State. That is no longer a concern.
That actually hurt to type. I spoke with another mentor who expressed a similar set of emotions and who is writing up an internal analysis of what went right and wrong, combined with some pressing questions about where do we go from here. This isn't an attempt to put words in his mouth or take his thunder or anything, but as with the other posts, it's my point of view about this whole thing. It turns out our points of view are pretty similar.
This makes a lot more sense with some perspective, so a brief review is in order. I'm certain some details are wrong - the mentor count is probably +/- 1 for example, but it's what I recall on a Sunday afternoon with a dog curled up at my feet, so it's what you get.
Season 1, 2014-2015:
- One team (8578),
- Lego Mindstorms as the controller.
- Know of at least 3 "full time" mentors.
- Made it to State.
Season 2, 2015-2016 (my first year):
- One team (8578),
- 6-7 "full time" mentors + 2-3 that helped ~50% of practices.
- first year with Android Studio.
- Many teams had no autonomous mode
- Made it to State - I think 8578 was on the winning alliance that year
Season 3, 2016-2017:
- Two teams (8578, 11959)
- 6-7 "full time" mentors, plus 2-3 who were at 50% of practices.
- Autonomous mode necessary to advance in qualifying competitions.
- Team 11959 made it to state. This was running pretty close to the edge. A couple more mentors would have been supremely useful.
Season 4, 2017-2018:
- Two teams (8578, 11959)
- 4 "full time" mentors plus ~5 "part time."
- The autonomous continues to become more complex - vision recognition now necessary to score highly.
- Neither team qualified for state
The technical demands have increased each year even as mentor support decreased. We've gone from around one "full time" mentor for every 2 students to one for every six. This is not sustainable.
It's true that we did have one mentor take an extended leave due to circumstances beyond his control, even without that we'd have been working with razor thin margins.
Let me say right now that I (all of us, really) deeply appreciate of all of the mentors we had, whether you made one practice, ten practices, or all of them. To all of our mentors and students who read this: PLEASE do not take any of this as a criticism of your efforts. In fact, thank you!
BUT ... We cannot do things this way again.
The overwhelming majority of the teams - and nearly all of the competitive ones - are composed of students in grades 9-12. Since FTC is open for students from 7-12th grades and FRC in Columbus is open for 9-12, we've concentrated on recruiting new 7th and 8th graders each year. The teams we compete against have an average of ~3 years of experience, ours have less than one. We are in a constant state of teaching students the absolute basics of coding and hoping desperately that some
grok the more subtle aspects of software engineering.
It simply is not plausible to teach someone the difference between an "if" and a "for" in August then have them extend classes into new objects and deal with the inherent limitations of running a near-real time system on something as unsuited for the purpose as Java and Android in October. Don't get me wrong, Android and Java are quite the sporting choices for this job and make it an edgy set of problems. "
Garbage collection" isn't a metaphor here, it's a feature.
For example's sake, I put a scope on an $8, single core, 16 MHZ Arduino UNO clone and watched it hold +/- 5
microseconds on a 60
microsecond pulse.
A Raspberry Pi 3 is similar to our phones - 1 GHZ for each of 4 cores, Linux variant OS. With both a Pi and our $100 phones I'm comfortable with allowing 1-5
milliseconds variation on a 50
millisecond loop. It may be better than that, but if we plan for that kind of slop things seem to stabilize nicely.
To put it another way, the precision of the "correct" kind of part is roughly
3 orders of magnitude superior to what we're actually using. So part of the programming fun is figuring out how to work around those limitations gracefully and that requires more thought and skill. These are spendy in any catalog, and simply not available among our
ab initio students and most of our mentors.
We can teach our students how to break problems down into simpler problems, how to view the program as a data pump, and maybe some basics configuration management. We
cannot get them to a place where they can code a reliable, maintainable, adaptable robot. Not in one year, not in two.
If that is the demand, we shall have a
mildly erratic kinetic sculpture but not a robot
We have exactly the same thing happening on the hardware side. More continuity might not cure everything, but it's an absolutely vital piece of triage.
The game itself is difficult enough to be worthwhile and it's less expensive than FRC. Consequently, I believe (without supporting data) that we are seeing some FTC teams which would ordinarily be FRC. If that really is the case FTC evolves into less of a feeder for FRC and more of a smaller, lower budget, but slightly more precise version. Think Swiss watch vs courthouse clock. The clock is bigger, more expensive, and talks back to you at 100 decibels. It's brash and loud, but not inherently more complex than a mechanical timepiece that fits on your wrist.
--------------------
So what discussions do I think we absolutely must have?
First is the brutally frank and candid discussion with the parents about the absolute need for regularly available mentors. The amount of skill and knowledge needed is negotiable, but clearly more is more.
I hate like anything the idea of closing off robotics to science-minded students. But without enough mentors, robotics practice becomes "come play on your phone for a couple hours" and that's fair to no one.
Second, we need to reassess our goals and objectives for the FTC program. Do we stay associated with Central Middle School? Do we restrict it to 7-9 grades, 7-10, or 8-12 or some other set? Do we discuss a third team, possibly open to home school groups? -- It occurs to me that home school groups are in a unique position to use robotics as an integral part of their curriculum and we may find a higher correlation between students and parental involvement than in the population overall as well as strong continuity.
Most importantly, we need to set in stone the conditions under which we will support 1 team, 2 teams, or
n teams.
Because I don't want to win as much as I want to make it very hard for someone else to win, and I want the season to end at State, not when the judges give us that sympathetic look and gently say "
Dein Roboter ist kaputt. Für dich ist der Krieg vorbei."
But ... I've been playing around with Python and a Raspberry Pi a little, and thought it might be interesting. Yeah, I know, it isn't the same thing. Python is interpreted yada yada yada... But I'm doing this for fun so it's an experiment worth pursuing just a little bit. 
The fun thing here is the millis and stopmillis ... we're basically timing the precision of the "sleep" command. Now, I think we _all_ can think of better ways to look at time, but for a really crude idea of what's going on, this will get us started. Here's what we see right off the bat. When I ran it 50 times at 0.05 seconds each, I was seeing some reports of 51ms, but mostly 50's. Roundoff error maybe? Well,run it with blinks of 10 seconds duration instead of 50 milliseconds ... and the very first one comes back at 10010 milliseconds. This seems plausible to me. 
