depthai v2.25.0 with an OAK-D.
Due to unpredictable models of IMUs within even the same product sku, using ACCELEROMETER is unsafe. There is no api to test for the 9 (fusion) or 6-axis. And hardcoding chip names in app code is a bad approach.
So using ACCELEROMETER_RAW everywhere is the reasonable approach.
However, ACCELEROMETER_RAW always marks the accuracy = dai::IMUReport::Accuracy::UNRELIABLE
which then requires code to either detect the chip to use the ACCELEROMETER_RAW or ACCELEROMETER and then look at the accuracy field, or to never check the accuracy field making it worthless.
I request that ACCELEROMETER_RAW provide useful accuracy values. And if it must have a single hardcoded accuracy, then make it Accuracy::LOW so it can be distinguished from a ACCELEROMETER stream's Accuracy::UNRELIABLE
related https://github.com/diablodale/dp.oak/issues/8
depthai v2.25.0 with an OAK-D. Due to unpredictable models of IMUs within even the same product sku, using ACCELEROMETER is unsafe. There is no api to test for the 9 (fusion) or 6-axis. And hardcoding chip names in app code is a bad approach. So using ACCELEROMETER_RAW everywhere is the reasonable approach. However, ACCELEROMETER_RAW always marks the accuracy = dai::IMUReport::Accuracy::UNRELIABLE which then requires code to either detect the chip to use the ACCELEROMETER_RAW or ACCELEROMETER and then look at the accuracy field, or to never check the accuracy field making it worthless.
I request that ACCELEROMETER_RAW provide useful accuracy values. And if it must have a single hardcoded accuracy, then make it Accuracy::LOW so it can be distinguished from a ACCELEROMETER stream's Accuracy::UNRELIABLE related https://github.com/diablodale/dp.oak/issues/8