Creating, supporting, and developing programmers and teamwork

[n3rdchik]

So, I have found myself one of two mentors on the programming side of the fence. (Darn my spouse and his adorable puppy eyes asking me to take on programming) The other mentor is highly technical, but has no patience for beginners or any of the basic bits of programming. This is probably an off season thing, but welp, its Dec 20 and we are going to learn during the season now.

• How do you appropriately train/challenge newbies/freshman?
• What tasks do you give them?
• How do you manage the different amount of help/skill?

Any help on how you organize your programming teams, foster resilience and sustainability, and avoid “the best programmer does everything and everyone else just hand waves” issue would be greatly appreciated.

I’ll be over here knocking dust off my college programming books. I am not a programmer, nor do I play one on TV, but apparently working in IT (Data and Databases) is the next best thing.

[wits]

What is the make up of your programming team (how many students and what is their experience level)? That can affect the answer of what your short-term plan needs to look like.

Have you chosen a programming language and an implementation (command vs. not command)?

I guess we train new students in the Fall which isn’t really an option for you. The way our code is structured there are many tasks of varying levels. So the new students tend to pick up the easier tasks whereas the experienced students pick up the more difficult tasks.

One technique that I a have found works well is to pair up students. This tends to help them resolve issues together (sometimes when they don’t know what to do, they don’t ask questions and if you have enough students, you may not realize they are stuck and with 2 of them, usually one is willing to say I don’t understand where when they work independently sometimes the new students, in particular, assume they are the only one not getting it).

[n3rdchik]

Programming in Java in the VSCode IDE. Most likely using command based, as that is what our legacy code is.

Programming Team Make Up:
I have one advanced level Senior. 2 Juniors who are advanced beginners and are active in other teams, so minimal time with programming. 6 freshman and sophmores with basic beginner skills. About 50% have some code experience, but none on a robot.

We will definitely do the pair up. which gives me 3 or so team/pairs. My main worry is that if we pair my senior with one of the Juniors, I’m still single threaded in wisdom and experience next year. Maybe do two-three teams of three?

I’m also inviting local robot programming experts ( Thank goodness I’m in Michigan! @LoganKippnick and 6081 are right down the road ) and finding out their favorite drinks and snacks to lure them occasionally to our robotics center

[apotato]

My team usually does groups of two or three students per computer, for reasons others have stated and a lack of laptops with wpilib on them. If you have an old robot wired up reprogramming some of it could be a good exercise for new programmers before the season. We have our programmers integrated into our prototyping teams for the first few weeks so we better understand what we are trying to control, so depending on how/if your team does prototyping you might want to have a group of two programmers attached to each mechanism, and have them focus on making that one mechanism work.
EDIT: If you want any help with programming feel free to dm me

[wits]

You can try three person teams (I’ve never tried it with robotics). It would probably work, though.

I’d probably make three teams as follows:

• Senior with 2 freshman/sophomores
• Junior with 2 freshman/sophomores
• Junior with 2 freshman/sophomores

That splits up your experience to help the younger/less experienced ones. You may need to work closer with the teams that have the juniors since they are active in other sub-teams.

I’d give each sub-team a mechanism (subsystem with commands). If the more experienced one can write the subsystem and the harder commands – at least initially – the others can come up to speed on the easier commands.

Assuming you make your code publicly available before kick-off (if it isn’t already), you can re-use things such as drivetrain (assuming it is the same as last year).

Since you will be learning/training during the season, I’d recommend not biting off complex things (at least initially). Focus on getting the basic robot up and running and then add to it. If you have the resources (money/materials and people), I’d recommend getting a chassis bot up (hopefully matching the comp bot chassis as possible) and running for the software team to test on (make sure drive works, get auton paths working, etc.). No matter what the game is if your drive isn’t robust, your mechanisms won’t matter. So make this rock solid and this is something that can be worked on early on. In fact if you are bringing drive code from a previous year, this is something that you might be able to get your experienced programmer to set up and then have younger ones test it out as well as start mapping your drive paths for auton. If you don’t have code that you are leveraging, I would definitely have your senior involved in this one.

You can even put it on blocks and test your mechanisms (e.g. assume this motor is the intake motor and make sure it runs). The other thing you can do is set up the simulator on your computers and run that way to test before you have a robot. The key is once you get the robot, being reasonably confident your code will run, so you don’t spend a lot of time debugging/fixing simple problems – you’ll have enough big ones to solve.

