rodralez / navego

NaveGo: an open-source MATLAB/GNU Octave toolbox for processing integrated navigation systems and performing inertial sensors analysis.

NaveGo

NaveGo: an open-source MATLAB/GNU-Octave toolbox for processing integrated navigation systems and performing inertial sensors profiling analysis.

NaveGo (ˈnævəˈgəʊ) is an open-source MATLAB/GNU Octave toolbox for processing integrated navigation systems and simulating inertial sensors and a GNSS receiver. It also performs analysis of an inertial sensor using the Allan variance. It is freely available online. It is developed under MATLAB/GNU-Octave due to this programming language has become a de facto standard for engineering and modeling of physical systems.

NaveGo's motto is "to bring integrated navigation to the masses".

Important Update for the NaveGo Community

Dear NaveGo Community,

I am reaching out to share an important update regarding the NaveGo project. Due to a shift in both my professional career and personal interests away from navigation systems, I have made the difficult decision to step down from my role as the lead developer of NaveGo.

Effective immediately, NaveGo will transition to a community-driven project. This change opens up new opportunities for collaboration, innovation, and leadership within our vibrant community. I encourage each of you to actively participate, whether by answering questions in the discussion forum, contributing to the development of new features, or sharing your unique insights and expertise.

This project has always thrived on the enthusiasm, creativity, and dedication of its community members, and I have every confidence that NaveGo will continue to grow and evolve in exciting ways. If you or someone you know is passionate about taking on a leadership role within the NaveGo project, please do not hesitate to contact me. Your involvement could make a significant impact on the direction and success of NaveGo.

I want to express my deepest gratitude to all of you for your support and contributions to NaveGo. It has been an honor to work alongside such a talented and dedicated group of individuals. I look forward to witnessing the future achievements of this project and the community that has been its backbone.

Thank you for your understanding and continued support.

Warm regards,

Dr. Rodrigo Gonzalez

Attention!

Please, you should open a new issue only if:

1. You found a bug or error in the source code of NaveGo,
2. You want to ask for new features. Maybe some contributor will gently take this issue and code your suggested feature.

But, if you have any question of any kind or you want to share some feedback about NaveGo, please leave a comment at the discussion forum.

Features

Main features of NaveGo are:

• Processing of an inertial navigation system (INS).

• Processing of a loosely-coupled integrated navigation system (INS/GNSS).

• Processing of a loosely-coupled integrated navigation system with magnetometers (INS/GNSS/MAG).

• NEW Processing of a loosely-coupled integrated visual navigation system (VISUAL/INS/GNSS).

• Compass heading using magnetometers.

• Simulation of inertial sensors and GNSS.

• Zero Velocity Update (ZUPT) detection algorithm.

• Allan variance technique to characterize inertial sensors' both deterministic and stochastic errors.

• Better visualization of GNSS outages.

NaveGo Mathematical Model

The underlying mathematical model of NaveGo has been evolving. It is based on several books, mostly on:

• Paul D. Groves (2013). Principles of GNSS, Inertial, and Multisensor Integrated Navigation Systems (2nd Ed.). Artech House, USA.

• D.H. Titterton and J.L. Weston (2004). Strapdown Inertial Navigation Technology (2nd Ed.). Institution of Engineering and Technology, USA.

Two previous articles used to expose NaveGo mathematical model, but currently these two documents are partially outdated:

• R. Gonzalez, J.I. Giribet, and H.D. Patiño. NaveGo: a simulation framework for low-cost integrated navigation systems, Journal of Control Engineering and Applied Informatics, vol. 17, issue 2, pp. 110-120, 2015. Download.

• R. Gonzalez, J.I. Giribet, and H.D. Patiño. An approach to benchmarking of loosely coupled low-cost navigation systems. Mathematical and Computer Modelling of Dynamical Systems, vol. 21, issue 3, pp. 272-287, 2015. Download.

For example, the original Kalman filter state vector has been reduced from 21 to 15 states. Therefore, please take these two articles just to have a glimpse of NaveGo structure.

 NaveGo Model Validation

NaveGo has been validated by processing real-world data from a real trajectory and contrasting results against Inertial Explorer, a commercial, closed-source software package. Differences between both solutions have shown to be negligible. For more information read the following paper:

• R. Gonzalez, C.A. Catania, P. Dabove, J.C. Taffernaberry, and M. Piras. Model validation of an open-source framework for post-processing INS/GNSS systems. III International Conference on Geographical Information Systems Theory, Applications and Management (GISTAM 2017). Porto, Portugal. April 2017. Download.

Roadmap

Hopefully, these three future features will be added to NaveGo:    

• Barometer as aiding sensor for altitude.

• G-sensitivity correction for gyroscopes.

• Tightly-coupled INS/GNSS integration.

