I've been stuck on this problem for a few weeks now. I'm developing an error state Kalman filter and using the output of this sim as test data.
It never estimates the errors 100% correctly, so I started running my prediction code only, figuring that, if using the ref data, I should get the same answer. I've reduced all variables to only now update my attitude using the gyro reading.
I set ref_frame = 1, so not taking into account earth's rotation etc (which I do calculate exactly the same as the sim). In calc_true_sensor_output I add the following code to test the output of the gyro, just after the line that calcs the gyro reading.

gyro = c_nb.T.dot(w_nb_n + w_en_n + w_ie_n)
q1 = attitude.euler2quat(att)
print(q1)
q2 = attitude.quat_update(q1, gyro, 0.5)
print(q2)
print("_______________________")
global count
count += 1
if count == 3:
    quit()

with a count in the global frame. Basically what I'm trying to do is get the current quaternion, update it with the gyro rate, and print the new quaternion. (Yes I did hardcode dt at 0.5s, and this is also the dt used as input, the error is bigger at larger dt's). My motion file is basically, start at 0, 0, 0 with vel 0,0,0 and attitude 0,0,0. Have the following command

1,0,0.3,0.3,0,0,0,1200,1
so flipping 360 deg in pitch and roll at the same time.

I get the following printout:

[1. 0. 0. 0.]
[9.99999983e-01 1.30899693e-04 1.30899693e-04 0.00000000e+00]

---

[ 9.99999983e-01 1.30899692e-04 1.30899692e-04 -1.71347298e-08]
[ 9.99999856e-01 3.79609089e-04 3.79609089e-04 -8.22467001e-08]

---

[ 9.99999856e-01 3.79609076e-04 3.79609076e-04 -1.44103071e-07]
[ 9.99999461e-01 7.34347081e-04 7.34347081e-04 -4.13426700e-07]

---

So the first is the quat where we start and the second is the quat where we end after applying the gyro rate.
The third is the quat calculated from the att, and that should in theory be the same as the second correct? But it is not, even by a few fractions. In my ESKF I get the same value as the second, so my calculations are done the same as the built-in attitude.quat_update.

I'm I doing something wrong? Is my assumption about how to apply the rate command wrong? Is this just a limitation of double precision?

I'm not sure if this was done on purpose, but if an altitude is <0 (either reference or algo), the KML altitude is set at 0. The output pos CSV files however state the negative altitudes.

Edit: Actually, it seems that the altitude data is always 0 in display of Google Earth Pro, but when altitude is <0, it shows up as 0 in the KML file.

hello,dear@Aceinna
i have same question about the imu model?
1.which parameter is the Gaussian white noise ？
2.The imu model parameter which means in discrete sample case or in continuous sample case？ thanks alot!

During the simulation, I found a problem. After stdp and stdv are specified as 2.5 and 0.1, respectively, the simulated GPS height may tend to a certain direction of the true value. For example, the average GPS position height of the track is about -1.5m according to the statistics of the simulated GPS data. Even though I didn't do any settings on the height. Is this normal?

I stumble upon an issue in free integration as my program calculated the same problem.

I have the following motion file

ini lat (deg),ini lon (deg),ini alt (m),ini vx_body (m/s),ini vy_body (m/s),ini vz_body (m/s),ini yaw (deg),ini pitch (deg),ini roll (deg)
0,0,0,100,0,0,0,0,0
command type,yaw (deg),pitch (deg),roll (deg),vx_body (m/s),vy_body (m/s),vz_body (m/s),command duration (s),GPS visibility
1,18,0,0,0,0,0,10,0
1,0,0,0,0,0,0,10,0

Basically running North at 100 m/s at init, making a 180 deg turn to go South. After the turn I have a residual 0.314 m/s velocity in the East direction. If I then continue for 10s, my position is off by about 4 m. See the max error in the following output:

The following are error statistics.
-----------statistics for simulation attitude (Euler, ZYX)  from algo (in units of ['deg', 'deg', 'deg'])
        Simulation run algo0_0:
                --Max error: [6.63957329e-09 9.04183229e-06 4.23312952e-05]
                --Avg error: [-1.22998502e-09 -4.51875153e-06  1.69835339e-05]
                --Std of error: [1.92722543e-09 4.93997734e-06 1.31422442e-05]

