I got it now.
Thank you very much
Posts made by paha
Thank you very much for the reply.
I'd like to ask one more question about function
_GenerateObservationJacobian_AHRS in UpdateFunctions.c.
There is following comment for
/* Pitch (including modifications for |q| = 1 constraint) * mu = 2*( q(1)*q(3) - q(2)*q(4) ); * % 2/sqrt(1-mu*mu) * [q(3); -q(4); q(1); -q(2)] * 2/sqrt(1-mu*mu) * [q(3) - mu*q(1); * -q(4) - mu*q(2); * q(1)- mu*q(3); * -q(2)- mu*q(4)] */
I know how to get this line
% 2/sqrt(1-mu*mu) * [q(3); -q(4); q(1); -q(2)]
but don't know how you came to this
2/sqrt(1-mu*mu) * [q(3) - mu*q(1); * -q(4) - mu*q(2); * q(1)- mu*q(3); * -q(2)- mu*q(4)]
which is most probably mentioned constraint for |q| = 1.
Could you please shed more light on it? Your code awesome and great practical EKF tutorial.
I intend to use IMU300ZI in our omnidirectional robot (can turn all 4 wheels into arbitrary but the same direction). The robot has speed encoder and wheel angle encoder so I want to use this info in EKF. As a base code I use your INS example project.
I studied your code and think that the best place for wheel angle incorporation is in function
Update_PseudoMeasurement() in UpdateFunctions.c. Instead of using
frontVelMea variable as scalar I would make it vector the values of wich would be set based on current wheel angle, wheel speed and
gKalmanFilter.ppsEulerAngles[YAW]. I would also set
Odometer data would be received over SPI.
Do you think this is correct solution or is there anything important I forgot about which could cause failure?
It seems to me there is a bug in openIMU300-lib/Platform/Core/src/platform.c in function
case 42: orientation = 0x005A7958; break; // 0000 000 | 00 0 | 10 1 | 01 0 +Z -X +Y
case 42: orientation = 0x005A7859; break; // 0000 000 | 00 0 | 10 1 | 01 0 +Z -X +Y