Contributions

We are looking for contributors to NaveGo! Since integrated navigation is a topic used in several fields such as Geomatics, Geology, Mobile Mapping, Autonomous Driving, and even Veterinary (yes, Veterinary!) for animal tracking, we hope other communities other than the navigation community compromise and contribute to this open-source project.

You can contribute in many ways:

• Writing code.
• Writing a manual.
• Reporting bugs.

If you want to contribute to the NaveGo project, you should follow the Github Workflow methodology summarized at ./doc/github-workflow.md.

If you are interested in joining NaveGo, please feel free to contact Dr. Rodrigo Gonzalez at rodralez [at] frm [dot] utn [dot] edu [dot] ar.

Branches

NaveGo has two main branches:

1. master: contains the stable releases of NaveGo.

2. develop: every new feature of NaveGo will be implemented in this branch first. develop will be merged to master from time to time.

More branches would be created to develop particular features for NaveGo. These extra branches will be eventually merged to develop.

Please, cite our work!

If you are using NaveGo in your research, we kindly ask you to add the following two cites to your future papers:

• R. Gonzalez, C.A. Catania, P. Dabove, J.C. Taffernaberry, and M. Piras. Model validation of an open-source framework for post-processing INS/GNSS systems. III International Conference on Geographical Information Systems Theory, Applications and Management (GISTAM 2017). Porto, Portugal. April 2017. Download.

• R. Gonzalez, J.I. Giribet, and H.D. Patiño. NaveGo: a simulation framework for low-cost integrated navigation systems, Journal of Control Engineering and Applied Informatics, vol. 17, issue 2, pp. 110-120, 2015. Download.

An URL to NaveGo should be provided as the following cite:

Gonzalez, Rodrigo (2022). NaveGo: an open-source MATLAB/GNU-Octave toolbox for processing integrated navigation systems and performing inertial sensors profiling analysis. NaveGo Release v1.4 (v1.4). Zenodo. https://doi.org/10.5281/zenodo.6549626

Donations

Your donation helps us to improve NaveGo. You can make a donation to support our work using:

• BITCOIN public key: bc1q8uehhf0y36jtwyua29z0xhqxvd7q2thuuwys28 (BTC network).
• Ethereum public key: 0x97aae6533AaeD1ba38D1863B4a8C35e7Cc5261E8 (ERC20 network).
• USDT public key: 0x97aae6533AaeD1ba38D1863B4a8C35e7Cc5261E8 (ERC20 network).
• PAYPAL: paypal.me/supportnavego.

Examples

The example folder contains several types of examples which try to be a kind introducción to the use of NaveGo.

Allan variance example

This example can be analyzed by just executing the file navego_example_allan.m. Firstly, Allan variance is applied to 2-hours of real static measurements from a Sensonor STIM300 IMU. Then, almost 5 hours of synthetic inertial data are created and Allan variance is run on these simulated data.

INS/GNSS integration example using synthetic (simulated) data

The NaveGo example with synthetic data is based on the output of a trajectory generator. This program provided both truth accelerations and angular velocities for a previous defined trajectory. NaveGo does not provide a trajectory generator.

The file navego_example_synth.m tries to expose how NaveGo can be used step by step. Two IMU measurements are simulated according to the error profiles of the ADIS16405 IMU and the ADIS16488 IMU. Then, both IMU are fused using a simulated GNSS sensor. Finally, performances of the two simulated INS/GNSS systems are compared.

References

• R. Gonzalez, J.I. Giribet, and H.D. Patiño. NaveGo: a simulation framework for low-cost integrated navigation systems, Journal of Control Engineering and Applied Informatics, vol. 17, issue 2, pp. 110-120, 2015. Download.

• Analog Devices. ADIS16400/ADIS16405 datasheet. High Precision Tri-Axis Gyroscope, Accelerometer, Magnetometer. Rev. B. Download.

• Analog Devices. ADIS16488 datasheet. Tactical Grade Ten Degrees of Freedom Inertial Sensor. Rev. G. Download.

• Garmin International, Inc. GPS 18x TECHNICAL SPECIFICATIONS. Revision D. October 2011. Download.

INS/GNSS integration example using real data

Two examples of how to use NaveGo to post-process real data are provided as navego_example_real_xxxx.m, one for tactical-grade Ekinox-D IMU and another for consumer-grade MPU-6000 IMU. Both IMUs are integrated with Ekinox-D GNSS. These datasets were generated by driving a vehicle through the streets of Turin city (Italy).

These two real examples are part of the data collection used in the article (Gonzalez and Dabove, 2019).

References

• R. Gonzalez and P. Dabove. Performance Assessment of an Ultra Low-Cost Inertial Measurement Unit for Ground Vehicle Navigation. Sensors 2019, 19(18), 3865; https://doi.org/10.3390/s19183865. September 2019. Download.

