Low performance. 150hz max color sensor reading frequency.

[Soupborsh]

Are there any performace benchmarks, expected performance? I got 150hz maximum reading colorsensor rgb. Pybricks on ev3dev reaches 3000hz and clever(on stock firmware) 6000hz(I was testing with a friend).
Is it always has been so or I have some issues and usually it is much faster? Why possibly it can be slow? How to improve it?

I added all recommended performance tweaks and built with --release. I have arm-unknown-linux-gnueabi toolchain built with crosstool-ng for linux 4.14(ev3dev kernel IIRC), glibc 2.24 and software floating point. I executed binaries by copying and running them in ssh in home directory.

I love Rust and this project, and having maximum performace would be great. I do not intend to be negative.

I would like to know performance you are getting.

[pixix4]

This library is based on the ev3dev-lang-python library (v1) and uses the linux kernel driver with access to the sysfs interface. Their is not much we can do to improve the access to the kernel driver besides the already implemented file handler caching (and using --release to build the project).

If I understand the pybricks correctly, it bypasses the sysfs interface and therefore the overhead to serialization/deserialization and context switching. But this does not mean, that it gets significantly more values from the color sensor. As far as I know, the ev3 color sensor sends an update at 100 - 300 Hz. This value is cached an all reads use this cached value. So if the value can be requested at 6000 Hz, 80% of the reads will return the same cached value as the read before. So yes, the loop runs much faster, but the accuracy is not improved at the same rate.

To change this behavior the pybricks implementation needs to be analyzed. Compatibility to third party hardware, that emulate the sysfs interface must be checked and if this seems possible the backend of this library must be changed accordingly. But currently I do not have time to do this.

[knobsam]

Hi, according to LEGO themselves the ColorSensor has a sample rate of 1kHz, but must be polled at least every 100ms (or it goes to sleep). Please see here.

As far as I remember, we've never achieved that rate with Python or C implementations on EV3DEV OS (as pixix4 wrote, sysfs layer reduces speed). I think we got around 7-800Hz with a C implementation.

Maybe 1kHz is only possible with the "native" implementation of the LEGO builder?