R3's eye, and trying to aim the robot

So I'm trying to add an "eye" to R3. Mechanically it's simple enough, I just stuck an LDR between ground and one of the analog inputs. Since the input has a built-in pullup resistor that should effectively create a voltage divider. No problem, that works as expected. Now I want the robot to spin in place, stopping every 45 degrees to take a light reading. Since the motors are just modified servos with no feedback it took some fiddling. After a bit of trial and error I find that running both motors for 300 millis rotates the bot 1/8 turn. So, spin for 300, stop, take a light reading, if the light reading is lighter than the last one replace last high reading and store which step in the spin it is, repeat. As usual, the code to make that happen is shorter than the sentence describing it in English. No problem.

Here's where it gets fun. Because of the way R3 drives (the spinny motion described on the project page), to aim for a specific location the "right" wheel needs to be pointing towards the target at the start of the drive cycle. Since I saved which position had the highest light reading, and I know which position I end in, it's simple math to figure out how many 1/8 steps the right wheel is away from pointing at the target. I should just have to run the motors for 300*steps millis to be lined up correctly. Except this part just fails to work every time. R3 ends up pointing it's right wheel nowhere near the intended target. I know it's likely a bonehead screwup in my math. Now I've tweaked the function so much I don't remember where I started. The best shot is probably to delete that part, grab the notebook, and work it all out again from scratch.

Damn this would be easier if I'd just used wheel encoders. Why in the hell did I decide to try it with as low of a parts count as possible? Is there a moral to this story? Probably not, just generalized ranting, and a reason to put off grabbing a pencil and thinking about math that I shouldn't have this much trouble with.

Update

I rewrote/reorganized about half of the light-finding function. Now the steps are named 1 through 8 (inclusive) instead of 0 to 7. That makes it a bit easier to calculate how many steps out of aim the bot is. Easier makes for less code too ;) Another big change is making the final rotate happen in steps, as discussed below with emuller. Finally I just moved the order of things a bit, now it moves then takes a reading, instead of reading then moving. Minor change, but for some reason my brain wrapped around that easier too. I blame the Rum.

Now I've realized a new problem. Fortunately it's not a major one. The 300 ms delay and/or the speed at which the servo is driven are likely to be wrong when I remove the Serial.print() debugging lines from the routine... Dammit... I blame the Rum. LOL

Update 2

Nevermind about the Serial.print screwing with the timing. I'm not printing to the console while it's driving, only while it's sitting still. That was a "duh" moment. Yup, blaming the Rum again ;)