-----------statistics for simulation position from algo (in units of ['m', 'm', 'm'])
        Simulation run algo0_0:
                --Max error: [1.00223908 4.70682951 0.00532531]
                --Avg error: [ 7.50355098e-01  1.80151065e+00 -1.42031785e-03]
                --Std of error: [0.35447558 1.52014583 0.0015642 ]

-----------statistics for simulation velocity from algo (in units of ['m/s', 'm/s', 'm/s'])
        Simulation run algo0_0:
                --Max error: [0.15715554 0.31415198 0.00068664]
                --Avg error: [ 0.050112    0.23549853 -0.0002667 ]
                --Std of error: [0.06053796 0.11113709 0.00021853]

The position error will obviously grow over time. I run the code as follows for the above result:

                vel_dot_n = c_bn.T.dot(accel[i-1, :]) + g_n -\
                            attitude.cross3(2*w_ie_n + w_en_n, self.vel[i-1, :])
                # Current velosity is previous plus my experienced changed in velocity
                self.vel[i, :] = self.vel[i-1, :] + vel_dot_n * self.dt

                #### propagate position
                lat_dot = self.vel[i-1, 0] / rm_effective
                lon_dot = self.vel[i-1, 1] / rn_effective / cl
                alt_dot = -self.vel[i-1, 2]
                self.pos[i, 0] = self.pos[i-1, 0] + lat_dot * self.dt
                self.pos[i, 1] = self.pos[i-1, 1] + lon_dot * self.dt
                self.pos[i, 2] = self.pos[i-1, 2] + alt_dot * self.dt
                #### output
                c_bn = attitude.euler2dcm(self.att[i, :])

In the free integration file, there was some code commented out that updates the c_bn first, calculates vel_dot_b and then vel_b, then converts the vel_b to vel, and updates the position. If I do the calculation this way around it works out correctly. See the output below:

The following are error statistics.
-----------statistics for simulation attitude (Euler, ZYX)  from algo (in units of ['deg', 'deg', 'deg'])
        Simulation run algo0_0:
                --Max error: [0.00000000e+00 1.32311075e-12 1.01268861e-11]
                --Avg error: [ 0.00000000e+00 -5.00873751e-13 -3.77686476e-12]
                --Std of error: [0.00000000e+00 3.71630599e-13 3.40864583e-12]

-----------statistics for simulation position from algo (in units of ['m', 'm', 'm'])
        Simulation run algo0_0:
                --Max error: [8.41556947e-08 1.12544081e-06 4.64393640e-04]
                --Avg error: [ 2.21354525e-08 -4.37359926e-07 -3.47980894e-04]
                --Std of error: [2.92403334e-08 3.63927099e-07 1.64325317e-04]

-----------statistics for simulation velocity from algo (in units of ['m/s', 'm/s', 'm/s'])
        Simulation run algo0_0:
                --Max error: [1.77236092e-09 7.36129863e-08 7.29224333e-05]
                --Avg error: [-3.67040030e-10 -5.51504148e-08 -2.32196570e-05]
                --Std of error: [6.70454848e-10 2.61383274e-08 2.81123335e-05]

I change the code to the following for this result:

                c_bn = attitude.euler2dcm(self.att[i, :])
                vel_dot_b = accel[i-1, :] + c_bn.T.dot(g_n) -\
                            attitude.cross3(c_bn.dot(w_ie_n)+gyro[i-1,:], self.vel_b[i-1,:])
                self.vel_b[i,:] = self.vel_b[i-1,:] + vel_dot_b*self.dt
                self.vel[i,:] = c_bn.T.dot(self.vel_b[i, :])
                
                # vel_dot_n = c_bn.T.dot(accel[i-1, :]) + g_n -\
                #             attitude.cross3(2*w_ie_n + w_en_n, self.vel[i-1, :])

                # # Current velosity is previous plus my experienced changed in velocity
                # self.vel[i, :] = self.vel[i-1, :] + vel_dot_n * self.dt

                #### propagate position
                lat_dot = self.vel[i-1, 0] / rm_effective
                lon_dot = self.vel[i-1, 1] / rn_effective / cl
                alt_dot = -self.vel[i-1, 2]
                self.pos[i, 0] = self.pos[i-1, 0] + lat_dot * self.dt
                self.pos[i, 1] = self.pos[i-1, 1] + lon_dot * self.dt
                self.pos[i, 2] = self.pos[i-1, 2] + alt_dot * self.dt
                #### output
                # c_bn = attitude.euler2dcm(self.att[i, :])