• SBG Systems. SBG Ekinox-D High Accuracy Inertial System Brochure, Tactical grade MEMS Inertial Systems, v1.0. February 2014.

• InvenSense Inc. MPU-6000/MPU-6050 Product Specification. Document Number: PS-MPU-6000A-00. Revision: 3.4. Release Date: 08/19/2013.

VISUAL/INS/GNSS integration example using real data

Two examples are provided for VISUAL/INS/GNSS integration:

1. navego_example_canada_data.m.
2. navego_example_katwijk_data.m.

Please, check the folder examples/visual-data/.

References

• Johann Diep et al. (2022). Investigating the Performance of LCNS with Visual-Inertial Odometry for Lunar Rover Navigation. NAVITEC 2022, April 2022.

• Johann Diep (2022). Investigating the Performance of LCNS with Visual-Inertial Odometry for Lunar Rover Navigation. Youtube video.

Researchers who are using NaveGo

The following 16 papers have expressed the use of NaveGo for research:

1. Paul Rawiel (2022). Positioning of Pedelecs for a Pedelec Sharing System with Free-Floating Bikes. In: Coors, V., Pietruschka, D., Zeitler, B. (eds) iCity. Transformative Research for the Livable, Intelligent, and Sustainable City. Springer, Cham. link

2. Ren, X.; Sun, M.; Zhang, X.; Liu, L.; Wang, X.; Zhou, H. An AR Geo-Registration Algorithm for UAV TIR Video Streams Based on Dual-Antenna RTK-GPS. Remote Sens. 2022, 14, 2205. https://doi.org/10.3390/rs14092205. This paper use NaveGo to improve the geographic registration (geo-registration) accuracy by fusing the positioning and heading data from the dual-antenna real-time kinematic global positioning system (RTK-GPS) with onboard internal measurement unit (IMU) data.

3. Johann Diep et al. Investigating the Performance of LCNS with Visual-Inertial Odometry for Lunar Rover Navigation. NAVITEC 2022 conference, April 2022. NaveGo is used as part of a VISUAL/INS/GNSS navigation system. Youtube video.

4. Canhui Tao, Zhiping Song, and Zhenping Weng. MCTLS-Assisted Completed SINS/GPS Integrated and Applied to Low-Cost Attitude and Heading Reference System. Mathematical Problems in Engineering 2021 (2021). Link. NaveGo is used as a benchmark for comparing a proposed heading determination approach.

5. Nagui, N., Attallah, O., Zaghloul, M.S. et al. Improved GPS/IMU Loosely Coupled Integration Scheme Using Two Kalman Filter-based Cascaded Stages. Arab J Sci Eng 46, 1345–1367 (2021). Link. Authors use NaveGo as a benchmark for a new proposed integrated navigation scheme.

6. Benjamin Noack, Christopher Funk, Susanne Radtke,and Uwe D. Hanebeck. State Estimation with Event-Based Inputs Using Stochastic Triggers. First Virtual IFAC World Congress (IFAC-V 2020). Germany, July 11-17, 2020 Link.

7. W. Sun, J. Wu, W. Ding and S. Duan. A Robust Indirect Kalman Filter Based on the Gradient Descent Algorithm for Attitude Estimation During Dynamic Conditions, in IEEE Access, vol. 8, pp. 96487-96494, 2020, doi: 10.1109/ACCESS.2020.2997250.

8. R. Rabiee, X. Zhong, Y. Yan and W.P. Tay. LaIF: A Lane-Level Self-Positioning Scheme for Vehicles in GNSS-Denied Environments, in IEEE Transactions on Intelligent Transportation Systems, vol. 20, no. 8, pp. 2944-2961, August 2019. doi: 10.1109/TITS.2018.2870048. Link. NaveGo is used as a benchmark to assess a proposed fusion algorithm based on a particle filter to achieve lane-level tracking accuracy under a GNSS-denied environment.

9. O. Tokluoğlu and E. Çavuş. Study of Utilizing Multiple IMUs for Inertial Navigation Systems Without GPS Aid, 2019 1st Global Power, Energy and Communication Conference (GPECOM), Nevsehir, Turkey, June 2019, pp. 86-89. doi: 10.1109/GPECOM.2019.8778612.  Link. The purpose of NaveGo in this work is to test the performance of an INS/GNSS system with multiple IMUs.

10. Bac Nghia Vu, Khanh Nhu Nguyen and Mung Huy Vu. Practical Considerations of IMU Data Generator, 2019 3rd International Conference on Recent Advances in Signal Processing, Telecommunications & Computing (SigTelCom), Hanoi, Vietnam, March 2019, pp. 63-68. doi: 10.1109/SIGTELCOM.2019.8696196. Link. NaveGo is used to simulate gyros data. Then, these data is compared to the output of a proposed method for the same goal.

