BTW. I just noticed something else in your code. You put a 50 msec wait at the end of your loop, which was not in mine. What happens if you read the sonar too fast? What kind of values come back?

Also, I put in 8 bits because I couldn't use the precision. I assumed 10 bits would be slower then 8 bits?

Peter

It's a shame when work gets in the way of robotics, isn't it?

Xander

As I understand it, the internal RobotC drivers update the SensorValue array when they actually get a new value, not when you read from the array (I think its just a normal array not some magical code like in other places of RobotC). So no I doubt you'd get any weird values from reading it faster.

I did get the ~1004 values with your original #pragma section (sorry I failed to mention that I replicated your issue and then fixed it)

I always put some sleep delay in loops so I ensure other parts of the program get time to run. Since I can't see their code and there is very little documentation, I don't trust their preemptive multitasking when everything is running full bore. I always make sure loops either sleep or give up the rest of the time slot.

In this case you're writing an actual control loop so I recommend setting a specific loop time rather than it being based on the amount of code in the control loop. Running the code as fast as it can is probably counterproductive and difficult to fine tune. You need to give the motors and robot inertia time to respond.

Mostly the 50msec delay was so long just to point out that the sonar values won't change any faster than that so if you're trying to drive based on them you have to realize there will be some "lag" that you have to take into account.

In your case, you are just stopping at a limit. You should be able to tune the stopping point pretty well since the robot will be going about the same speed every time it hits that threshold.

I'd set your loop delay time based on making the line detector work well and not so much the sonar. The motor controllers are updated every 20msec by default I believe. This is also pretty good rate for the the HTPB (although it can handle much faster ... see xander's blog http://mightor.wordpress.com/2008/10/25/taking-i2c-to-the-max-on-the-nxt/).

good luck.