I made the IMU and GPS noise 0 to remove inconsitancy in the calculation and I am running the sim in
ref_frame=0,
in the demo_free_integraion file.

Is this problem an issue in the simulator generating the data or in the way free integration calculates?

Dear author,
In #10 Issue, you mentioned that " The accel in the body frame = c_n_to_b * f_NED = c_n_to_b * [0;0;-1]g ".
My question is, why does g need to be multiplied by -1 in the NED coordinate system? Isn't the direction of gravity consistent with that of D?
Thanks a lot.

when i run file demo_no_algo.py. i have bug "NotImplementedError: It is not currently possible to manually set the aspect on 3D axes"

First, thanks for the amazing tool!

But, I suspect there is a bug here:

Should it be

b = drift[i] * np.sqrt(1. - np.exp(-2/(fs * corr_time[i])))

or am I missing something?

With this scaling, then the drift[i] describes the standard deviation of the output process. Whereas, the original implementation just describes the standard deviation of the discretized white noise. Which means that the noise process will not be consistent if the sampling frequency is changed.

From looking at the code matplotlib is minimally used and only to show graph plots. However matplotlib drags in a lot of dependencies causing issues.

Be good if matplotlib was not referenced directly inside core gnss-ins-sim modules. Maybe a separate graphing module.

Looking for an example to create high freq trajectory from low freq trajectory.

The most similar example to start from seemed to me to be demo_free_integration.

Running the demo_free_integration.py example produces empty plots.
I modified demo_free_integration.py this way:

>> git diff demo_free_integration.py
diff --git a/demo_free_integration.py b/demo_free_integration.py
index fc2e804..b7274eb 100644
--- a/demo_free_integration.py
+++ b/demo_free_integration.py
@@ -58,8 +58,7 @@ def test_free_integration():
     ini_pos_vel_att[3:6] += ini_vel_err
     ini_pos_vel_att[6:9] += ini_att_err * D2R
     # create the algorith object
-    algo1 = free_integration_odo.FreeIntegration(ini_pos_vel_att)
-    algo2 = free_integration.FreeIntegration(ini_pos_vel_att)
+    algo = free_integration.FreeIntegration(ini_pos_vel_att)
 
     #### start simulation
     sim = ins_sim.Sim([fs, 0.0, 0.0],
@@ -68,14 +67,14 @@ def test_free_integration():
                       imu=imu,
                       mode=None,
                       env=None,
-                      algorithm=[algo1, algo2])
+                      algorithm=[algo])
     # run the simulation for 1000 times
-    sim.run(10)
+    sim.run(1)
     # generate simulation results, summary
     # do not save data since the simulation runs for 1000 times and generates too many results
     sim.results(err_stats_start=-1, gen_kml=True)
     # plot postion error
-    # sim.plot(['pos'], opt={'pos':'error'})
+    sim.plot(['ref_pos', 'pos'], opt={'ref_pos': '3d', 'pos':'3d'})
 
 if __name__ == '__main__':
     test_free_integration()

This gives empty plots:

Reading the doc, I tried to simplify the case:

>> git diff demo_motion_def_files/motion_def-90deg_turn.csv
diff --git a/demo_motion_def_files/motion_def-90deg_turn.csv b/demo_motion_def_files/motion_def-90deg_turn.csv
index 87caf81..12a3b3a 100644
--- a/demo_motion_def_files/motion_def-90deg_turn.csv
+++ b/demo_motion_def_files/motion_def-90deg_turn.csv
@@ -1,6 +1,4 @@
 ini lat (deg),ini lon (deg),ini alt (m),ini vx_body (m/s),ini vy_body (m/s),ini vz_body (m/s),ini yaw (deg),ini pitch (deg),ini roll (deg)
 31.9965,120.004,0,10,0,0,315,0,0
 command type,yaw (deg),pitch (deg),roll (deg),vx_body (m/s),vy_body (m/s),vz_body (m/s),command duration (s),GPS visibility
