strange behavior of US sesnor in NXT-G

[alex-kolotov]

Hi,

2 years ago I already tried calculate performance of US sensor in NXT-G and got quite expectable results.

It was somthing about 17 iterations per second. I don't recall exactly what version of NXT and FW was used at that time.

Today I tried to execute the same test case. I prepared the following program:



Where the main loop is for 10000 iterations.

So, as results I see about 8000 on the screen. It means that 10000 iterations containing pulling of ultrasonic sensor are executed in ~8 seconds.
I tried this on NXT 2.0 and standard FW v1.31.

Is this something wrong with my NXT-G program? Because if I prepare similar code on NXC I see the corresponding 22 sec for 1000 iterations (i.e. 22 ms for one).

[mattallen37]

Because it isn't doing anything useful with the values, it might be optimizing it like crazy. It is totally impossible for it to only take 8 seconds to read it 10000 times, so it probably isn't reading it more than maybe once (if even).

A better test would be to actually output the values to the display, so that it can't optimize out the reading. To compare speeds, do another loop where you display a loop count. The time difference divided by the number of samples would be the amount of time it takes to read (or at least relatively).

[alex-kolotov]

You know, I have already did such testing yesterday. I didn't see much difference here.

What I put in the loop: store loop counter in a variable, and used the switch block instead of "recieve data" block for US sensor. I also tried to display the sensor value in another test.

So, the maximum I could get is 13 sec for 10000 iterations. It is still odd.

[HaWe]

what exactly do think is "odd"?
IIRC, the US sensor works in automatic mode and gives a new reading about every 40ms or so.
You will always have to wait until the sonic impulse has been sent + reflected back at max 2x250cm = 5m, at 300 m/s it takes 5*1000/300 = 17 ms at least for 1 "real" reading.
But what you get polling so fast is thousands of times the same identical buffered value :)

[mattallen37]

The I2C bus speed is 9600kbps. If the entire read procedure uses 39 bits, the actual time the bus is being used is 0.00375 seconds (3 3/4ms). Without taking into account delays at either end, that's 37.5 seconds of active bus time for 10000 readings.

[HaWe]

Code: Select all

task main() {
    SetSensorLowspeed(IN_4);
    Wait(500);
    int tmp;
    long strt = CurrentTick();
    for(int i=0;i <1000;i++) {
        tmp = SensorUS(IN_4);
    }
    NumOut(12,LCD_LINE4, CurrentTick()-strt);
    until(ButtonPressed(BTNCENTER, false) > 0);
}

By this NXC program I need ~ 23 sec for 1 thousand sensor readings at OL 2 and ~ 22 sec at OL 1.
That's about 1 program reading cycle each (about) 22ms which is limited by the the execution speed of the fw virtual machine (the byte code interpreter). One must note that incrementing the loop counter i++ needs a little additional execution time.

Indeed it is not credible that the execution speed of the Lego NXT-G program should be faster than the NXC program execution speed - if it appears to be so then I agree, that point is really odd.

But what I actually wanted to express is that this is not the "real" update interval of the USS , which is 17 ms minimal (limited by mathematics) and maybe 50ms maximal (limited by USS firmware).

The i2c bus speed is maybe even far faster but will never get faster "real readings" than the USS fw enables - but at best more redundant readings of identical buffer values.

[alex-kolotov]

But what I actually wanted to express is that this is not the "real" update interval of the USS , which is 17 ms minimal (limited by mathematics) and maybe 50ms maximal (limited by USS firmware).

The i2c bus speed is maybe even far faster but will never get faster "real readings" than the USS fw enables - but at best more redundant readings of identical buffer values.

Doc-Helmut, mattallen37,
I understand what you saying, I know about physical limitations of US sensor that is why I called the topic "strange behavior". I just wanted to know if someone else has the same in NXT-G 2.0.

I know that RobotC FW claims that they work with USS very fast. So, I even realize that they can create a separate thread (task) independently of user's implementation that will pull USS and put actual measurement in some buffer as so another thread can read the value from the buffer as often as it can. I even implemented similar on NXC.

So, I could make a guess that NXT-G guys wanted to implement somthing like this. Just for now I don't know how it is possible because my understanding is that NXT-G is like macro-code of LabView (similar as "C" language is a macro-assembler). In other words every NXT block can be represented as a sequence of LabView blocks. So, it quite difficult to think here that they implemented some kind of optimization, because it is definitely (from my perspective) hard work in graphical languages. But I would conjecture that creation of the thread (or checking if it is running already) is very possible withing a NXT-G block therefore buffering of USS values is quite logical here.

Is this somthing someone knows for sure?

[HaWe]

I don't know anything for sure, and I dont own NXT-G 2.0 and sorry if I didn't understand everything of what you wrote quite correctly.
But my guess now is the following:
maybe NXT-G has got a code optimizer like C compilers have.
Because the USS values are never displayed or used in another way in the program they might have been optimized away, so the counting loop results to be just an empty counting loop (which, of course, is insanely fast).
This is something that also a C compiler might possibly do, against which a protection by volatile might be helpful (see different thread):

Code: Select all

    volatile int tmp;
    long strt = CurrentTick();
    for(int i=0;i <1000;i++) {
        tmp = SensorUS(IN_4);
    }

maybe this guess can help though.

[spillerrec]

I doubt this because of a code optimizer. If it is doing that, it should remove the whole loop completely.

I think I remember reading something about the FW might not return the correct sensor value and that you have to keep calling the function until it reports it being correct. So the FW might buffer it or do something special here. You should try to decompile both the NXT-G and NXC program to NBC with nbc.exe and look for the difference.

[alex-kolotov]

I don't know anything for sure, and I dont own NXT-G 2.0 and sorry if I didn't understand everything of what you wrote quite correctly.
But my guess now is the following:
maybe NXT-G has got a code optimizer like C compilers have.
Because the USS values are never displayed or used in another way in the program they might have been optimized away, so the counting loop results to be just an empty counting loop (which, of course, is insanely fast).

I have already mentioned that inserted the display block to show US sensor value in every iteration. So, I got about 13 secs for 10000 iterations.