The students have been working at it diligently each practice with some tweaking from the mentors. If we maintain the discipline described by this structure, we should have a tight, tidy, easily MODIFIABLE, easily MAINTAINABLE, and EXPANDABLE set of code for the remainder of this season.
All depends on our discipline of recognizing that getting INPUTS, while a simple task, is different from doing SOME ALGORITHMIC THING with them, which in turn is very distinct from WRITING OUTPUTS. This is the heart of functional cohesion and forces us to think about the robot's tasks atomically, and that in turn leads to smaller, simpler pieces of code that we can have multiple people work on simultaneously.
It is really tempting to go ahead and drive the motors as we read the stick commands. But that collapses the instant you want to make a more complicated widget. Part of our goal, after all, is to instill solid software engineering values in the students. ... and complicated widgets are cool :-) .
(mini rant:) We have the same obligation to teach and respect functional decomposition and functional cohesion as an architect does to keep the kitchen and water closet separate rooms even though they both involve flowing water: the ease of plumbing is outweighed by the pain of having guests rinse their toothbrushes in the colander. (/rant)
While I'm on the boil, we ABSOLUTELY must guard against is the use of "wait" or "sleep" instructions. There shall be only one "While" and it is "While Opmode is ACTIVE."
Putting a sleep statement in our code forces us to read our data every time we want data. We end up with lots of reads and can get things out of sync that way. I really value stability in an embedded system. Stability and predictability. If it's predictable, we can do darned near anything.
Code really isn't that different from an essay - we take big complicated ideas and break them down into progressively simpler ideas. If the subordinate ideas are too complex, or if they wander around, the teacher/prof will compel you to keep each paragraph cohesive. Same deal here: By putting our logic into "services" we make the timeliness of it predictable.
Here's a rough overview of this year's code for both teams. The blue block in the middle is called "Nav" because it was late and I was out of ideas. Anyway, each of the 5 main blocks (plus one for read encoders and another for write telemetry) gets pinged every so many milliseconds (30 right now for everything except telemetry which is going out every 1000 milliseconds). Including comments, we have about 400 lines of code so far, but expect that to double between now and this time next month.
 | ||||
| Juden Ki / Kernel Panic Baseline Controls |
**********************************************************************
The following code was added Saturday afternoon;
- A limit to forward and aft speed of the robot to +/- 0.5 while the lift is engaged
- A crude PID algorithm to hold the lift at more or less a constant place while the lift is engaged
- A debounce so that the "LIFT" command has to be asserted for 180 milliseconds before it will be acted on. Basically, we read the button, then increment a counter. If the counter is >= 6, begin lifting. It goes up to 12. Thus to release the counter, it has to be off for 6 times also (at 30 ms each). This may be overkill but should help with a flaky controller or a messed up connector. The time constant is really is a defined constant, so it's easy to change (all the way to zero, if you like). It sounds more complicated than it is.
- There are constants for each service's period, the duration of the lift, the default and closed positions of both servos, etc. Change things ONE place, if possible.
I discussed with Leo how we ought to be able to use most of the same code for autonomous. Ideally we'll split the inputs into their own class. I have a couple of thoughts on that, and will work on those over Thanksgiving if time allows.
The "good" code is on both Barticus and "Lively" and in the two github repositories for the teams.
I've pinned them to the top of the JK github page, which should make things a little easier to find. Anyway, here's the link to JK's file as it exists in github as of noon today (the url is bigger than the text):
https://github.com/judenkirobotics
*********************************************************************
I've also created a couple of aliases on both Barticus and Lively. One's the HP and the other is a T410. These are the main machines we're using at the moment. JK uses Barticus mostly, and KP mostly uses Lively (the T410).
"gotocode" from the command line should take you down into the team code on both the JK and KP projects. "teamcode" from the command line is generic, and will take you from the first level project directory down to teamcode.
I also turned off the Android Studio popup bubbles. I saw one of the kids hit the "update" last Wednesday. Somebody updating something the week before a competition can wreck us. Less painful is the update takes the whole practice, or gets halfway done and times out, leaving us with an unusable system.
Speaking of which, there is an FTC 3.5 version out. I've read that it has some initialization issues. Hmmm. Let's see if we need it. Right now we don't have the whole 2017/18 projects in git, just the team code, so it should be a little easier to try than it was before ... especially with the aliases I created. Which is kinda why I did it.
Since I'm feeling especially wound up about solid software philosophy today, I'll close with a quote I've seen attributed to John W Gardner:
- "The society which scorns excellence in plumbing as a humble activity and tolerates shoddiness in philosophy because it is an exalted activity will have neither good plumbing nor good philosophy: neither its pipes nor its theories will hold water."
No comments:
Post a Comment