-1,0,0,0,0,0,0,1,0
-1,15,0,0,0,0,0,6,0
-1,0,0,0,0,0,0,3,0
+1,0,0,0,0,0,0,10,1

And still get empty plots.

What did I miss?

My initial need is to create high freq trajectory from low freq trajectory: what is the most similar example? Any advice on how to achieve this would be helpful.

Note: my low freq trajectory is a collection of n-uplets {timestamp, lat, lon, alt, roll, pitch, yaw, ax, ay, az, wx, wy, wz}

Downloaded repo
Opened powershell
ran py -m venv env
ran & env/Scripts/Activate.ps1
ran pip.exe install numpy
ran pip.exe install matplotlib
ran python.exe .\demo_no_algo.py

Got the following error
NotImplementedError: Axes3D currently only supports the aspect argument 'auto'. You passed in 'equal'.

Quick look in code did not show where we set it as equal or where to set it as auto

Hello.

I noticed a slight disparity between the computation of vector w_nb_n (angular rotation vector from b to n expressed in n frame) in function calc_true_sensor_output of file pathgen.py comparing to the formulae that I found in various theory sources.

It seems that you are interpreting the result as w_nb_n, but these authors say that this vector is actually w_nb_b (that is, expressed in b frame coordinates).

Sources:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.668.1629&rep=rep1&type=pdf Eq.9 ,
https://www.atlantis-press.com/article/25897503.pdf Eq. 18,
Springer Handbook of Global Navigation Satellite Systems, Chapter 28, Eqs (28.21)-(28.23)

Am I missing something, or is this correct?

Thank you for your time

Different GPS generated using int and float longitude and latitude.

attitude.D2R: 0.017453292519943295
ini_pos_n: [ 32. 120. 0.]
calculated ini_pos_n: [0.55850536 2.0943951 0. ]

attitude.D2R: 0.017453292519943295
ini_pos_n: [ 32 120 0]
calculated ini_pos_n: [0 2 0]

Hi, I have an issue with getting the simulated accelerometer and gyroscope measurements to match with a real life case. I'm trying to replicate IMU data that was recorded during a metro ride that includes 2 approx. 75 deg turns. First left then right. I flipped the IMU with initial pitch of 180 deg to get positive z-acceleration and assigned an initial velocity v_y = 20m/s. Then I simulated these 2 turns with constant yaw rate during 40 sec. (I ignored the acceleration periods in y-direction)

The results match pretty well with the real life case except that the acceleration in x-direction is negative during the left turn and positive during the right turn. I would assume that these should be opposite if the accelerometer coordinate frame follows the right hand convention?

I am running simulations and I cannot make GPS positions to show any variations from their initial values, except for the altitude which varies if I make the vz velocity vary.

I have tried a lot of different motion profiles:

• Various initial states (zero and non-zero velocities; zero and non-zero Euler angles);
• Various motion commands (zero and non-zero changes in Euler angles or velocities; different command types);
• I made sure I have gps=True in the IMU model and that GPS visibility is 1;
• I tried with no algorithms and with different built-in algorithms;
• I tried with the two reference frames.

In all my experiments, GPS latitude and longitude (gps_lat, gps_lon) stayed at there initial value. I am refering to both the 'ref_gps' results and the 'gps-0' results (with or without GPS uncertainty).
I was expecting the latitude and longitude to vary when for example vx or vy vary, which is not the case.

In addition, in the results with uncertainties, only the altitude has noise, while latitude and longitude are always flat curves.

To reproduce this issue, I am attaching the results I obtain with the motion file motion_def-simple.csv (also attached) and with the main code demo_no_algo.py.

accel-0.csv
att_euler.csv

att_quat.csv
gps-0.csv

