Closed Flesko closed 6 years ago
2018-06-26 13:13 GMT-03:00 Flesko notifications@github.com:
Dear rodralez,
first of all, thank you very much for your work. I am not sure if I miss something at the velocity update (vel_update.m), because there is a difference at the signs within the code and your publication. Here is the current function:
S = skewm(vel); % Skew matrix with velocities
coriolis = S (omega_en_N + 2 omega_ie_N); % Coriolis
fn_c = fn - coriolis - (g); % Corrected specific force in nav-frame
vel_n = (vel + fn_c' * dt);
According to your paper "An approach to benchmarking of loosely coupled low-cost navigation systems" the equation for the velocity derivative should be
fn_c = fn + coriolis + (g);
I also compared it to the derivation from Paul Grove in his book "Principles of GNSS, Intertial, and Multi-sensor Integrated Navigation", which coincides with it. Did I miss any transformation or redefinition?
Dear Flesko,
Unfortunately, this equation from my article is wrong.
Since gravity (g) is positive in NED frame, it must subtracted to NED velocity. So, NaveGo equation is right.
Regards.
-- Rodrigo Gonzalez
gravity(g) is negtive in NED frame, but the sign of fb(3) in your imu data is positive, I have a strong doubt here, is there a bug in the sign of fd when calculating F matrix?
May 2, 2019 at 9:51, raoxuanivan (notifications@github.com) wrote:
gravity(g) is negtive in NED frame, but the sign of fb(3) in your imu data is positive, I have a strong doubt here, is there a bug in the sign of fd when calculating F matrix?
Hi,
Gravity is positive in the NED frame. "D" stands for down. So, the sign of the gravity force in the NED frame must be positive. Moreover, each element in vector fb( : , 3) should be positive as well.
Kind regards.
-- Rodrigo Gonzalez
Dear rodralez,
thank you very much for your reply,I mean the gravity accelerometer measures points to up in a static condition, so that should the sign of fd be negative?
thank you very much for your reply,I mean the gravity accelerometer measures points to up in a static condition, so that should the sign of fd be negative?
Hi,
NaveGo is developed using the NED frame. Therefore, each element in your vector fb( : , 3) should be positive. If your fb( : , 3) is negative, for example [ -9.813, -9.824, -9.815, ... ], you have to do:
fb( : , 3) = - fb( : , 3);
This way, your new vector will be [ 9.813, 9.824, 9.815, ... ]
Kind regards. -- Rodrigo Gonzalez
I clearly know the NED frame is used。MayBe we can imagine a situation that a vehicle is moving downward with the acceleration being g exactly,the measurement of the accelerometer now should be zero exactly,like a gravity free condition。In NavGo: fn_c = fn - coriolis - (g); Then the result of fn_c(3) is negative here, thus we will get a upward velocity, is anything wrong here?
发自我的 iPhone
在 2019年5月2日,下午9:39,Rodrigo Gonzalez notifications@github.com 写道:
thank you very much for your reply,I mean the gravity accelerometer measures points to up in a static condition, so that should the sign of fd be negative?
Hi,
NaveGo is developed using the NED frame. Therefore, each element in your vector fb( : , 3) should be positive. If your fb( : , 3) is negative, for example [ -9.813, -9.824, -9.815, ... ], you have to do:
fb( : , 3) = - fb( : , 3);
This way, your new vector will be [ 9.813, 9.824, 9.815, ... ]
Kind regards. -- Rodrigo Gonzalez — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Dear rodralez,
the biggest difference between us is the sign of gravity. I am sure that the gravity a real accelerometer measures points to up in a static condition. In this way, the velocity update becomes:
fn_c = fn + coriolis + (g);
But your formulation works better in your project(For testing, I changed the sign of fb(:,3) and the velocity update function). I'm really confused about this. Looking forward to your reply. My English is not good, I hope you can understand.
El vie., 3 may. 2019 a las 1:24, raoxuanivan (notifications@github.com) escribió:
Dear rodralez,
the biggest difference between us is the sign of gravity. I am sure that the gravity a real accelerometer measures points to up in a static condition. In this way, the velocity update becomes: fn_c = fn + coriolis + (g);
But your formulation works better in your project(For testing, I changed the sign of fb(:,3) and the velocity update function). I'm really confused about this. Looking forward to your reply. My English is not good, I hope you can understand.
Dear raoxuanivan,
Gravity is a force vector. It could positive or negative based on the reference frame you are using. In the ENU frame, gravity is negative. In the NED frame, gravity is positive. NaveGo uses the latter (NED). I think you should read more about reference frames.
Regards. -- Rodrigo Gonzalez
Of course,Gravity points down。But the gravity an accelerometer measures points up。I am sure of it
发自我的 iPhone
在 2019年5月3日,下午9:05,Rodrigo Gonzalez notifications@github.com 写道:
El vie., 3 may. 2019 a las 1:24, raoxuanivan (notifications@github.com) escribió:
Dear rodralez,
the biggest difference between us is the sign of gravity. I am sure that the gravity a real accelerometer measures points to up in a static condition. In this way, the velocity update becomes: fn_c = fn + coriolis + (g);
But your formulation works better in your project(For testing, I changed the sign of fb(:,3) and the velocity update function). I'm really confused about this. Looking forward to your reply. My English is not good, I hope you can understand.
Dear raoxuanivan,
Gravity is a force vector. It could positive or negative based on the reference frame you are using. In the ENU frame, gravity is negative. In the NED frame, gravity is positive. NaveGo uses the latter (NED). I think you should read more about reference frames.
Regards. -- Rodrigo Gonzalez — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Dear rodralez,
I think the problem is found。
Your formulation in vel_update.m has some sign problems, right one is:
fn_c = fn + coriolis + (g);
The sign of gravity accelerometer sensed is negative in the NED frame.
The sign of imu.wb(:,1) and imu.wb(:,2) is also opposite in your project, so is the sign of ref.roll and ref.pitch.
After above corrections, the RMS reduces, especially in the D-direction.
Real data in the examples is used for testing. Your imu data generated for simulation also has above problems. So It can't be used for this test.
The following picture comes from the book of "Strapdown inertial navigation technology". NED is used as the reference frame in this book. These pictures shows the sign problems in your codes.
Finally, appreciate for your job really, hope you can spend some time checking my issues.
在 2019年5月3日,21:05,Rodrigo Gonzalez notifications@github.com 写道:
El vie., 3 may. 2019 a las 1:24, raoxuanivan (notifications@github.com) escribió:
Dear rodralez,
the biggest difference between us is the sign of gravity. I am sure that the gravity a real accelerometer measures points to up in a static condition. In this way, the velocity update becomes: fn_c = fn + coriolis + (g);
But your formulation works better in your project(For testing, I changed the sign of fb(:,3) and the velocity update function). I'm really confused about this. Looking forward to your reply. My English is not good, I hope you can understand.
Dear raoxuanivan,
Gravity is a force vector. It could positive or negative based on the reference frame you are using. In the ENU frame, gravity is negative. In the NED frame, gravity is positive. NaveGo uses the latter (NED). I think you should read more about reference frames.
Regards. -- Rodrigo Gonzalez — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Dear rodralez,
first of all, thank you very much for your work. I am not sure if I miss something at the velocity update (vel_update.m), because there is a difference at the signs within the code and your publication. Here is the current function:
According to your paper "An approach to benchmarking of loosely coupled low-cost navigation systems" the equation for the velocity derivative should be
fn_c = fn + coriolis + (g);
I also compared it to the derivation from Paul Grove in his book "Principles of GNSS, Intertial, and Multi-sensor Integrated Navigation", which coincides with it. Did I miss any transformation or redefinition?King regards, Flesko