You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on an application where it is critical to be sure that the data received are valid / correct, otherwise some real world hardware will do bad stuff. If I do not miss something, I think that checking data validity is not really doable / enforced at the moment with this library, but that additional safety could be added relatively easily. I discuss this a bit in details here:
Example of how things can go wrong
My scenario is the following; at present:
the sensors starts as it should and is used for a long time...
... then something bad happens: hardware failure, a broken wire on a drone, etc, and the sensor gets disconnected / stops working. The problem is, the library will just continue providing (bad, invalid) data, without a way for the user to know that these data are bad
then bad data is fed into another critical system, and there is no way for this system to know that the data are bad, which is even worse (otherwise, the system could at least try to use another sensor, find a correction solution, restart everything, etc).
For example, at present, if I start using one of these IMUs on I2C, and it starts well, then if I just unplug the sensor, I start getting erroneous values, without any way to check if these are actually valid or invalid values.
Where the issue comes from
I will follow the stream of what my code uses. I rely on this function to read from my IMU:
which does in fact return a valid and carefully checked flag indicating if the communication worked or not (this can be checked by looking at the function used to write and read:
If you agree with this, I could work on a suggestion of pull request, but I would like to double check with you first that I do not miss anything before proceeding with the pull request work etc :) .
I am working on an application where it is critical to be sure that the data received are valid / correct, otherwise some real world hardware will do bad stuff. If I do not miss something, I think that checking data validity is not really doable / enforced at the moment with this library, but that additional safety could be added relatively easily. I discuss this a bit in details here:
Example of how things can go wrong
My scenario is the following; at present:
For example, at present, if I start using one of these IMUs on I2C, and it starts well, then if I just unplug the sensor, I start getting erroneous values, without any way to check if these are actually valid or invalid values.
Where the issue comes from
I will follow the stream of what my code uses. I rely on this function to read from my IMU:
Adafruit_LSM6DS/Adafruit_LSM6DS.cpp
Lines 251 to 261 in 1ea3bd2
but this function always returns true, even if the
_read()
fails are the data are grossly invalid.Really there is no need for this, because this:
Adafruit_LSM6DS/Adafruit_LSM6DS.cpp
Line 254 in 1ea3bd2
which comes from here:
Adafruit_LSM6DS/Adafruit_LSM6DS.cpp
Lines 450 to 502 in 1ea3bd2
relies actually on this:
https://github.com/adafruit/Adafruit_BusIO/blob/b903c7e0154cfe20ea618f972fad3277feae6fb2/Adafruit_BusIO_Register.cpp#L201-L234
which does in fact return a valid and carefully checked flag indicating if the communication worked or not (this can be checked by looking at the function used to write and read:
https://github.com/adafruit/Adafruit_BusIO/blob/b903c7e0154cfe20ea618f972fad3277feae6fb2/Adafruit_I2CDevice.cpp#L238-L246
which does take care of the quality of what is read and written, and the low level read and write are written and checked with great care:
https://github.com/adafruit/Adafruit_BusIO/blob/b903c7e0154cfe20ea618f972fad3277feae6fb2/Adafruit_I2CDevice.cpp#L77-L158
)
How to fix the issue
_read
function should return a validity flag, that is just the propagation of the flag returned by theAdafruit_BusIO_Register
read call:Adafruit_LSM6DS/Adafruit_LSM6DS.cpp
Lines 450 to 502 in 1ea3bd2
Ie become something like:
_read
, including but not only:Adafruit_LSM6DS/Adafruit_LSM6DS.cpp
Lines 251 to 261 in 1ea3bd2
should actually read the (newly introduced) status flag returned by the
_read
function and use it as their own return flag.discussion about implementation
The text was updated successfully, but these errors were encountered: