read values don't go below zero

[harvardbiorobotics]

commit hash 0c6f537d

when the sensors are in compression, the sensors should go past zero and into negative readings. Currently, they appear to report the absolute value of the reading instead (giving non-monotonic response)

[itdaniher]

Could you please paste an example reading(s) demonstrating the error?

[harvardbiorobotics]

under increasing pressure: (appears to be an issue with the two's compliment code)

self.getDataRaw(): {30: (432, 506), 31: (132, 508)} {30: 90.7041, 31: 129.6398} self.getDataRaw(): {30: (433, 505), 31: (124, 510)} {30: 90.6268, 31: 130.5214} self.getDataRaw(): {30: (431, 505), 31: (116, 509)} {30: 90.8672, 31: 131.5792} self.getDataRaw(): {30: (431, 505), 31: (109, 509)} {30: 90.8672, 31: 132.4533} self.getDataRaw(): {30: (431, 505), 31: (101, 509)} {30: 90.8672, 31: 133.4522} self.getDataRaw(): {30: (430, 505), 31: (92, 508)} {30: 90.9875, 31: 134.6366} self.getDataRaw(): {30: (431, 506), 31: (83, 509)} {30: 90.8243, 31: 135.6999} self.getDataRaw(): {30: (431, 507), 31: (75, 509)} {30: 90.7813, 31: 136.6989} self.getDataRaw(): {30: (431, 505), 31: (65, 508)} {30: 90.8672, 31: 138.0095} self.getDataRaw(): {30: (429, 505), 31: (56, 507)} {30: 91.1077, 31: 139.1963} self.getDataRaw(): {30: (429, 507), 31: (48, 509)} {30: 91.0215, 31: 140.0703} self.getDataRaw(): {30: (430, 506), 31: (40, 509)} {30: 90.9444, 31: 141.0693} self.getDataRaw(): {30: (429, 505), 31: (33, 508)} {30: 91.1077, 31: 142.0071} self.getDataRaw(): {30: (429, 506), 31: (23, 506)} {30: 91.0646, 31: 143.3847} self.getDataRaw(): {30: (429, 506), 31: (15, 509)} {30: 91.0646, 31: 144.191} self.getDataRaw(): {30: (429, 507), 31: (6, 508)} {30: 91.0215, 31: 145.38} self.getDataRaw(): {30: (428, 505), 31: (2, 507)} {30: 91.2279, 31: 145.9449} self.getDataRaw(): {30: (427, 506), 31: (10, 508)} {30: 91.3049, 31: 144.8803} self.getDataRaw(): {30: (427, 505), 31: (17, 508)} {30: 91.3481, 31: 144.0058} self.getDataRaw(): {30: (427, 506), 31: (21, 508)} {30: 91.3049, 31: 143.5061} self.getDataRaw(): {30: (427, 507), 31: (24, 509)} {30: 91.2617, 31: 143.0672} self.getDataRaw(): {30: (427, 505), 31: (25, 508)} {30: 91.3481, 31: 143.0064} self.getDataRaw(): {30: (426, 505), 31: (26, 509)} {30: 91.4683, 31: 142.8175} self.getDataRaw(): {30: (427, 504), 31: (26, 507)}

[itdaniher]

I was erroneously applying twos complement decoding to the pressure and temperature data. This has been fixed in https://github.com/TakkTile/TakkTile-usb/commit/0563e2f8f88274e4cef0e726d77ae9ec1ff70aff.

[harvardbiorobotics]

Now when high pressure applied the values jump to 1024 and then go down .... see below. Maybe applying two's compliment was not wrong after all ?

I remember to solve this one in my code by keeping the history of the values and then adjust it as the values overflow above or below the 7bit number. But maybe you have a better idea ?

{30: 87.3309, 31: 143.6187} self.getDataRaw(): {30: (458, 513), 31: (15, 515)} {30: 87.2894, 31: 143.8033} self.getDataRaw(): {30: (458, 511), 31: (14, 515)} {30: 87.3724, 31: 143.9279} self.getDataRaw(): {30: (458, 513), 31: (12, 514)} {30: 87.2894, 31: 144.2418} self.getDataRaw(): {30: (458, 513), 31: (10, 514)} {30: 87.2894, 31: 144.491} self.getDataRaw(): {30: (458, 512), 31: (8, 514)} {30: 87.3309, 31: 144.7402} self.getDataRaw(): {30: (458, 512), 31: (6, 516)} {30: 87.3309, 31: 144.8592} self.getDataRaw(): {30: (458, 511), 31: (3, 515)} {30: 87.3724, 31: 145.298} self.getDataRaw(): {30: (458, 513), 31: (2, 515)} {30: 87.2894, 31: 145.4225} self.getDataRaw(): {30: (458, 513), 31: (0, 515)} {30: 87.2894, 31: 145.6716} self.getDataRaw(): {30: (458, 511), 31: (1022, 515)} {30: 87.3724, 31: 18.3778} self.getDataRaw(): {30: (458, 511), 31: (1018, 515)} {30: 87.3724, 31: 18.876} self.getDataRaw(): {30: (458, 512), 31: (1013, 515)} {30: 87.3309, 31: 19.4988} self.getDataRaw(): {30: (458, 513), 31: (1011, 515)} {30: 87.2894, 31: 19.7479} self.getDataRaw(): {30: (457, 514), 31: (1009, 515)} {30: 87.3676, 31: 19.997} self.getDataRaw(): {30: (456, 512), 31: (1008, 515)} {30: 87.5706, 31: 20.1216} self.getDataRaw(): {30: (456, 512), 31: (1006, 515)} {30: 87.5706, 31: 20.3707} self.getDataRaw(): {30: (456, 513), 31: (1005, 514)} {30: 87.5289, 31: 20.5077} self.getDataRaw(): {30: (457, 512), 31: (1003, 515)} {30: 87.4507, 31: 20.7443} self.getDataRaw(): {30: (456, 513), 31: (1003, 515)} {30: 87.5289, 31: 20.7443} self.getDataRaw(): {30: (457, 513), 31: (1002, 515)} {30: 87.4091, 31: 20.8689}

[itdaniher]

I'm not entirely sure what you're expecting anymore - can you describe in detail the expected numerical results? After going over the code again last night, I'm pretty sure TakkTile.py successfully implements the compensation and calibration algorithm described in the datasheet, and the pressure numbers we're getting now makes slightly more sense for a sensor with a written range of 50kPa to 115kPa.

[harvardbiorobotics]

I am not looking at the compensation or calibration algorithms. I am looking at the raw data.

If you look at the data sample shown above then you can see that the values go to zero as the pressure is applied, and then jump to 1024 and then decrease .... the lowest is 1002 in this case.

I personally would expect the values to become negative after they reach zero rather than jump 1024.

It maybe a problem on the sensor side ... but maybe not ?

[itdaniher]

The raw data is literally just the raw data. You're seeing the output of the unsigned integer registers 0x00 to 0x03 on the MPL115A2 sensor, suggesting that this is an issue with the sensor, not the code in question.

I'm not sure of a stateless approach to catching an operational overflow, but willing to accept either a clean patch adding minimum state or a higher level module with functionality targeted towards robotics use.

[harvardbiorobotics]

A wrapping algorithm to deal with this aspect was implemented. The changes were performed within TakkTile.py and will be pushed shortly.