Been meaning to do a write up on rebuilding a programming team from scratch, might as well write this up to organize everything before our post-mortem tomorrow. Sorry if this is a bit of a mind dump. I know programming teams collapsing is not a regular event but can be quite devastating to teams, so hopefully something here helps some team out.
For context (TLDR everyone programming last year either graduated or quit except Joey who got elected to be “CTO”), last year I was a rookie electrical sublead as I (as a Junior) joined with prior experience in both elec and prog but saw that electrical seemed to need more help and that I didn’t want to do Java. Through the season electrical got more new members as programming struggled to teach their rookies and had a bit of drama that is out of the scope of this writeup. To sum it up, by the start of this school year everyone but Joey who was elected as CTO.
Long story short, in two weeks we went from a programming team of three consisting of another elec person, and my friend Eyal who I convinced to join, to having over a dozen people. Now of course about two thirds of those people had never programmed Java before and had all almost exclusively done solely Python. My first decision was to basically dedicate Eyal who I knew was a pretty good tutor, to essentially try to teach a condensed AP CS curriculum to all of them. This was a large burden and I have to say he did a good job with this, as by the start of build season they were able to program a drive train as a group.
In parallel during training season I basically focused on learning WPI Lib and teaching what I had learned to the third of the members that did know Java (including a couple who only knew C# but quickly adapted to Java). There was a bit of debate over ROI on setting up sim and having students learn from it, versus setting up Romis. In the end we did both with two Romis ordered and setting up simulation for our drivetrain. In retrospect the sim payed off very well and kept the rookies interested as we couldn’t all share the one practice pancake bot we had, but the Romis were a waste of money as we could only secure one RPi from mentors and at that point it wasn’t worth being set up separately.
In terms of how I taught everyone, at this point it feels more like a blur and I wish I kept some record of my progress, but essentially I’d look through last year’s code and either find something I didn’t know (like command based programming), learned it, and then taught it the next day, or I’d find something from last year that I found to be suboptimal (like the commit messages or the file/class names) and made a lesson or two out of it. If anyone has to go through this the WPI docs really are your friend, and don’t be afraid to send out “reading assignments”.
During build season I immediately programmed a basic skeleton or MVP of the specs I was given. We spent the next two or so weeks working on auto with the bot (write up on that is above so I won’t go to much into it, except to give my thanks to 948 again for helping us figure it out). My takeaway from that was that you should always dump as much data to Shuffleboard as you can during dev and to always make sure the values are sane in terms of direction and order of magnitude. You don’t need to make sure you’re precise ±0.1mm during dev, but you do need to make sure the bot doesn’t think it’s moving -500m when it moves 10cm forward! After we got balance working with the practice bot I essentially had the team take a break until we had a physical robot to program. Another takeaway is a strategy I learned when dealing with the amount of people we had was to split people into groups working on the best thing and take whatever group’s code works the best.
Now perhaps it was selfish of me, but this is where I went from almost being a “mentor” to fully taking over. I wanted the code to be perfect so I adopted a strategy of asking rookies to do things yet having my own code to go with when we they had given it a good try. It still feels a bit wrong to do that but I think it was a good trade-off to let them learn while still keeping us mildly on target.
Now we really fell behind with elevator and arm control, PID seemed to just not work and in retrospect I was too afraid to raise P by too much so we tuned at a snails pace. Honestly just pump up that P more and more.
My proudest part is that we arrived at Bonney Lake with no auto code, but because we made our arm/elevator command based I was able to write code on the bus to score a preload, and then we used the practice field to make a very cursed timed move for auto mobility points. Timed auto may be cursed but it sure worked!
Anyway if you’re still reading this, or skipped to the bottom to see if there was anything interesting, my key takeaways:
- Simulation is great, as an alum I plan on helping out the team by combining our existing drive sim with some sort of elevator or arm sim as it’s a great way for new rookies to get immediate feedback on their code without having to use a real bot! - Romis are not so great.
- People working in groups are better than people working alone, we had problems with people being afraid to ask for help and at least in a group they’d work together and learn from each other.
- Might not have bot early in build season but that’s no reason to not have some basic code skeleton.
- When tuning PID: go all in, if you’re afraid of breaking things, set up some “clamp” of a reasonable area of movement and make it stop if the mechanism goes out of bounds, then just go ham with your P value until you see oscillation.
- Write command based code in a way that you can combine it into an auto in less than an hour - Timed auto may be cursed, but better than no auto!
. Perks of this is around .5" of clearance missing over our battery mount that I now have to add in for the elevator so that the battery can be properly inserted. Please please please let me know if you see anything that looks wrong as it probably is and I just didn’t notice it lol.
