Closed ToMe25 closed 3 years ago
sure, well documented getters would be accepted if they pass CI :)
Wow, that was a fast response. I will try to document them well enough. Starting to work on the PR them :)
I have started working on this, and while the Gravity Vector(gSeGyMi) returns valid results, and i have no idea what the Geomagnetic Vector(mSeGyMi) should be(googling it didn't help) so i just asume its right, the linear acceleration fields(aSeMi, aSePl, aGlPl) all return strange things.
I used this program and a LSM9DS1 to test this:
And this is some sample output:
For this test i used aSePl as Linear Acceleration, which should be linear acceleration (g, sensor frame)
, and the sensor didn't move much.
The Linear Acceleration issue was seemingly just me being stupid, and probably one of the examples being wrong. Not sure about the second one, but if its true i will PR that later.
BTW the example is not wrong, the thing i didn't notice is that for the roll/pitch/yaw calculation it doesn't matter whether the input acceleration is m/s² or g, while for the linear acceleration it does. And as the example uses a fusion algorithm that doesn't calculate the linear acceleration it doesn't matter.
I deleted all the template stuff, because i don't think it applies to suggestions.
The NXP Sensor Fusion algorithm calculates a bunch of interesting values, that don't seem to be accessible in any way. I suggest changing this, by adding getters for them. The ones that seem most interesting to me are:
I suggest adding methods like this:
void getLinearAcceleration(float *x, float *y, float *z) const;
and I would be willing to PR this, if this that has a chance of getting merged. However I would need to know which of the linear acceleration(g, sensor frame) arrays to use, which i currently do not.