Java Is as Java Does

We would not seek a battle, as we are;

Nor, as we are, we say we will not shun it.

Henry to Montjoy,  Henry V,  Shakespeare

Last season I (Howard) was not very active in FTC Robotics, and it turned out to be a fascinating year - new leagues, new competition formats, and just when it was getting into the home stretch, it got locked down - hard.   Along with nearly everything else.  None of us saw that coming a year ago.

So here we are at the start of a new season, and not a one of us knows what will happen over the next 4-5 months.   That's actually OK, and more to the point, it's what King Harry was driving at in that quote: "our present condition may not be to our best advantage, but regardless of our present condition we'll take it on."

In a normal year we'd be meeting in the shop and using shop computers and doing a lot of loud talking to be heard over the shop noises.   This year, we're starting "virtual" or on-line, and that creates both challenges and new opportunities.

Virtual practices are a new thing for us, and it's probably good and bad in equal measures.  The face to face interaction, the whiteboard sessions, and some of the subtleties about mapping a real world into a virtual space don't happen easily in a virtual session.   BUT, nobody needs to yell to be heard over the shop tools, and I think we can do some interesting things.

Elsewhere in this blog you'll see my fondness for the Raspberry Pi as a learning tool.  (link to blog post here)  The humble Pi was built for this job, and the default Raspbian OS has, for years, included both Python and Java development tools.   Java, as you no doubt recall, is the language we use for programming the robot.  One of those Java development tools, also available for Mac, Linux, and Windows, is BlueJ.

Now I'm not saying, or even really recommending that everyone go install BlueJ or Greenfoot, especially since we're doing most of our development on Android Studio, but let's be candid.  Android Studio is kind of a hog.  If you ask it how much memory and processor it needs, it'll burp like Jabba the Hut and say "MOAR" without even a please.   BlueJ is lighter (it runs on a Pi, for goodness sake), and for experimenting with some ideas or just learning some aspects of programming in an object oriented environment, it has some really neat features.