If you will be using CAN devices, I’d have your team get familiar with the Phoenix Tuner if you use CTRE motor controllers or the REV Hardware Client if you use REV motor controllers (our team, in fact, has the electrical sub-team run this to make sure the wiring is correct before turning it over to software.). You can use these to make sure the motors are going the correct direction and even start playing around with closed loop control constants (I’d definitely get all of you mechanisms working in open loop before getting them working in closed loop as you can start to see how fast something needs to move if it is going to be in velocity control or what position it needs to be at if it is in position control by moving it manually).

Yes, it is a good thing to be in Michigan with the density of teams. We are up the road in Lake Orion. While we run C++, we do have Java knowledge, so if there are things we can help you with let me know.

[Jacob_S]

From the perspective of a student:

Yes! Teams are great, getting students to bounce ideas and problems off of each other helps so much.

How to train newbies?

IMO its a great idea to give them a chasis, last years code, a more senior member, and the WPILib docs website on drivetrains & API docs. This helps teach them to read Docs, which is very important in creating independent programmers that can find answers on their own. It also helps senior members teach new members existing code, and the simple ropes.

I struggled a lot with these two things when I first started FRC, not knowing where to look for answers, and not understanding existening codebases.

What tasks?

Start small. I know my mentors started us off with giving us a function during build season and saying “here, it should have this input and this output, can you make it happen?” And breaking up the problem like this helps so much. Plan out subsystems, and create functions while leaving it up to students to produce the correct output.

Also pro tip: familiarize yourself deeply with git, and github and take advantage of the Github Projects feature, this makes it easier to distribute and manage your tasks accross programmers in a centralized way. (By assigning tasks and having advanced project management, this also helps mitigate the top dog from doing everything)

Another thing that confused me as a new student was no one ever taught me that different vendors individually contributed their own libraries, so make sure to familiarize your students with what your project depends on.

On a final note: with being crunched to build season, finding practical examples and teaching them how to write (simple) subsystems and commands step-by-step before teaching any advanced computer science theory may be beneficial.

[char]

I strongly agree with @wits & @Jacob_S recommendations, especially about creating subsystem teams composed of veteran student leaders and newer “still learning” members. His advice mirrors how I mentor our team’s programming sub-team.

To add to their advice:

1.) I would recommend you pursue MVP (minimal viable product) software first. Get something that “just works” first. Doing so will help relieve much of the stress on programming. Once you have an MVP for each subsystem, you can build in more complex control approaches.

2.) Hold “stand-ups” with your programming sub-team at the beginning of each meeting. 3-5 minutes top. Stand in a circle and each person either states what they plan to achieve by end of that meeting, or else you (or your student Programming Lead) assign them a goal to achieve. (We adults tend to forget, but “deconstructing problems into smaller achievable pieces” is a skill that is learned via experience and students are relatively new to it.)

3.) At the end of each meeting, hold another 3-5 minute standup and everyone reports their status/progress.

4.) Request from your Design/Mechanical sub-team a list of specific motors, sensors, and understanding of how the subsystem should work, for each subsystem. Convert how “it should work” into a State Diagram for your programmers. Have your programmers then learn how to communicate/control with the specific motors & sensors. Once they’ve done that, have them introduce control logic. The control logic is what determines whether or not you change the state of a motor or sensor – ie, it controls/decides when and why you transition from one state to another, where “State” is just a collection set of motor speeds, sensor settings, etc. Around week 4 your Design/Mechanical sub-team should have at least some prototypes that your programmers can work with to then begin to fine tune the motor controls/sensor comms/control-system-logic. Rinse-and-repeat. Iterate until competition.

Hope that helped.

[IanSzalai]

Having programmers understand how the subsystem they’re programming mechanically and electrically works is very important in my experience. Often times very simple issues can slip through since a programmer doesn’t know something about the mechanical system, for one reason or another.

Still create a state diagram, but don’t just skip over the mechanical design aspect while explaining a subsystem to programmers.

[char]

100% agree. Programmers MUST understand the physics at play in the subsystem they are coding.

State Diagrams are tool to clean-up how we model the system, they are NOT the system.

[coderkevin]

If you yourself are new to programming and WPILib, I heavily recommend getting a Romi Robot for yourself to learn the basics of WPILib at home. That way you can have some idea of what you’re talking about when helping the students.

[Hollisms]

Assuming you have last years code and last years robot… leverage the heck out of it. Start by making sure you have a backup of all the code! ROMI is also great option.

If last years code is using the CommandBased framework, you’ll want to learn how it works. It can be a bit intimidating at first, but once you understand it, it will be a huge help! If last year’s robot isn’t CommandBased… I wouldn’t take that on right now.

I generally break the team up by Subsystem… most advanced taking on drive, auto, vision. Least advanced LEDs, pneumatics.