11. Mohamed Atia. Design and simulation of sensor fusion using symbolic engines. Mathematical and Computer Modelling of Dynamical Systems 25.1 (2019): 40-62. February 2019. Link. This work proposes a simulation framework for inertial sensors and an Attitude and Heading Reference System (AHRS). Atia uses the same true data that NaveGo provides (see Fig. 7) as true data input to simulate sensors. Unfortunately, Atias' simulator and NaveGo performances are not compared in this work.

12. Ren, X., Sun, M., Jiang, C., Liu, L., & Huang, W. (2018). An Augmented Reality Geo-Registration Method for Ground Target Localization from a Low-Cost UAV Platform. Sensors, October 2018, vol. 18, no 11, p. 3739. Link. NaveGo is used to process RTK GPS data in the context of an INS/GNSS system for geo-registration and target localization.

13. M. Pachwicewicz and J. Weremczuk. Accuracy Estimation of the Sounding Rocket Navigation System. 2018 XV International Scientific Conference on Optoelectronic and Electronic Sensors (COE), Warsaw, June 2018, pp. 1-4. doi: 10.1109/COE.2018.8435180. Link. In this paper NaveGo is used as a simulation framework for three types of IMUs.

14. M.G. Deepika and A. Arun. Analysis of INS Parameters and Error Reduction by Integrating GPS and INS Signals. 2018 International Conference on Design Innovations for 3Cs Compute Communicate Control (ICDI3C), Bangalore, April 2018, pp. 18-23. doi: 10.1109/ICDI3C.2018.00013. Link. This work is completely based on the synthetic data example provided by NaveGo. It is not clear what the contribution of this paper is.

15. P.K. Diamantidis. Attitude Navigation using a Sigma-Point Kalman Filter in an Error State Formulation. Dissertation for Master degree. Department of Space and Plasma Physics, School of Electrical Engineering, KTH Royal Institute of Technology, Stockholm, Sweden. 2017. Link. A 30-minutes static measurement of a gyroscope was made with and its Allan Variance plot is presented by using the NaveGo functions.

16. Shaoxing Hu, Shike Xu 1, Duhu Wang and Aiwu Zhang. Optimization Algorithm for Kalman Filter Exploiting the Numerical Characteristics of SINS/GPS Integrated Navigation Systems.  Sensors 2015, 15(11), 28402-28420. Link. The mathematical model of this work is base on NaveGo's proposed mathematical model.

Acknowledgments

We would like to thank to the many people that have contributed to make NaveGo a better tool:

• M.Sc. Johann Diep for contributing with code and examples for VISUAL/INS/GNSS integration as part of his research at the European Space Agency (ESA). You can learn more about his research by watching this video.

• Mr. Daniel Lu, GIS Analyst at Western Heritage (Canada), for his comments on the sign of acceleration when accelerometers sense gravity.

• Dr. Paolo Zoccarato for his comments on attitude conversion.

• Dr. Paolo Dabove and Dr. Marco Piras (both from DIATI, Politecnico di Torino, Italy) for helping to debug NaveGo and suggesting new features.

• Prof. Zhu, Dr. Yang, and Mr. Bo Sun, all from the Laboratory of Precision Measuring Technology and Instruments, Tianjin University, Tianjin, China, for contributing with IMU static measurements to test Allan variance routines.

• Dr. Charles K. Toth (The Ohio State University, USA), Dr. Allison Kealy, and M.Sc. Azmir Hasnur-Rabiain (both from The University of Melbourne, Australia) for generously sharing IMU and GNSS datasets, and in particular, for Azmir's unselfish support and help.

• Dr. Juan Ignacio Giribet (National University of Buenos Aires, Argentina) for his continuous support on theory aspects of INS/GNSS systems.

navego's Issues

Strange free INS coasting error

Hi,

Firstly, thank you for you work! It's a very useful toolbox and it's awesome that you deliver it under gpl.

Secondly, I am trying to simulate the INS without GPS calibration to estimate how much grow the error with the reference data. As you can see in the figure,

the down component error grow up too much for a free inertial solution.

if you want to reproduce it, I used the ins_gps.m function without kalman filter.

Thank you

Questions about the new dt term in F_update

Hi Rodrigo,

I noticed you add dt in the F matrix. I don't really understand this, can you explain why do you need to multiply the fixed bias term with dt here?

F= [Fee Fev Fep (DCMbn)*dt Z (DCMbn) Z;
Fve Fvv Fvp Z (-DCMbn)*dt Z (-DCMbn);
Fpe Fpv Fpp Z Z Z Z;
Z Z Z Z Z Z Z;
Z Z Z Z Z Z Z;
Z Z Z Z Z Fgg Z;
Z Z Z Z Z Z Faa;
];