One of those features is that it allows you to run a small method (like a subroutine, but only if you're REALLY old) all by itself without having to run the whole program.   Here's a screenshot of how that looked at a recent practice.

BlueJ itself is available from https://bluej.org/  as is a usable set of instructions and links.

It, like the Pi, was developed as a teaching tool, so no surprise that several tutorials on how to use it come from various universities.  I've used this one, but there are others:   https://www.cs.utexas.edu/~scottm/cs307/handouts/BlueJProjectInstructions.html 

While the next couple of sessions will have a strong focus on reinforcing the basics - data types, good structure, use of methods, and probably an introduction to classes, my strong sense is this:

The mentors (including me) need to start thinking about how to test small snippets of code, and how to teach the students to do this.   Shop hours will be precious, and every single bug we can get sorted out before heading downtown will pay us back by the bucketful. BlueJ allows running just one function at a time pretty easily and that, my good people, is power we can use.

If you want to use and extend some of the code we worked with earlier, I've put it on GitHub here: https://github.com/50N40W/javacode/tree/master 

But it's always worth remembering that while the details of a language are necessary, the discipline - and yes, beauty - of a well constructed program transcend any specific language.

Raspberry Pi.

For the last couple of years, a couple of parents have asked what kind of things they might do at home for their student who is interested in coding.

My reliable fallback answer is "Raspberry Pi."

This one in a yellow case was mine until I mailed it off to our oldest child (a computer science major) who had a need to do some low level work on an ARM processor.  Do NOT worry if none of that sentence made sense. :-D

I replaced it, of course, but I still miss the sticker.  I often try to have 3-4 of the zeros on hand, and give them out when I find myself around college nerds and see a project I think is cool. 


A complete - except for monitor and keyboard/mouse - setup will run between $35 (for a Pi Zero W) and about twice that for a Pi 3B+.
Microcenter usually has the base zero Ws (no accessories) on sale for $5 and there's a limit of one per customer.

They are available from Amazon,
Adafruit: https://www.adafruit.com/category/175
Microcenter - there's one near the Cincinnati Ikea - http://www.microcenter.com/search/search_results.aspx?Ntk=all&sortby=match&N=4294910344+4294819333+4294818915

And probably Fry's.   I think I've seen them at Target and Barnes and Noble in the past, but that's been quite a while.

Anyway ...

There is a ton of information at the Raspberry Pi foundation's own site: https://www.raspberrypi.org/  but here's a little overview anyway:

The 3B+ has 4 USB ports, a full size HDMI connector, 4 cores and twice the memory.
The Zero costs less and is tiny - a little bigger than a pack of chewing gum.
They both have wifi and bluetooth.

Size wise, the Pi is something like 85x23 mm, or about 3.3 x 2.2 inches if exercising your birthright to imperial measurements is a thing you're into

Oh the perils of mixing measurement systems

https://imgs.xkcd.com/comics/lightsaber.png

Anyway, the Pi was created because the boffins at some really impressive university in the UK discovered that school aged children didn't have the experience with both hardware and software that earlier students did, and in turn that made filling their computer science classes harder than it should be.   Rather than moaning about it, they created the Raspberry Pi foundation and designed their own.

They're mostly made in Wales, home to some truly astonishing town names.  The video is an hour long, so you might not want to click the link:

The Pi uses a pretty nifty Linux variant, and don't panic if you've never used it before.  The instructions for how to install it and get it working are on the foundation's page (Adafruit also has a lot of Pi info) and it's not all that complicated.  The foundation's site even has a page to help guide parents through the trauma: https://www.raspberrypi.org/learning/parents-guide/

The software packages included in the base OS change a little from time to time, so I won't go too much into that here, but they usually include some Java and Python development tools plus something like Scratch and they have included a lightweight version of Wolfram Mathematica as well.

 I have no connection to any of the links provided here, and can't make an official endorsement, but I've bought and given away several and have 2 or 3 hanging around now that I use for playing around with different OS's, ways of programming microcontrollers using the IO pins, that sort of thing.  I'm thinking about seeing how Jenkins works on one for my next experiment.

It isn't perfect by any means, but despite - or because of - its incongruous nature the whole package works a lot better than you'd think.  And like these guys from Finland, I'm actually a little thunderstruck.

"Code to Joy"

Ludwig von Beethoven “The thing that gets lost,” he says, “and which I think is important to know, is that programming is never easy. You’re never doing the same thing twice, because code is infinitely reproducible and if you’ve already solved a problem and you encounter it again, you just use your old solution. So by definition you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.” - Quincy Larson, quoted by Andrew Smith in https://www.1843magazine.com/features/code-to-joy Information is where you find it, and if you go looking for articles that require a little thinking they have a way of finding you.  Case in point: I'm not a regular Economist reader (1843 is a cultural offshoot of the Economist), but this article by a journalist who decided to learn to code bubbled up on my news feed one day. I read it, and I'm glad I did.   Ode To Joy is also the fourth movement of Beethoven's Ninth (which is why he gets a cameo), and the Code to Joy title seems to me to reflect the way that dedicated and skilled professionals feel about their life's work.  It may play into the interfaces necessary for making a symphony work, but I didn't read that much into it. Anyway, this sentence really stood out to me "...you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.”  It sounds kind of sporting, doesn't it?  It is, but that's why we love it.  There's always that little hit of adrenaline that kicks in because we don't absolutely know what's going to happen next. Let's pull back a few klicks and challenge a word we've gotten too comfortable with.  Mathematics is no more just arithmetic and geometry than "Life" is last night's leftovers and mowing the lawn.    Computer science, it may surprise you to hear, is applied mathematics.  I usually say "an applied mathematic" but that's just to emphasize the point, because the real experts like to fight over whether "applied" or "pure" mathematics is better.  I think it's kind of a dumb argument. https://xkcd.com/435/ Math is funny stuff for both the pure and applied mathematicians with lots of ties to music, language, philosophy, and logic.   In fact, a big chunk of a math degree (especially pure math) once someone finishes the calculus series is how to use that logic to prove things called theorems. Here's one: "if group A includes all the pasta types, and group B includes all marinara sauces, then every pasta meal has marinara sauce."  A Skyline chili just blows that away, and the disproof - the proving it false, is both tasty and trivial. The point being that some things are easier to prove than others, and most of them depend on some sort of assumptions and definitions we make along the way. Parts of CS (Computer Science) are a really peculiar fusion of the pure and the applied - the code must do something, so it is "Applied Math," but it is subject to theoretical constraints and proofs, so it elbows into "Pure Math" too.  Consequently neither type of mathematician totally trusts CS, at least until they need a job.  (My background is a mix of applied math and CS, so I catch shade from everybody.  :-D   ) You might have guessed that proving things about code is where we're headed, and you'd be right.  You can just whale on the code until it's bludgeoned into something like cooperation, but this is horrifying.  Yes, you get this wobbling object that trots itself partway across the field (yay! the robot works!!) but then it disgorges its bits and bytes in a public and appalling display of the perils of illogic (wow, what went wrong with the robot and can you fix it in 5 minutes?!).  That's no fun at all. If you'll indulge me the source, once upon a time a Roman named Paul wrote "all things are legal; not all things are profitable" and the blunt force method is ... unprofitable.   You see, after you put down the clubs, hammers, and open flame that method relies on, someone else is going to have to make a change to that dented and quivering carcass of logic, and they will either break it, or break it and soundly curse you and three generations of your heirs as "the reason we can't have nice things." There are better ways. I've been doing this for money off and on since Reagan was president, and in between waiting for Windows, waiting for compilers, waiting for ... you get the idea, I've had some time to contemplate and some time to read the evolving theory of this science.  I'll be darned if we don't agree - 1) the fastest, cheapest way to make code is to do it correctly. 2) it's called the correct way because it is the fastest, cheapest way to make code. 3) if you want it to stagger to a collapse right when you need it most, do it the blunt instrument way. I've posted earlier that the hard part of making software is not the little pieces of logic that make the individual things happen.  The hard part is figuring out which little bits you need, how to make them play nicely with the other little bits, how to write as little code as possible, and how to reuse as much of what you do write as you can. Another hard part is how to get to where you believe what you have might work.  There's a difference between actually believing it will work and saying "if anything's going to happen, it's gonna happen out there."  We're supposed to be training the students, after all. If you can sniff out a bug before you ever compile or download it, you've saved some time.  Do this enough, and you get some freed up practice sessions where you can work on other, more interesting problems. A good lint tool can help with both of these.  Here's a picture of some team code that's been linted:

Notice on the right side there aren't may little yellow lines.  Most of our code files have 20-50 or more lines of various colors - every one of which is a Lego on the floor of our code, just waiting for us to step on it in the middle of the night. Could be a piece of data that's defined in the wrong place, an improperly defined class, or a variable that is never read, only set because it's name is really close to the one we meant to use, could be one of a hundred different things.

So for the mentors, we really do have to resist the temptation to start slashing and burning our way through the jungle of this year's competition, we really do need to help the students start thinking about the design early and how they're going to communicate it among themselves, and just as importantly, how serious we're going to be about driving out those endless annoyances of "incorrectly scoped variable," "variable declared but not used," and "code never reached."

I'm hoping "Very Serious."

In the last post I discussed using Sonarlint - which I still like for a couple of reasons. I spent a day last holiday break going over 3.5 of our team code and actually learned quite a bit about Java conventions and was able to deduce why they exist.  Sure I questioned the wisdom sometimes while I was doing this, but when I finished I looked it over and it really was tighter, easier to read, with less wasteful code.  And if it looks like that to me, it's going to look a million times more like that when we shove it into the microprocessor to run "hot."

 To install it in Android Studio select the leftmost pulldown, then from File -> Settings -> Plugins -> "From Repositories" then scroll down to find SonarLint.  Here's a picture of my menu screens for this job:

Here's a link to my github of our team code set up for the 3.5 FIRST release.  We'll probably have to make some small changes to connect our team code to the FTC code for 3.7 or 3.8, but the team code wouldn't need to change much.  https://github.com/50N40W/KP35-Bravo

To close out in a full circle kind of way, here's another take on "Ode to Joy"

Mambo #5 - A little SysAdmin in my life

I believe this is Season #5 for FTC Robotics in Columbus ... that's kind of hard to believe. It's also why we put a #5 in the post title.

Anyway, we have some tech chores at hand, so let's discuss.

If we get new computers for Robotics this year, we’ll probably find that they have no OS.  This communication is to describe the desired configuration of our s/w computers for maximum portability and service with minimum needed maintenance.

What follows is pretty close to what we’ve had the last couple of years and it works predictably, updates are knowable and controlled, and overall system stability AND portability is excellent – runs on Pentiums and CoreI5’s, and VPro’s with 2Gig and up of RAM and ~40 gig and up of disk.

Obviously don’t download any of this onto your work machine.

Desired Configuration:

Distro:   I really cannot emphasize this enough, but we *must* have control over when system updates happen.  WE CANNOT LOSE OUR WORK DUE TO A BADLY TIMED UPDATE FAILURE.  That kind of risk is for people who roll the dice with Redmond's product, and we have some higher standards.

Anyway, here are the options I'm willing to help with.  Sounds curmudgeonly, I know, but I'm pretty sure we can keep 4 machines running and in sync with this setup. I don't feel like spending any extra effort on this kind of overhead, and it keeps things simple and reliable.  And cheap.  And simple. I said that twice, because it is twice as important.  

http://bbqlinux.org/ (not really preferred, but the fastest install I know.  If you're pressed for time, this might be a good call) BBQ Linux (NOT LinuxBBQ)

• Pro: Has Android Studio & a workable Java included as part of distro.  Setup is pretty simple.
• Pro: Arch gets you more hitpoints of nerd just for saying it, let alone using it.  Depending on your view, this also can be a Con.
• Con: is Arch based rather than Debian based.  Works fine, just uses a different repository schema.  With the pi's and other things, I'm more used to Debian and apt, but I kind of like the extra geeky aspect of Arch.  It is to Linux itself as Linux is to Mac or Win.

PREFERRED  

 XUbuntu (Not Lubuntu, Kubuntu, Ubuntu, or any other ‘buntus).  I believe XUbuntu works OK with UEFI (the MS-inspired denial of service boot obstacle – I’ve not tried installing GRUB on a recent piece of hardware). Plus 'buntus are the "hello world" of Linux, and that's not necessarily a bad thing.  XUbuntu is maybe the "hello world" of the 'buntus.

• https://docs.xubuntu.org/current/user/C/index.html
• The XFCE window system native to XUbuntu is clean, low overhead, and functional.
• XUbuntu (historically) allows you more control over both the schedule for updates and the password/username to a greater extent than other ‘buntus.  We do NOT want the OS to upgrade automatically the week before a tournament. You wanna do CPR on Android Studio because some tool incompatibility bounced into your lap and 'sploded, that's your problem.  I have plenty of baggage without that.
• Computer Name: The name should be something unique and yet appealing to a nerdy teen.   Just don't make it boring.  Have used variations of person’s name who donated computer (Bartacus, Ziggy, MagiCarp) and for corporate donations once used names of ships in Patrick O’Brien novels that also existed in the Royal Navy (Surprise, Lively).  Should be a consistent theme. If using planet names, could make the background a picture of that planet so it can be identified from even a distance. Prolly should skip Venus and Earth.
• Post install, run from command line: %sudo apt-get update      --This should update the repository lists.
• Post install, also run from command line: %sudo apt-get dist-upgrade –This is to ensure the software is up to date.  Will take 5 minutes to 40 minutes to run, depending on available bandwidth and time of day.

I’d love to experiment with Rasperry Pi’s Pixel distro, but don’t recall if it is 32 bit or 64 bit and can’t be bothered to look right now.  We need the 64bit OS.   Pixel looks very much like the Raspian distro for a pi, except it does not include Wolfram Mathematica.  OTOH, it ought to be familiar to some of our students and an excellent tie in to inexpensive machines they’ll have access to at home (a Pi 0-W is $10, probably figure $35 plus a keyboard and mouse to get one up and running on your HDMI monitor.  Pi 3b+ adds 3 cores half a gig of RAM and about $20 to that. I really like the idea of presenting a system that looks very like one they might reasonably get to students from a fairly frugal economic circumstance).

Accounts: historically we’ve used judenki, but this year let’s do “robotics” (We'll have to coordinate the password.  I'm not putting it here :-) ) … can make it automatically log in, but must do password for sudo.

