Quaternion equations should match Crassidis' formulas
rodralez opened this issue · comments
Quaternion equations should match Crassidis' formulas for a better understanding of NaveGo's code. Functions qua_update.m and ins_gnss.m should be modified according to Crassidis' formulation.
Yes! t's better to update the quaternion equations according to the formula in this Crassidis' book, which is consistent, but the qua_update.m needs to be modified.
Can you tell me formula 13c ~ 13g， Which paper do you refer to for these formulas？
I want to deduce it myself.
Yes! t's better to update the quaternion equations according to the formula in this Crassidis' book, which is consistent, but the qua_update.m needs to be modified.
I have already modified this function in the develop branch. Please, check it.
Can you tell me formula 13c ~ 13g， Which paper do you refer to for these formulas？ I want to deduce it myself.
What article are you referring to?
I find it is still -skewm,not skewm in ins_gnss.m.
I left the negative sign because NaveGo works fine this way.
By the way, I removed the negative signs in the G matrix at function F_update.m.
@rodralez I checked the codes of your different branches in NaveGo, including before and after changes and your paper. I found a problem. You often change the symbols for DCMbn in F and G, which is too casual. too lax and unreasonable.
I think whether it is a plus sign or a minus sign, that should be determined, at least according to what is given in your paper eq.1 and eq. 3(An approach to benchmarking of loosely coupled low-cost navigation systems).
I'll deduce it myself later to determine whether it's a plus or minus sign.
In addition, I also found another problem. Some formulas in your paper, including but not limited to the update of F and G, and even the update of attitude angle, you cite different documents, which is very dangerous, because some definitions of coordinate system direction are different in different documents, such cross references can lead to inconsistencies and introduce confusion.
I have an intuition that there are still some errors in your program, not just the symbols in front of the skewm.
To be honest，, I tend to think that the book is right. No minus sign in front of skewm, It should be positive. If you change it to negative sign to avoid the divergence of program operation, it just shows that there are still some unknown errors. It is a coincidence that the current positive sign leads to divergence, and the minus sign can work normally.
@rodralez I submitted a branch，which is different with you codes(ins_gnss.m, earth_rate.m, vel_update.m, transport_rate.m,att_update.m,F_update.m).
You can check and run the code, F& G is consistent with your paper, NaveGo woks normally，it doesn't diverge, but I get the result is not very good.
I think there is some unkown error. You can compare with them.
@rodralez I submitted a branch，which is different with you codes(ins_gnss.m, earth_rate.m, vel_update.m, transport_rate.m,att_update.m,F_update.m).
You can check and run the code, F& G is consistent with your paper, NaveGo woks normally，it doesn't diverge, but I get the result is not very good.
I think there is some unkown error. You can compare with them.
I cannot find the branch that you submitted. What is its name?