Regards

Updating of reference section in .m files header

Since NaveGo mathematical model is no longer completely based on the two articles by Gonzalez (Gonzalez et al., 2015, Gonzalez et al., 2015b), references to these two articles have to be eliminated to avoid confusion among NaveGo new users.

size of F and G matrix

Hi, Dr Gonzalez
After I study your codes , figure out in your article , dimension of F matrix is 2121 but you programmed it 1515 , why?
and please submit a reference for more understanding a ZUPT algorithm and formula .
thank you .

Lever arm for velocities

I am not sure to understand how you are using the lever arm for the computation of the position.
In fact, I have the impression that you use it for the position but not for the velocity

" zp = Tpr * ([lat_e(i); lon_e(i); h_e(i);] - [gps.lat(j); gps.lon(j); gps.h(j);]) ...
+ (DCMbn * gps.larm);

zv = (vel_e(i,:) - gps.vel(j,:))';    "  (from ins_gps.m)

Am I right or did I misunderstand the script ?

Thank you in advance for your answer !
And thank you for your code.

Coordinate systems (vehicle frame)

Hello Dr. Gonzalez,

Thanks for the open sourced software. It is stepping stone and great insight for the beginners.

It is mentioned in the comment section of each example file
"% NOTE: NaveGo assumes that IMU is aligned with respect to body-frame as
% X-forward, Y-right, and Z-down."

1. In "navego_example_synth.m" the Vehicle frame has same direction as of IMU?
2. For "navego_example_real_ekinox.m" & "navego_example_real_mpu6000.m". This is similar as 1, except we have lever-arm and we compensate for the lever-arm effect?
3. Does it matter if vehicle move along a different axis. For example, assuming the vehicle is moving along x-axis in case of "navego_example_real_ekinox.m". In second case, the vehicle collects data moving along y-axis. Considering such scenario should we change anything? // or we keep our model the same?

Sorry for asking so many questions.
I wish you a very happy and healthy new year ahead in advance.

Best regards,

vel_update

Hi,
Please note that vel_update corrects the specific force by subtracting g as a vector (31) and not by a scalar as written in function description (moreover, fn_c dimensions are (31)..so g must be (3*1) )
Thanks!

Gyros and accrs static biases are not used in ins_gnss

I checked the code of ins_gnss and there is no usage of ab_sta and gb_sta.
There is only one line with this variables:

b(1,:)  = [imu.gb_sta, imu.ab_sta];

But there is no practical benefit in it. It confused me at first. Maybe remove this input or add special comment in ins_gnss.m?

llh2ecef.m

It seems that llh2ecef.m, referenced in ned2ecef.m is missing.

ZUPT algorithm

Hi , Dr Gonzalez
In first thank you for your best tools in navigation .
I studied your codes but I didn't understand ZUPT algorithms.
please help me to understand it .
Thank you for your attention ...

Definition of body frame XYZ?

Hi~I'm working with your wonderful work to process the data from my own UAV autopilot. But Now I am confused with the relation of the Body frame XYZ and the roll/pitch/yaw of the UAV. I tried to found the general relationship and there are many possibilities existing. So I'm wondering if there is any further definition of the relation of the Body frame XYZ and the roll/pitch/yaw of the UAV?

Size of g and use in vel_update.m

Dear rodralez,

thank you for your work, I really appreciate your code.

I am a little bit confused since the function "gravity" creates a vektor g_n with the size [1x3]

g = (g0 ./ (1 + (h ./ Ro)).^2);

Z = zeros(size(lat));

g_n = [Z Z g];

First of all, in the description of the function its mentioned as size [Mx1]
But more important for me: in the function vel_update you use

fn_c = fn - coriolis - g

fn is size [3x1], coriolis is size [3x1] but g is size [1x3] which actually creates a matrix [3x3] for fn_c (which confuses me since fn_c should have size [3x1] as well).

Can you help me out please?

Thank you very much

sgolayfilt warning

In a normal execution of navego_example.m, I receive a warning in gyro_gen:

Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 5.892434e-33.

In sgolay (line 101)
In sgolayfilt (line 71)
In gyro_gen (line 43)

is it normal?

Limiting the altitude drop when GNSS is lost

During the forced GNSS outages, the altitude shows a sharp drop which is inconsistent with a land vehicle trajectory.

One approach could be, if the Vel D is bigger than a threshold, the altitude should be frozen until the Vel D shows reasonable values.

how to generate trajectory data?

Dear Rodrigo,
thanks for this useful toolbox!
I would like to ask a question how to generate trajectory data?
I have some real data collected by apm or pixhawk, how to use amp or pixhawk data to your model?

Question about get REF DATA