Android Studio – whatever is current.  It’s a derivative of IntelliJ, so any web instructions you find for IntelliJ should work fine for Android Studio.

• configure SDK’s for Nexus phones.  Check the FTC message board for instructions.  Or copy from one of the PS3’s.
• With updates and configuration, this may take an hour or so to install.  
• As I recall, you can install Android Studio in the user directory but it's messed up - a little like putting your socks on over your shoes.  All the stuff is there, but it's cringably wrong.  We can discuss.

Android Studio Plugins

• Git  https://javapapers.com/android/android-studio-git-tutorial/
• Sonarlint  https://www.sonarlint.org/intellij/   I really would like to see the software students use lint in real time.  It's hard, but I had a lint fueled wilding over our code during the holidays last winter and by the time I was done, it really was tighter, sturdier, and better looking code.   Ugly code, you'll remember, is a venial sin in some places, a mortal in others.

Java

• XUbuntu should come with either Java or OpenJDK.  OpenJDK is rumored to have some compatibility issues. We want Java. Can download it and tar or use a file manager to extract it (should be done with root priv) we want Java 8  64 bit!
• Java really needs to be installed in /opt or /opt/bin (I forget which one right now)
• There is a little bit more configuration work that needs to be done for Java, like added to /etc/sources maybe?  
• You'll need the JDK and the JRE as I recall.
• https://www.java.com/en/download/help/linux_x64_install.xml

