multiple serouts???
 

if drive_L and drive_R are also the variables used in the manual section AND they are in the single serout at the end (which they would need to be to effect anything) then shouldn't they still affect the serout as in the same manner as long as they come after the user part of the code? I noticed alot of people are saying you need multiple serouts or serins... The single serin already finds out the sensor readings on the robot which will return real values. Your autonomous code MUST use only those values and timing to determine the values for the variables in the serout. Simply use the same variables in the autonomous mode and user mode and a single serout will suffice... However this means that the autonomous code must be the last thing to edit the variables before the serout in order for it to work.

The general idea: yes.
The purpose of the for loops, the total_iter loop:no

line following code
 

The code posted to follow the line would probably work ok, but it depends on very careful positioning of the sensors. Since the robot will either go forward full speed or rotate in place full speed, there is the chance it would oscillate side to side if it catches the line wrong. Try it and you'll see what I mean.

I worked with the edubot to try and apply a control loop to the line following problem, with mixed success. There were two wheels at the front of the bot with a caster in back. Each wheel was controlled independently using the same subroutine. There were three sensors, one on the line and one on either side. It kept track of the previous reading and the number of cycles the sensor had been in that position. The speed was then increased or decreased proportionally to the amount of time the sensor was either on or off the line. The formula was something like:

Speed = Current Speed +- ((Cycles in State) * Gain)

Speed is initially set to neutral (127) for both wheels. The number of cycles was some subdivision of the loop counter. I think it was something like 5 loops = 1 Cycle. Gain was tweaked manually until the robot worked well. If the sensor was on the line it would decrease the speed, off the line it would increase it.

The idea was to apply only small changes when the robot is off the line, gradually increasing the amount it tried to compensate. The state it did not count on was overshoot for sharp angles.

It works pretty well for long straight sections, the robot would eventually compensate for a sloppy drivetrain by driving the wheels at different speeds. Gentle curves worked pretty well also, but it could not handle sharp corners.

Following a line while moving slow is easy - doing it fast is the trick.