Ultrasonic sensor doesn't return centimeters for distance_centimeters value in US-DIST-CM mode

[marnovdm]

• ev3dev version: 4.4.68-20-ev3dev-ev3
• ev3dev-lang-python version: not sure how to get this info? Came installed with latest jessie ev3dev release

When using the ultrasonic sensor the distance doesn't seem to be in centimeters. The brickman tool on the ev3 does show the correct value when I read the sensor there. In python code I have to divide ultrasonic.distance_centimeters by 10 to get actual centimeters. A simple test case:

robot@ev3dev:/usr/lib/python3/dist-packages/ev3dev$ python3
Python 3.4.2 (default, Oct  8 2014, 14:47:30)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ev3dev.ev3 as ev3
>>> ultrasonic = ev3.UltrasonicSensor('in4')
>>> ultrasonic.distance_centimeters
326

While the display shows 32.6 cm (which corresponds with real world distance from the sensor). I would expect to get either a floating point like 32.6 for distance_centimeters method or a changed method name like distance_milimeters or something. This seems incorrect, or am I doing something wrong? Workaround is easy enough and I'm having lots of fun programming my EV3 with python but thought I'd at least report this.

[WasabiFan]

Looks like an oversight in the library implementation to me. distance_centimeters returns this.value(0); the value method returns the integer value without any decimal point offset. @ddemidov Where is that value supposed to be incorporated? My JavaScript library's implementation explicitly called a method which incorporates decimals.

[ddemidov]

Yes, we could divide the returned value by 10**decimals. The drawback is that each readout would cost an extra file access operation. It could be more effective if user would read decimals once and used it for scaling the returned values outside of the library code. I am not sure which is the best approach though.

[WasabiFan]

I think it's a safe bet that the decimals value will never change -- it's hard-coded in driver code. Also, this is only relevant for properties which we call floats.

[ddemidov]

It may change when the mode is changed: http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-jessie/sensor_data.html#lego-ev3-ultrasonic-sensor. On the other hand, it is indeed fixed for each of the modes, and we could just encode the information from the driver documentation into spec.json (for example, add decimals field here) which would result in division by a constant in python code.

[ddemidov]

(and I don't think there is a notion of float properties in python bindings)
EDIT: ah, there it is in the spec.json: https://github.com/ev3dev/ev3dev-lang/blob/develop/spec.json#L1193

[ddemidov]

Another option is we store decimals in a dictionary keyed on mode value. The initially empty dictionary would be filled automatically from sysfs on first access.

[WasabiFan]

It may change when the mode is changed ... On the other hand, it is indeed fixed for each of the modes, and we could just encode the information from the driver documentation into spec.json (for example, add decimals field here) which would result in division by a constant in python code.

I like the idea of using a dictionary for each mode -- it's simple.

(and I don't think there is a notion of float properties in python bindings)

We store that info in the spec (I believe), even if the Python binding doesn't use it. JS isn't typed such that floats and ints require different types in code, but the logic can exclude the decimals check for integer values.