Git

• Need it.  %sudo apt install git-all    

Get all this in place, and we can fork our android studio project from github and copy onto the laptop in question.  That’s a whole different set of problems,  and I still need to do some prep work for this season on that.

Finally, here's a little video that pays homage to the title of this post.  It's hard to find a squeaky clean cover of Mambo #5, so we'll add a little Beethoven to our song.  It isn't precisely what it seems, but you should expect that by now :-)

Sixty miles in latitude, three hundred to the main

Only five more months until we can binge watch season five of Robotics, and each year I think about this a little differently and a little earlier.

The Campaign Boards from a couple years ago

This year I'm trying to figure out how to make it easier easy. Well, easy-ish.  See, here's the thing, bad software is both difficult and ugly.  It's ugly because it's difficult, and the difficult makes it ugly.  A tautological knot to be sure, but write some pretty python code and it should make a lot more sense.

Anyway, a lot of stuff doesn't bug me, but ugly software freaks me right out.  (wow, that feels good to confess).

I've often said that the two hallmarks of a competent engineer are enough arrogance to think you can do something no one else ever has, and enough paranoia to disbelieve it works until it's retired and all the copies are destroyed.

Good software helps both facilitate the arrogance and ease the paranoia, and what's hard about making software is nurturing the underlying brainwork before writing anything.  The yeast has to rise, the meal has to digest, the egg has to be incubated, pick a metaphor that works for you.  It's always tempting just to start hammering out code without thinking of how the logic and data flows intertwine, but that's the surest way to make ugly essays and ugly software too.