gps_time.csv
gps_visibility.csv

gyro-0.csv
ref_accel.csv
ref_att_euler.csv

ref_att_quat.csv
ref_gps.csv

ref_gyro.csv
ref_pos.csv

ref_vel.csv
summary.txt
time.csv
motion_def-simple.csv

RE: https://github.com/Aceinna/gnss-ins-sim/blob/master/gnss_ins_sim/pathgen/pathgen.py

It looks like to me you this simulation only considers constant bias (or turn-on bias; static bias in your code at line 520), bias instability (bias drifting in your code at line 522), and angle random walk (white noise in your code at line 524).

I have a question that why rate random walk is not considered in the simulation. Does it have a neglectable effect on the gyro error?
According to these references, it seems rate random walk also has a considerable effect on the simulation of the gyro error:

1. Jay A. Farrell, Felipe O. Silva, Farzana Rahman, and Jan Wendel, “IMU Error State Modeling for State Estimation and Sensor Calibration: A Tutorial”, May 2019. [Link].
2. Elder M. Hemerly, “MEMS IMU stochastic error modelling”, Systems Science & Control Engineering, vol. 5, Jan. 2017, pp. 1–8.
3. Vaibhav Saini, S C Rana, and MM Kuber, “Online Estimation of State Space Error Model for MEMS IMU”, Journal of Modelling and Simulation of Systems, vol. 1, 2010, pp. 219--225.

Also, do you have a good reference to simulate the bias instability as a white noise sequence, rather then a random walk sequence, when there is no correlation input (line 558 in the code)? I think it is improper as suggested by the above references 2 and 3.

在pathgen.py文件中的函数 def calc_true_sensor_output(pos_n, vel_b, att, c_nb, vel_dot_b, att_dot, ref_frame, g) 中
406~411行代码如下：
# Gyroscope output
gyro = c_nb.T.dot(w_nb_n + w_en_n + w_ie_n)
# Acceleration output
w_ie_b = c_nb.T.dot(w_ie_n)
acc = vel_dot_b + attitude.cross3(w_ie_b+gyro, vel_b) - c_nb.T.dot(gravity)
return acc, gyro, vel_dot_n, pos_dot_n

在计算真实加速度时，这一项

attitude.cross3(w_ie_b+gyro, vel_b)

中的gyro项里面包含了w_nb_n，是否合理？

Hello, is it possible to simulate the attitude change of the IMU sensor without changing the attitude and velocity of the vehicle?

For example, I want to simulate that the IMU data would come from a smartphone inside the vehicle and that the attitude of the smartphone could change during the ride.

Thanks!
Oskari

I am trying to simulate an imu augmented magnetometer based on a motion trajectory. if I can know the magnetic strength and robot pose, I can calculate the mag_x, mag_y,mag_z. But how can I know the magnetic strength? I guess I can get it based on location on earth?
Or could you recommend some papers or tutorials on how to simulate a magnetometer?

Hi,
Thanks for the open source algorithm, almost all functioned for me.
I would like bring to your kind attention the following error in demo_ins_loose.py

Traceback (most recent call last): File "C:/gnss_ins_sim/demo_ins_loose.py", line 63, in <module> test_ins_loose() File "C:/gnss_ins_sim/demo_ins_loose.py", line 55, in test_ins_loose sim.run(100) File "C:\gnss_ins_sim\gnss_ins_sim\sim\ins_sim.py", line 177, in run algo_output = self.amgr.run_algo(algo_input, range(self.sim_count)) File "C:\gnss_ins_sim\gnss_ins_sim\sim\ins_algo_manager.py", line 101, in run_algo results[self.output_alloc[i][j]][this_algo_name+'_'+str(key)] = this_results[j] IndexError: list index out of range

After checking, I found that index j is out of range.

Thank you very much for your help in advance!!

Hello,

Thank you for sharing this toolbox. I was wondering: what are reference frames (world vs body) for command type 1 inputs? It seems to me that the rotation rate inputs are in world frame while the acceleration is in a body-fixed frame; is that correct.

