Software Team 2017 10 25

Wednesday's practice was ... loud.  But we survived.

Here's where we are, and it applies to both teams

Configuration Management:
Howard forked the ftc app from the FTC github, then added an opmode containing the new time-domain based code.  He then went back to the judenki github and forked the ftc app from his account and created a JudenKi branch.  This was downloaded onto one of the laptops, opened in Android Studio, and "built" but not downloaded.
At Wednesday's practice we had the students create a KernelPanic branch (see the pic below) and downloaded that to a different laptop.  Now we have two branches of the same fork, and we should be able to have the students develop in each of these independently and keep the branch updated independently.

In theory, we can then merge the branches into the "master" and keep everything updated together without the hassles we had last year.

Each team then created a Teleop version of the opmode in their own branch - (we discussed the distinction between Autonomous and Teleop), added it to their project, commit the changes, then try to push them back up to github.   We were bandwidth constrained, and that just didn't work.  I don't know if everyone is using the wifi to watch Spongebob covers of Aerosmith videos or what, but Howard took two of the laptops home and will do the github pushes before Saturday's practice.

We also discussed the importance of viewing code as a "data pump" where data comes in, things happen to it, and data goes out.  Our pump works best if we think pretty hard about what we need that data pump to do as we design it.

A WORD ABOUT Time Domain processing:
We have ONE loop, and ONE place to look for "whileopmodeisactive".  This should prevent some of the spinning/no-shutdown or whatever again this year.
PLAN FOR SATURDAY:
1) may need Jim's input, but want to add a Drive class to each and put our common software in it.  We can probably keep this coordinated with some good old cut and paste technology, but ... we shall see what happens.
2) create a "controller input inventory" form ... so when we start adding driver control functions we'll have a documented map to start with ... we have about 20-30 possible inputs, and that provides a huge number of combinations.  If things get hectic in C-2 ("C minus 2" or 2 days before a competition), KNOWING what buttons have been assigned keeps things mas tranquillo (more calm).
3) want to start adding the things we need to make it drive autonomous.  Will need to get a preliminary sensor inventory and will put some students (Propose John and maybe Ethan) to start working up an algorithm for accumulating wheel encoder counts.   I would like to be able to continue reading sensors every 50ms while the thing is turning, and I believe the included method only allows you to command a turn of a certain distance or duration - which it does while in a really tight while loop of its own (meaning nothing else happens during that 1-3 seconds).

I think that may be ambitious enough for Saturday.  If we get all that done, we'll give some instruction on theory (maybe some object oriented stuff?  Maybe some UML with Bluej?   We'll figure something out).

See you Saturday!

FTC 8578 and 11959 Software Mentor roles and description 2.0

(revised 11 Feb 2018) 

What we need from software mentors ... a simplified version.
This, once more, is my personal vision, and does not reflect that of Columbus FTC or any of the mentors - unless purely by coincidence. It also obsoletes and supersedes an earlier, vastly more complicated version.

In general, our need for mentors is as follows:

Team Mentors
Each team, whether there are 1, 2, or n, needs a dedicated mentor to supervise the software development for that team.

Auxiliary Mentors
 These individuals are useful in many roles. One hopes that they'll work with the students and with the software and grow into "full time" mentors. "Full Time" has no rigid definition, but practically it means making 7/8 or more of the practices.

Computer Setup Tasks
One of those mentors - or a separate one - should accept the following responsibilities - before September, and evaluate the need for an update in mid November and again over the Christmas-New Year's holiday:

1. make sure the computers have a common or at least similar OS
2. make sure the version of Android Studio is correct and that Android Studio is configured correctly.
3. make sure all teams are using a legal and servicable version of the FTC software

Architecture and Training Tasks 

An astonishing percentage of the people I've met who style themselves software architects have huge troubles designing the code equivalent of a privvy, to the point where I'm reluctant to use the term. Regardless, a member - either the one above or a different one needs to ...

1.  keep on top of the configuration management schema. This takes constant effort, as it gets ignored almost instantly. This means helping make sure that commits are done at the end of each practice and that pushes to github are done often enough to make the catastrophic failure of any given computer a non-event.
2.  Keep on top of the architecture. To succeed, that is, to add the most value to the students, they need to spend their time thinking about the difficult problems and not chasing down 16 instances of the same bug. This in turn means that we have to leverage some of the object oriented properties of Java. 
3. Provide training in Linux Command Line, Android Studio, Java, principles of systems engineering, and basics of software engineering. For example, it is profoundly useful for the students to understand how long is 100 milliseconds, some of the basics of how geometry and algebra apply to making the robot do what we need, and on up to some rudimentary PID controller, first order filter, and other things of that ilk.