Thanks for your NaveGO, I am not good at programming, so I have trouble about getting REF DATA.
The Inertial Explorer need input binary data, I only have csv data, how can we do?
Looking forward to your reply!

Improvement of Allan variance functions

The goal of this issue is to improve NaveGo functions for getting the Allan variance, inspired in the methods exposed in ref [1].

[1] https://www.mathworks.com/help/nav/ug/inertial-sensor-noise-analysis-using-allan-variance.html

Improvement of GNSS outages plots

Plot of INS/GNSS estimates has to be improved to better show when GNSS outages are forced. Functions navego_plot.m and/or navego_plot_main.m have to be modified.

It would be nice to plot two vertical lines showing the GNSS outages period and change the color of the line inside this period.

关于数据的说明

Strange accuracy problem whereas RTK received

Dear Rodrigo,

First of all thank you for your code, it is very helpful.

However I noticed a strange phenomenon, at the beginning of my simulation the hybridization is actually worse than GPS alone. For almost 3min there is about 35cm of error for the hybride trajectory whereas GPS error is below 2cm. Imu data are generated from the reference trajectory, with error estimated in static with Allan-variance.

What I do not understand is that since GPS.stdm is of about 1cm for this period, the kalman filter should give more weight to GNSS, and it appears not to be the case ? I have spent days on it, I don't see what I am missing.
I tried to take only gnss when RTK is received, with no success (kalman filter diverge).
Screenshots are attached.

Thank you in advance for your answer
Sincerely,

(The vehicle starts moving after 15sec)

Parser for RINEX files

A parser for RINEX files is needed to extract pseudoranges and pseudorange rates from GNSS measurements, in order to later support tightly-coupled integration.

The parser can be developed in-house or taken from another project.

Removing function dsplot.m

dsplot.m is a very verbose function to plot downsampled data from static IMUs. It has to be deleted and a new function or code has to be implemented just to plot downsampled data from a static IMU.

typo

NaveGo/ins_gnss.m

Line 12 in c3be322

% vrw: 1x3 angle velocity walks (m/s^2/root-Hz).

vrw: 1x3 angle velocity walks (m/s^2/root-Hz).
↓
vrw: 1x3 velocity random walks (m/s^2/root-Hz).

F_update (lines 81-112)

Hi,
In F_update (lines 81-112):
Updating F matrix for the misalignment errors doesn't match Farrell's book (up to minus sign). Please see page 394 (CHAPTER 11. AIDED INERTIAL NAVIGATION).

What is the right implementation ?

Thanks,
Barak

5x Median Absolute Deviation (MAD) criteria

