Hi All,

Is there a code sample or a function available within RobotC to optimise the NXT or RCX, (Similar to the new optimise icon within Robolab 2.9). This function is useful for programs that require very rapid reading of sensors. It shuts down extraneous functions like screen updates and other things for faster line following etc?

Thanks
James

I know there's a way to have the compiler optimize the assembly before sending it to the NXT. If you check in preferences, under the compiler tab, you'll see what I'm talking about. I'm not sure that it would be noticeable unless you had alot of stuff going on though. Hopefully this is what you're looking for.

Hi HoTWiReZ,

I don't think we are talking about the same thing. That the code should be optimised when being compiled would be a normal option. What I'm talking about is an NXT state where peripheral tasks such as screen updates etc are stripped out or shut down.

Thanks
James

Wouldn't you just not write them into your program? I guess I don't quite get what you're saying. Sorry. I know my programs can read sensors pretty darned fast without doing anything extra. I use 100 checks of a sensor value and then take the average, and the program doesn't take any longer than it did before I added that averaging.

My guess is that there are still screen updates going on (at an operating system level) even if you are not sending instructions. This must use up cycles that could be more effectively utilised. Having said that, and given the speed of the NXT the gain may be virtually insignificant. I was just curious because I'd seen that the writers of Robolab 2.9 had decided to incorporate it into their program. Perhaps it is really aimed at the RCX. I was just curious to get a perspective on it.

Wow, you average 100 readings without any impact on the program. I was told the light sensors sample at around 300 readings/sec.

At that speed are you putting a millisecond between each reading to prevent reading the same value twice? I assume that the light sensor processes slower than the NXT processor. So do you need to add a delay to prevent recording the same reading twice or more? Is there a rule or principle/calculation relating to this?

Any sample code demonstrating this would be cool.

Really, I don't know about the delay. That'd be a good question to ask here.. I don't put one in, because as I understand it, the sensor simply sends an analog signal back to the nxt to be sampled onboard. I haven't the slightest clue as to the speed that it samples at, but I am sampling for one reading, so I'd expect the values to be very similar each time. I'll try putting a small delay between the measuring also, to see if it helps with accuracy or anything.

Here's the part of my function that measures (in my case, to the left of the robot up to 75 degrees from center) the ultrasonic sensor reading in 5 degree increments to see if there was an edge detected. This is used later to figure out which direction that the robot needs to turn.

Robolab uses a simpler vresion of the RobotC firmware. I wrote both of them.

RobotC programs execute faster than any other programming environment for the NXT. Typically 50 times faster than an equivalent program written in the NXT-G graphical programming environment.

For simple programs (i.e. limited use of arrays, not more than 256 different variables) RobotC typically executes around 100+ lines of code per millisecond! I suspect this is more than fast enough for your program.

Yes. Analog sensors are sample once every 3 milliseconds. This rate cannot be changed. SO if your program reads a sensor value as fast as it can, it will typically be reading the same value.

Ultrasonic sensors are sampled at an even slower rate. Something like once every 50 milliseconds. That's how long it takes to send a ultrasonic ping and get the response and then leave lots of time in between to ensure that you don't get any echos.

LCD screen updates consume a minimal amount of time. Last time I checked all background tasks (LCD updates, motor and sensor device drivers, etc) averaged 13% of total CPU with remaining 87% for RobotC program execution.

Thank you Dick,

Once again a very informative post.

I now understand why there is no equivalent optimisation function in RobotC

You have certainly helped to clarify my (and I assume many others) understanding of the speed of sensors Vs NXT’s speed of code execution under Robot C.

Just to confirm my understanding. (nb anyone who knows can respond)

If I was to write the following code:

Then, given the 100+ lines of code executed/sec (ignoring the approx 13% overhead for background tasks such as LCD updates, motor and sensor device drivers, etc) I could inadvertently fill 300 or more variables (in the 3 millisecond gap between sensor reads) with the same 1st reading and theoretically the next 300 variable with redundant/repetitive copies of the 2nd reading etc.

If that is the case, it will be very handy to know when trying to average sensor readings (particularly ultrasonic readings at 50 milliseconds).

For example in HoTWiReZ's post above he'll end up averaging 100 copies of the one reading.

Thanks again,
James

Yeah, I guess I'll just have to drop the delays before and after the averaging and then add a 50 msec delay inside of the for loop and drop the number of values used in the average to make up for it. Thanks for the help, Mr. Swan.