For reference, I am attempting to generate IMU data for a known trajectory, given as NED positions and orientations. I have differentiated to get velocity, acceleration, and rotation rates, and use the attitude to transform the accelerations into body-frame. After disabling the filter on the inputs, this seems to give me the correct reference accelerations (ref_accel), rotation rates (ref_gyro), and attitudes (ref_att_euler) but the outputs for position (ref_pos) and velocity (ref_vel) do not match the source data.

I'm trying to track down what I am doing incorrect, and would appreciate any advice.

Hi!

In the context of IMU simulation in a static setting, we've run into issues using the constants in geoparams because of the "hard-coded" values FLATTENING and E_SQR.

I'd change to FLATTENING = 1/298.257223563 and E_SQR = ECCENTRICITY**2?
The first is the WGS-84 definition of flattening. The second removes a 1e-12 error that integrates to small drifts.

Thanks for open-sourcing this simulator: it's great!

At first, thank you very much!

Could you explain , how the position error results depend on the fs ?
I am trying to set zero error for gyro and acc and get non-zero error when fs=10 (demo_free_integration).
Or am I missing something important?

Hi!
Thank you for your code.
I am doubt whether your code can use to create data for simulation of Ultra-tightly integrated ins/gnss navigation?

Hi @dxg-aceinna! Firstly,this library is super useful!! Thank you very much for putting something so comprehensive together!

I have been looking into your Mahony algorithm and was wondering if there was a source you based it on as it is different from the standard implementations in literature. It almost seems like you merged in elements of the Valenti complementary filter. I would be very interested if you had some relevant articles I could read.

Thanks!

Hi,

Function： In the function geoparams.py "lla2ecef(lla)"
Data: motion_def-3d.csv, I modify the init lat/long to 1° and 1°.
Function return value: (x,y) = (6.38E+06 , 1.11E+05). Actually you can check in the result txt file: ref_gps.csv.
Thanks very much.

Best Regards
Jun Wang