When I used Allen variance for IMU calibration, if the angular velocity (WB) changed very little, I tested the condition of all 0, so an error would be reported, and the reason was found to be function [retVal, S, errorb, tau] = allan_overlap(data,tau,name,verbose)
% Screen for outliers using 5x Median Absolute Deviation (MAD) criteria
MAD = median (abs (medianfreq) / 0.6745);
if verbose >= 1 && any(abs(medianfreq) > 5MAD)
Odl = (abs (medianfreq) & gt;5MAD);
Outliers = data. Freq (odl);
Fprintf (1, 'allan_overlap: OUTLIERS: There appear to be %d OUTLIERS in the frequency data.\n', length(OUTLIERS));
Fit_line = polyval (s.l inear, (1 / data. Rate: 1 / data. Rate: length (data. The freq)/data. Rate) ') - s.m edian;
Idl = (medianfreq <(5*MAD + fit_line) );
Data. The freq = data. The freq (idl);
Medianfreq = medianfreq (idl);

Fit_line = polyval (s.l inear, (1 / data. Rate: 1 / data. Rate: length (data. The freq)/data. Rate) ') - s.m edian;
Idl = (medianFreq >;(-5*MAD + fit_line) ); &&这行代码删除掉了我全部的数值0
Data. The freq = data. The freq (idl);
Medianfreq = medianfreq (idl);
S.o utliers = length (outliers);
The else
S.o utliers = 0;
end
It will make data filtering, delete all data.freq values, and get empty [], and report an error.

Questions about the correlation times

Dear Rodrigo,
Firstly, thank you for your toolbox!
I am a beginner. I want to know how to determine Gyro correlation times and Acc correlation times for real-world data? Do you have suggested methods and functions?

Many thanks.
Best Regards.
Shida

Error with example

Hello! At first I would like to thank you for the great tool!

But I have some trouble when I;m trying to start an example (synthetic-data, Matlab 2014):

NaveGo: generating GNSS synthetic data...
NaveGo: generating IMU1 ACCR synthetic data...
Reference to non-existent field 'DCMnb_m'.

Error in acc_gen (line 64)
acc_b = acc_nav2body(acc_ned, ref.DCMnb_m);

Error in navego_example_synth (line 271)
fb = acc_gen (ref, imu1); % Generation of acc in the body frame

ins_gnss - double definitions for R

Hi,

R has already defined in line 163. It appears again in 181.

Barak

Velocity update signs

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?

King regards,
Flesko

Function for generating ref.mat

Dear Rodrigo,
many thanks for this useful toolbox!

Would it be possible to add also the function for generating the ref.mat data or are you using an external tool for generating it?

Many thanks.

Best Regards.
Paolo

size of DCM

Hi my friend.
I just started learning but I had a problem ...
DCMnb is 33 matrix but in ( gyro_gen_delta.m ) code you told DCMnb is N9 matrix , why?
I don't understand following code:
dcmnb = reshape(DCMnb(k,:), 3, 3);
dcmnb_old = reshape(DCMnb(k-1,:), 3, 3);

please help me to understand it. thank you

Consider a cloud CI service

Given public open source projects have free support for cloud ci services, consider leveraging one of them here. 🎉

https://blogs.mathworks.com/developer/2020/12/15/cloud-ci-services/

How to calculate gb_psd and ab_psd

Hi Dear Rodralez:
I have read most of your articles, and I have carefully studied the previous version of NaveGo code. At the same time, I have also carefully looked at the latest version of the code in recent days. You have done a good job, very Thank you; but now there is a question;
In the paper 《Performance Assessment of an Ultra Low-Cost Inertial Measurement Unit for Ground Vehicle Navigation》Table 1 and Table 2, shows the noise parameters calculated by the allan method!

In the program 'navego_example_real_ekinox.m',we can see the struct of 'ekinox_imu' , but I don't understand how you calculated ‘gb_psd’ and 'ab_psd' .
From your simulation pragram, i know the 'imu_si.gb_psd = imu_si.gb_dyn .* sqrt(imu.gb_corr)'
but when i use the dynamic error and correlation time in Table 2 to calculate it ,but i don get the same result with you !
Please help me ,thank!

Confusion about gravity direction

Hi Dear Rodralez:

I'm using NaveGo to deal with my own IMU data from UAV, during the process, I found the result was ridiculously wrong, after a careful examine, I found the gravity directions are different in my IMU data and the NaveGo code and the NaveGo simulated example data.

I used both a DJI UAV and an Xsens MTi IMU to collect the original data. Their body coordinate system are all FRD, which are supposed to be the same with NaveGo. But their data are acting differently with the NaveGo simulated example data:

↑this is the DJI UAV IMU data

↑This is the data from an Xsens MTi sensor

In both case, the body is firstly still and then moving upwards and downwards back. The upwards accelerations are negative, which meets the FRD coordinate definition well. The Z acceleration data is around -9.8,which means the gravity is -9.8 in their FRD coordinate system.

But directly providing these data to NaveGo leads to a messy result. Then I checked the simulated example data, I found the body acceleration data is like:

the Z accleration data is around +9.8, initially I thought this may be an inverted axis.But according to the simulated track, the body experienced an upward acceleration, if the axis was inverted ,the upward acceleration should be positive, however the upward acceleration is still negative with the + 9.8 gravity.

So it appears that in NaveGo the gravity is positive in the body FRD coordinate system, unlike conventional sensor's definition. Now I'm working around this problem by making:
fn_c = fn - coriolis - (g);
to
fn_c = fn - coriolis + (g);
The results get reasonable but still not perfect. So i'm wondering besides altering - (g) to + (g), is there anything else I should do to make up for the different gravity direction problem? Will this affect allan regression result?

About the "eps"

Would you mind telling me about how to calculate the
eps(time interval to compare current IMU time to current GNSS time vector (s).)

Usually, how can I get it?

In consistent tau length

Hi, I'm working with an actual IMU. While generating the error parameters using allan_imu.m, I got inconsistent tau lengths.
From line.176 of allan_imu.m, the for loop repeats 3 times, in the first time, allan_overlap() returns a tau that has 48 items, but in the second time, the allan_overlap() returns a tau that has 48 items. Then the program retuens an error says
`the dimention of left side is 48×1，the dimention of left side is 47×1。

error allan_imu (line 184)
imu.fb_tau (:,i) = tau';`

And I debugged the program, it seems that in line.301 of allan_overlap.m the program returns 48 and 47 in first and second time.

So is there a walkaround of this problem?

Glad to have your reply:)

The data I used is:
https://github.com/xelmirage/my_allan

Down velocity in INS/GNSS integration example using synthetic data

Dear NaveGo-Team, thank you for your work, I do appreciate it.

Performances of the two simulated INS/GNSS systems are compared in the file navego_example_synth.m, but the down velocity seems to be problematic (Down velocity errors of the two simulated INS/GNSS systems are always outside the margin of error).

Down velocity error of imu2:

calibration and non-orthogonality

add calibration processing for IMU data ? And also add frame transformation due to level arm effect？

Adding support for tightly-coupled integration

NaveGo's Holy Grail ;-)

Groves' book (2nd Ed.) provides MATLAB code for an implementation of tightly-coupled integration. This code can be used as a starting point for NaveGo's own implementation.

Incorrect F matrix, Velocity Update

Hi, i found following mismatch/incorrect updation of matlab software and reference "An Approach to bench-marking of loosely coupled low-cost navigation systems"

1. Equation (17C) + sign @ fc + S*() +... but in code vel_update function fnc = fn - S*() + ... (i.e fnc = fn - Coriolis +fn)
2. F matrix in equation 22, negative sign for Cbn at attitude row but in code negative sing for Cbn in velocity row.
3. Similarly for G matrix,equation 23, negative sign for Cbn at 1st row but in code negative sing for Cbn in second row.
   Please check and update or comment..!?

Missing file

myUD.m, referenced from ins.m@112

equation

Hi Dr,
I think one section of your program is wrong , am I true ?
you programed following equation in line 52 at gnss_err_profile.m :
gnss.std(2) = gnss.stdm(2) / (RN + h) / cos (lat);

but as you told in your article it must be :
gnss.std(2) = gnss.stdm(2) / ((RN + h) * cos (lat));

and I can't find the reference of this equation in the book.
thank you.

Questions about Allan Covariance unit

figure 1 is the outcome of 'navego_allan_example.m',figure 2 is gyro specification in datasheet of stim300.
What are the units of arw and vrw, respectively?Can they be identical with those in datasheet?
Thank u.

ref.mat, imu1.mat, imu2.mat, gps.mat

Could you please post ref.mat, imu1.mat, imu2.mat, gps.mat that works with your latest navego_example in matlab. I tried to use your code on Octave and FreeMat however some functions(for example matlabrc, sgolayfilt .) are not implemented in Octave and FreeMat so I would like to bypass the code which is using them by means of using mentioned ready simulation mat files instead. Thank you.

Sincerely, Adam

omega_ie_n and omega_en_n should be vectors not matrices at att_update.m

@rodralez meanwhile I think the output of omega_ie_n and omega_en_n should be two vectors, not two matrices
then when we use it in specified position, we can call skewm to get a matrix.
Otherwise, we will change the dimension of the matrix as described above

Originally posted by @scott198510 in #91 (comment)

Can not find "a_std" in acc_gen when run navego_allan_example.m

Hi Rodralez,

When I tried to run navego_allan_exmaple.m. I have got following errors:

Reference to non-existent field 'a_std'.

Error in acc_gen (line 101)
a_wn(:, i) = imu.a_std(i).* wn(:,i);

Error in navego_allan_example (line 159)
fb = acc_gen (ref, ustrain); % Generate acc in the body frame

Could you please check this issue for me whether there is some problem in stim300.mat file?

Thank you very much!
Fox

Kalman filter

I have read your paper,Nave GO : a simulation framework for low -cost integrated navigation systems. I have a question? formulation:(23.a) have matrix G and matrix U, but In your matlab simulation code,I don't see G and U.
In Kf_prediction.m , kf.xi = kf.A *kf.xp. so I am very confused about this question? please help me understand it.

Thank you for your attention ...

F_update with infinity imu.gb_corr or imu.ab_corr

Hi Authors,

I was reading the code of NaveGo and I am curious about something. When you update F without valid imu.gb_corr or imu.ab_corr, the matrix of Fbg or Fba is not produced, see lines 170 to 172 and lines 178 to 180 of function F_update. However, when MAG is switched to 'OFF', these two matrices are needed to produce G, see lines 186 to 202. So I wish to know if these were intentionally written? Could you please let me know a suggestion on these two matrices for my processing?
Thank you very much!

River

Sign of the matrix DCMbn_n in ins_gps.m

Dear Rodrigo,

thank you for the useful toolbox!

Maybe my question is very stupid. I am confused about the sign of the matrix DCMbn_n in ins_gps.m from the line 307 to 308. In the matlab code ins_gps.m, the sign of DCMbn_n is negative, however, in your paper

• (Gonzalez et al., 2015a) R. Gonzalez, J.I. Giribet, and H.D. Patiño. An approach to benchmarking of loosely coupled low-cost navigation systems. Mathematical and Computer Modelling of Dynamical Systems, vol. 21, issue 3, pp. 272-287, 2015.

the sign of DCMbn_n is positive, cf. eq (21e). I am a beginner in this area, so I am not sure whether I missed something or not.

Thanks again and best regards,

Haifeng Wu

Function coriolis_b.m is no longer used and must be deleted.

Function coriolis_b.m is no longer used for other functions and must be deleted.