I generally do white boarding session of each of the subsystems calling out the various states and the state changes. Then depending on skill level work with the students to stub it out in code and/or comments. For the most junior students…

// Check the sensor and do X...
// TODO write the code

I find the most difficult part is teaching them how to do source control, merge code, etc. And find myself taking on that task with the help of the programming team lead. So, most of the time I work side-by-side when something is complete to get it into Github, do the pull request, etc.

Keep in mind that the WPILIB documentation and library is top notch and you should NOT have to write much code to have a functional robot. The examples are great starting points and the WPILIB vscode plugin will generate an almost functional robot. So, if you find yourself writing a lot of code… you may want to ask a question here and somebody will point you in the right direction. This is an amazing community!

[ericjanofski]

We begin with teaching classes, variables, methods and objects on a whiteboard. I like to make a class called cat and then make objects named after our cats where we change the default variables based on how many eyes, ears and legs our cats have. Stuff like that.

The students then watch an instructor use a desktop robot to spin a single motor with a button press.

Then the students program a new project to spin a motor.

With command based programming there’s a lot that goes into that from making sure the wiring is right, to understanding motor controllers and setting up a subsystems and a joystick.

We then move on to using smart dashboard for visualizing motor encoder data and for getting and setting data.

Then we do a position control by setting the P in PID and using encoder values and smart dashboard features.

After that it’s variations on the above with more complex buttons, velocity control etc.

This can all be done with a single motor.

[SLAB-Mr.Thomas]

Lots of good advice posted for you and I suggest you get to decide if you are splitting the software team into two largely independent groups or not?

1. You can teach the inexperienced students what they should have been doing since September. Get one Romi for each two students and start with the basics of programming to move the Romi. I can share with you what we have so far for lessons but they are still a work in progress (we didn’t get done either).
2. The experienced students can program the competition robot under the guidance of the other mentor.

OR

1. Everyone works on the competition robot. The inexperienced students code and the experienced watch over their shoulders to help guide, correct, contribute what should be typed.

(You and I reject the 3rd choice about it being only about winning and not about the students learning and having fun so just let the inexperienced ones get bored and drop out.)

[n3rdchik]

We are definitely going with the 2nd choice - even if the newbies program a single intake wheel, it will be worth it if that keeps them engaged and determined to up the stakes for next year.

[AronRubin]

I have done SCRUM for FTC in the past which worked out really well but I have experience being a SCRUM master. This helps with estimation and task decomposition which are challenging even for professionals.

In terms of work breakdown, this is the pitch I made to my team this year:

• Product and DevOps
• Robot Control & Sensing
• Operator Interface
• Maintenance Interface
• Autonomy/Navigation
• Perception

[n3rdchik]

I do agile with sticky notes/index cards too!

Tell me more about the maintenance interface! I asked about previous test programs and got a blank look.

[SLAB-Mr.Thomas]

Maybe the test code is hiding behind the comment lines in the code.

My take on

@n3rdchik

maintenance interface

is running diagnostics and displaying the health of the robot. A sort of “signature” can be developed from sensors such as motor current draw for a given load, velocities, accelerometers to detect vibration, microphone to detect noises. A normal, all-is-well signature is made when the robot is most healthy and then after each match run the diagnostics and compare to the ideal state signature. There has been a recent CD thread about displaying data but I can’t remember its details.

You can see some examples at matches and open houses such as our neighbor StrykeForce.

This is an advanced topic that your highly technical mentor should relish getting their teeth into.

[AronRubin]

There are a few aspects:

• For any issue with the robot you want the fastest path to finding it
  • Design for test (DFT)
  • Indication (maybe during matches, definitely for debug and pits
  • Diagnostics - dashboards, logs, probes
• Modularity and Configurability
  • Swap-first, repair-second - robot is composed of components that can be swapped for known working parts for the next match while diagnosis is performed
  • Allow for parts to be re-id/reconfigured quickly for interchangeability
  • Design (dis)connection points
• Mise en place - Wikipedia
  • Tooling organization
  • Parts organization
  • Label all the things

[AronRubin]

Another thing to be aware of is the highly prescriptive nature of modern education. Careers and funding are tied to tests so that is where the focus is. The result is that students expect specific instructions. Either you get a very special bunch or you will need to break them of that mode, especially while they are on school grounds. Teach them not just that errors and missed expectations are ok but they are the norm. I tell mechanical “if you are not bleeding from scraped knuckles, you are not working hard enough.” and everybody “just like practice for a sport, where aches are how you know your advancing, you will have little disappointments on your way to robotics proficiency if you’re pushing your boundaries.”