(I don't know if you take this sort of usage question in the issues, I can move it elsewhere if you prefer!)

I would like to generate a circular trajectory (for benchmarking) using the simulator. Ideally, I'd like to have: constant speed in the body frame (say v_x = 1 m/s) and so constant y acceleration.

I can't quite get the motion definition file right. The best I have is using type 3 commands in the motion definition file. While the speed seems constant and position is periodic (lat and long return to the starting point), acceleration in the y direction is not constant and thus the movement is not circular. See attached motion def file.
circle.txt

def __parse_mode(self, mode):
'''
Parse mode. Not completely implemented yet.
Args:
mode: simualtion mode
'''
if mode is not None:
if isinstance(mode, str): # choose built-in mode
mode = mode.lower()
if 'flight' in mode:
mobility = high_mobility
elif 'land' in mode:
mobility = high_mobility
elif 'ship' in mode:
mobility = high_mobility
else:
mobility = high_mobility
elif isinstance(mode, np.ndarray): # customize the sim mode
if mode.shape == (3,):
mobility[0] = mode[0]
mobility[1] = mode[1] * attitude.D2R
mobility[2] = mode[2] * attitude.D2R
else:
raise TypeError('mode should be of size (3,)')
else:
raise TypeError('mode should be a string or a numpy array of size (3,)')
else:
mobility = high_mobility
return mobility

varible mobility not defined

Dear all,

Thank you very much for sharing & contributing the open source implementation.

in function ins_algo_manager()

def run_algo
at line 95 in code:
results[self.output_alloc[i][j]][this_algo_name+'_'+str(key)] = this_results[j]

this_results is list with value [NoneType]

IndexError: list index out of range as j goes from 0 to 4

how this error could be corrected??
Thanks for your help in advance.

请问一下可以输出ENU坐标系的数据吗？如果可以的话需要怎么设置呢？

感觉要对加速度计、陀螺仪和磁力计的数据进行坐标变换，交换x和y的数据，并对z轴数据取反。我对导航的理解还很浅，如果不对还望您谅解。

十分感谢！

I believe there is an issue in GPS noise generation when multiple runs are used, because of the way the gps_error dictionary is used.

Bug reproduction

Using the demo_no_algo.py:

1. comment out the plotting line
2. change sim.run(1) to sim.run(10) (for example)
3. change ref_frame from 1 to 0

Open gps-0.csv, gps-4.csv and ref_pos.csv. As you can see, the gps-4.csv data is identical to the ref_pos.csv data in the first two columns (lattitude and longitude). However, in the gps-0.csv file, this is not the case, and the noise level is consistent with the GPS error model dictionary (here, the built-in one).

Bug description

In the gps_gen function below, the gps_err dictionary is a class attribute, passed as reference, that is modified at each simulation loop. And so, dividing by the Earth's radii, becomes exponentially small as runs are simulated.

def gps_gen(ref_gps, gps_err, gps_type=0):
    '''
    Add error to true GPS data according to GPS receiver error parameters
    Args:
        ref_gps: If gps_type is 0, [Lat, Lon, Alt, vx, vy, vz], [rad, rad, m].
                 If gps_type is 1, [x, y, z, vx, vy, vz], [m, m, m].
                 ref_gps data are expressed in the navigation frame.
        gps_err: GPS reeceiver parameters.
            'stdp': RMS position error, [m, m, m].
            'stdv': RMS velocity error, [m/s, m/s, m/s].
        gps_type: GPS data type.
            0: default, position is in the form of [Lat, Lon, Alt], rad, m
            1: position is in the form of [x, y, z], m
    Returns:
        gps_mea: ref_gps with error.
    '''
    # total data count
    n = ref_gps.shape[0]
    # If position is in the form of LLA, convert gps_err['stdp'] to LLA error
    if gps_type == 0:   # GPS is in the form of LLA, stdp meter to rad
        earth_param = geoparams.geo_param(ref_gps[0, 1:4])
        gps_err['stdp'][0] = gps_err['stdp'][0] / earth_param[0]
        gps_err['stdp'][1] = gps_err['stdp'][1] / earth_param[1] / earth_param[4]
    ## simulate GPS error
    pos_noise = gps_err['stdp'] * np.random.randn(n, 3)
    vel_noise = gps_err['stdv'] * np.random.randn(n, 3)
    gps_mea = np.hstack([ref_gps[:, 0:3] + pos_noise,
                         ref_gps[:, 3:6] + vel_noise])
    return gps_mea

Fixing the bug

I would like to propose to submit a PR calculating the latitude and longitude standard deviations in local variables. Would you be open to that?

Environment

Cloned master branch in new Python venv with only numpy and matplotlib added.

Hi,

thanks for the great project, it's really helpful for me. I have a q though, is it possible for you guys to add a offcial license?

In your setup.py you state MIT License, but I couldn't find it in the repository. Here's a tutorial: https://help.github.com/en/github/building-a-strong-community/adding-a-license-to-a-repository

Thanks again :)

When I get the trayectory and I obtain the accelerometer data and reference quaternion, I've checked the acceleration measurements from the transformation the acceleration measurement. When the quaternion is [1,0,0,0], in this case, the acceleration measurements is [7.328724153415264002e-03,-7.097695153575984614e-04,-9.801918481487374990e+00].
After the transformation, with the quaternion [0.793 +0.609i +0.000j +0.000k] , the acceleration should be [ 7.32872415e-03 9.46751078e+00 -2.53847319e+00], but the acceleration obtained from simulation is [-0.004411866173716657, -9.473102208586964, -2.5396297352216073].
Thanks a lot!
Carlos

It would make the simulation much more realistic.

Looking at the function euler_update_zyx, the attitude is fed in and returned as [psi theta phi] (i.e. zyx - yaw, pitch, roll) and not [phi theta psi] as all the comments state. The gyro reading is fed in as [phi theta psi] (i.e. xyz).

The function works and is used 4 times in the project correctly, so no need to fix it, the comments just seem off and it is odd that x and w are in different orders, just something to take note of when using the function.

If you run " demo_free_integration_long_time.py" with mid-accuracy, you get odd results.

#imu_err = 'low-accuracy'
#imu_err = 'high-accuracy'
imu_err = 'mid-accuracy'

generate GPS and magnetometer data

imu = imu_model.IMU(accuracy=imu_err, axis=6, gps=False)