Robots are pretty bad at knowing where they are. You can spend millions on odometry (measuring wheel rotations), GPS, accerometers, gyroscopes, laser rangers and the robot still might know where it is very well. Most of these things are completely beyond a school project. The only one listed that you can probably do is odometry and a distance ranger, and if the track has any markers to let you know where the tracks is, then that is best. I would program a rough linear piece wise approximation of the track and with the appropriate lengths and turns degrees into my microcontroller (which should fit), and use odometry to make the turns when needed.
BUT since wheels slips and odometry is not accurate I'd another sensor to help correct for odometry errors and track errors in memory. Like if the track had walls, I'd use a ranger so that if my robot got too close to a wall, it would turn along the track and use the detection of the wall to correct where it is on its internal map. Or maybe the track has lines at it's edges and no walls so a ranger wouldn't work. In this case, I would use a line detector except it wouldn't be as effective as the ranger since my robot would only turn when it was right at the track's edge. They probably give you something on the track so your robot knows where it is or stays inside it- use that.
I would not count on them letting you run the robot once around the track though, or even seeing it. Then the odometry and internal maps would do no good and you woudl have to rely on the ranger or line detector or whatever tells you where the track is (and hopefully the track is in a circle so you are only ever turning right, or left whenever you hit the edge of the track).
So you woudl basically use odometry to try and turn ahead of time to minimize your travel time. And you woudl use some other sensor when your odometry failed so get you back on the track. There are very simple cheap methods for ranging (like IR or ultrasonic). THere are also very simple methods for line detection (like an IR diode and photodetector). I would only use a camera for very advanced line detection (like seeing the line from far away before you are on top of it so you can turn early and get better timing like you would with a ranger.
Do you ever need to go backwards? If you don't, then all you need is an NMOS transistor and gate driver beign controlled by the microcontroller for each motor (and a fast, low forward voltage diode like a schottky diode in anti-parallel with the motor to protect the transistor from inductive flyback (these are voltage spikes generated when cutting off current flow through the motor's inductance).
Just like the way M1 and Q1 are connected this picture here:
You would need a gate driver that accepts an digital input (for on/off only control) or PWM (for variable speed control) from the microcontroller and outputs a current pulse large enough to charge the gate capacitance on the NMOS transistor to turn it on fast enough for PWM. The diagram doesn't show the diode in anti-parallel with the motor to protect the transistor from inductive flyback.
If you do need to go backwards, then you need an H-bridge for each motor which is much more complicated compared to the first solution.