Streaming Data Format?

Hi Firmware Group,

Please explain the data format in streaming data. Send a request for Ambient sensor:

1A 01 18 39 8C 04 00 0A 02

Streaming service starts okay.

Streaming response:

28 01 18 3D FF 04 00 02 D6 BF E7   <<== ????
28 01 18 3D FF 04 00 02 A6 47 8F   <<== ???? 

The LEDs are flashing with the low battery warning which probably explains different values.

Reading Ambient directly gets:

29 01 18 30 8A 00 40 A6 56 EF     <<== 5.2167

They don’t come close to being the same. The direct reading varies nicely if I shine a light on it.

Other streaming readings are equally strange. Locator is another I tried and can’t make sense of.

Other directly read floating point values are reasonable when converted, like voltages.

Rud (former embedded systems guy who sympathizes)

1 Like

Hold on to your hat.

The streaming values returned are scaled unsigned values and have to be scaled back to there normal ranges…

Quaternion -1.0 - 1.0
IMU -180 - 180
Accelerometer -16.0 - 16.0
Gyroscope -2000.0 - 2000.0

Normalize: (value) / Max * (rangeMax - rangeMin) + rangeMin

Accelerometer returns X = 7F B5 AF 00 = 2142613248
Normalize = 2142613248/4294967295 * (16 - -16) + -16
Normalize = .498866 * 32 - 16
Normalize = -0.036288

Mike

1 Like

@iseries1,

That’s, ah, unique. Where did you find that information? There are some other sensors like Ambient light that don’t have a range that is easily discerned.

Rud

1 Like

I had to find it in the code since it’s not defined in a class.

They are defined in the sensor control code. Sensor Control on Github for javascript

They use this function:

public static normalize(value: number, min: number, max: number, newMin: number, newMax: number): number {return ( ( (value - min ) / (max - min) ) * ( newMax - newMin ) ) + newMin;

Mike

1 Like

Thanks, I hadn’t looked at the NodeJS code base. Been primarily working with the Pi code. Probably find more answers to question in NodeJS.

Rud

1 Like

This same code is also in Pi code. sensor_streaming_control.py

Mike

1 Like

Thanks…

I know I’ve looked at the file because I copied the table about the sensors. Guess at the time wasn’t looking at streaming in enough detail to follow the rest of the code.

Rud

1 Like

Looks like the Ambient Light code is wrong.

The value returned divided by 32767 seems to come closer to the other reading for light values. Checking a number of reading it comes closer to something like 35000.

Mike

1 Like

The normalize code is in SDK/sphero_sdk/common/helpers.py

1 Like

While we are on the subject, is the “quaternion” measure an “orientation quaternion” (https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation)? And WHY is it used?

Curious…

1 Like

Probably orientation. Necessary if you drive the RVR across the North or South poles.

2 Likes

Quarternions are the bees knees when it comes to rotation/orientation. It needs less bytes to store a rotation then other ways and uses less calculations when working with it. Also as mentioned by rmerriam it is error proof on the poles. But not just necessary on the poles, point and vector orientation would crash big time when you hold the RVR pointing its front directly upwards or downwards, qarternions don’t.

Went to the sensor_streaming_control too and saw the min/max values, but found no place where these values are actually used. So was assuming that the data you get back already are workable with. But well ok, seems we have to convert them to usable values ourselves. Just strange that they set the min/max and then completely ignore them. Wasted memory there :wink:
Also realized that the example for registering sensor handlers is wrong. They give an example for acceleration like this: x = accel_data[‘X’] but actually you have to go into the first level dictionary first and it has to be this: x = accel_data[‘Accelerometer’][‘X’].

2 Likes