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!