Meth lab in a monkey-house ugly.

Don't get me wrong, the complicated fiddly bits are always complicated and fiddly, but they're basically parlor tricks - after a while there's a sameness to them.  Think Gandalf making fireworks.  (In my defense, I did say great arrogance is essential).

The upshot is that in two or three weeks, I'm going to be pinging some people (some of whom aren't reading this so don't know that it's coming - bwahahaha!) for some help planning and divying up the work so we have the robotics code we want by the start of August.

Like I said in an earlier post, it is not possible to teach 7th graders enough coding so they have a fully functioning (or partially functioning) 'bot by the first competition. 

Given that, here's a preview of what I think we ought to hammer out in the off season.
1) set up a rudimentary API for autonomous mode
2) create classes and objects that support the minimum possible amount of software we need.  Fellow engineer Brad once stated the best comment he ever read was "I'm sorry I ran out of time to make this shorter" and that, my good people, is the pithy soul of wisdom.
3) get something in place to support vision recognition.
4) formulate some sort of training plan for our freshly minted software team members.

There are a couple more things, but I want to spend some time with my head tilted back, letting the frontal lobes run a little lean[1], and contemplate the order of battle a little longer before commenting.  Good ideas, like good digestion, cannot be rushed.

 And since I've been thinking of re-watching Ken Burns' Civil War series, here's a Korean version of "Marching Through Georgia" (a line from the original is this post's title) to close things out.

[1] gratuitous reference to Henry Mulligan of the Mad Scientists' Club (https://en.wikipedia.org/wiki/The_Mad_Scientists%27_Club)

Loose Thoughts About Time

 In the last post I mentioned feeling that the phones were good to plus or minus a few milliseconds on a 50 millisecond loop.  I don't have any hard data on that, and I'm not really in the mood to go play alien autopsy on the robotics innards with a probe and a scope.

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 first picture shows the basic setup.  Using a cobbler from Adafruit (This is NOT an endorsement, but it works and here's the link : https://www.adafruit.com/product/2028) and some generic LED circuit from I don't remember where,  I added the following Python code.

On a side note, there's a gyro or a BMP280 or something, a potentiometer, and a humidity sensor also on that breakout board.  We'll get to those some other day. :-D 

Anyway, it's crude and ugly, but sometimes you just gotta let your hair down - metaphorically of course - and beyond here be pythons, or at least a screenshot of the useful part.  I put it in as a screenshot because I like the darker theme for IDLE.  I think I used this one, but it's my own hardware so I didn't document it.  Link to dark theme: https://gist.github.com/dsosby/1122904 .

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. 

Remember, the Pi and our Phones are roughly comparable - typically an ARM processor running a Linux derivative at around 1GHZ.   

Yeah, I'm not actually satisfied with the experiment either, and yeah it's going to bother me. 

The "righter" way, of course, is to do what we have in our robotics code and let it lounge around in a do-nothing state until 50 milliseconds elapses then set a physical output and watch it jump around on an oscilloscope.  Then keep shrinking the time until the error is large enough to be a pain.  This might be a fun thing to do with our students in between seasons, but even with what we have, I'm a little more comfortable believing we shouldn't really trust our hardware to be both accurate and precise down to 1-2 milliseconds.

2017-2018 FTC Season Recap - "für dich ist der Krieg vorbei"

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."