New programmer tasks?

VEX V5 General Discussion General Forum
1

Since most of my team are seniors, we will be leaving VRC next year. There is someone on the team who will be a programmer next year. I want to give him some tasks to do before the seniors leave so that he knows how to do all the necessary programming things. Basically I’m going to give him a robot with every sensor on it, and give him tasks to complete. I have several tasks in mind, ranging from simple to more difficult. This is what I have so far:
-Simple driving (Tank/arcade)
-Simple bang bang auton tasks
-Line following
-P/PI/PD/PID for lift and drive
-PID for ultrasonic as robot approaches a wall
-TrueSpeed (just for fun)
What I am wondering is, are there any other tasks that I should have the new programmer practice before he’s on his own? Any suggestions are appreciated.

2

Square dance. I.e. implement enough library support to be able to run the code like:


void squareDance() {
    driveStraight(120);
    turn(90);
    driveStraight(120);
    turn(90);
    driveStraight(120);
    turn(90);
    driveStraight(120);
    turn(90);
}

such that the robot gets back to the starting position, the same starting orientation.
120 is the distance in cm, 90 is, obviously, angle difference. They’d better actually come with a more comprehensive argument set, such as adding speed and heading to the driveStraight, and perhaps using absolute target heading for the turns.

3

So you’re saying to make it where they have lots of functions for driving straight, turning etc.? So that the code isn’t just based off of lots of


motorSet ( unsigned char channel , int speed )

(We use PROS)

4

Oh, absolutely!
Not necessarily “lots of functions”, just a few, but well defined and tested so you can reuse them easily.
Them, the body of your auton should be short and easy to follow. It should pretty much “read” as your intent, as if your drivers were describing the strategy to you.

Would they say “and turn this motor to 100, then wait 300ms”? No. If the strategy description contains “and pick up the MoGo”, yes, you can go ahead and define a function pickUpMoGo(). It only gets a little hairy if the driver says “and keep driving while picking up the MoGo”, though similar approach is still usable when tasks or other forms of concurrency get involved

5

Dancing is great. Having taunts/dances ready at the push of a button, and that can be cancelled out, of are always morale boosters.

First, make sure they are comfortable with fprint/print/cout debugging. This is one of the easiest ways for beginner/intermediate level programmers to debug. They just read the output, and find where it stopped outputting.

Next, make sure the current programmers comment the heck out of their current code.

Make sure they learn to use arrays and structures to create adaptable and reusable code.

Finally, Gave them try to write any of the following: Straight-Drive code, lift-leveling, Velocity PIDs (flywheels from NBN), Auto grabbing/loading (using line readers), Gyro steering (and re-calibrating using line readers, 2x button switches, or ultrasonic sensors), Image tracking (V5), Autonomous watchdogs, Switchable control schemes, V5 GUI for debugging, V5 GUI for PID tuning or autonomous command issuing.

Oh, and if you can, design a sensor-laden clawbot for them to work with during the offseason.

6

This 100%. I routinely run this test with each time we build a new robot to verify that I have tuned our drive functions correctly. I generally run this and make sure my results are repeatable over at least 5-10 trials on different batteries. Also, running this twice in a row (no reset in between) is a good test to see what kind of drift you can expect and need to correct for in skills.

If those tests work, the odds are so will your auton routes.