uNav INS

Mike,
What will you use for base station? Wondering if I need two. We don't have one of those RTK broadcast stations near by.

Don
 
Hi Don

It doesn't have to be that close and you should have at least one a few miles from your home. Have you checked: https://geodesy.noaa.gov/CORS_Map/ for available stations. If you can not find one you will need a second one to set up as a base station. I have done it with two of the old firmware versions of an M8N and it does work. I changed since I have at least 4 stations within 10 miles of the house and the close a 1/4 mile away. One advantage of living in NY.

Mike
 
Mike, Tim, Brian, tonton81,
Did you all see this announcement?

https://www.u-blox.com/en/press-rel...cision-gnss-module-based-u‑blox-f9-technology

I've not been able to get my Here+ unit to ever go from RTK-Float to RTK-Fixed (cm-level accuracy) mode. This new multi-band uBlox should fix that. It's been rumored that this was soon-to-be-released...

P.S. Back from a cross-country trip, Houston to Taos for hiking. I ran my uNavINS setup on my dashboard for part of the trip, was fun to see the unit and code work at highway speeds and varying altitudes!

Don
 
Hi Don

Yea. I saw that but not sure how long before you start seeing breakout boards for it.

Not sure why you can't RTK-fix with the Here+'s. I have my M8N running on RTKLIB sitting by the window and I get a RTK-FIX. Takes about 10 minutes before it converges.

Mike
 
Mike,
I need to set up RTKLIB this week. I'm using the Here+ with the ArduPilot mission planner software, so maybe there's something funky with that setup.

When RTKLIB is showing "RTK-FIX", does that mean carrier integer ambiguities are really solved for? For Ardupilot, it shows RTK-Float if RTK is working, but the integer ambiguity (on the carrier phase waveform) is not resolved. It must transition to RTK-Fixed mode on the Ardupilot Mission Planner for cm-level accuracy with integer ambiguity resolved.

Would you recommend I get RTKLIB from the main website (http://www.rtklib.com) to get started, or is there a different/better source?

Thx!!
Don
 
Mike, Tim, Brian, tonton81,
Did you all see this announcement?

https://www.u-blox.com/en/press-rel...cision-gnss-module-based-u‑blox-f9-technology

I've not been able to get my Here+ unit to ever go from RTK-Float to RTK-Fixed (cm-level accuracy) mode. This new multi-band uBlox should fix that. It's been rumored that this was soon-to-be-released...

P.S. Back from a cross-country trip, Houston to Taos for hiking. I ran my uNavINS setup on my dashboard for part of the trip, was fun to see the unit and code work at highway speeds and varying altitudes!

Don

That looks interesting!
 
another note... I just traded emails with Jerome at Drotek. He says that to get cm-level RTK, you need to have a high quality antenna, like the Tallasman version they sell. So I'm thinking this is the main reason I don't get the transition from RTK-Float to RTK-Fixed on the Here+. My guess is a lot of folks using the Here+ (with Ardupilot Mission Planner) see that it's in RTK-Float mode on the Mission Planner display and think that this means they're getting cm-level fixed ambiguity accuracy, when in fact they are getting 1-3m accuracy because they have not solved for integer ambiguity. The Here+ doesn't seem to come with a very high quality antenna from what I can see on mine.

Don
 
Mike,
The Tallyman antenna is one of the antennas Drotek recommends.

I just got in two new GPS units, the M8T from Drotek and a couple of cheap Stoton GN-801 (Chinese) boards. The GN-801s have PPS. The M8T I can use to familiarize myself with RTKLIB. Unfortunately neither of these allow for external antennas. When the uBlox F9 is avail this Fall, I'll plan to get one with external antenna connector. By then I should be up-to-date with RTKLIB I hope. Might be asking you some questions on RTKLIB soon! What do you think about us starting a new thread on using Teensy with RTKLIB and uBlox???

P.S. I'm thinking there could be some cool ways to blend the AHRS stuff you, Tim, and I have been doing with the capabilities of the new F9 chip (20Hz update rate!!) when it's avail in a breakout board in a few months. Could be really cool I think...

Don
 
Let's start easy.
I'm thinking there could be some cool ways to blend the AHRS stuff you, Tim, and I have been doing with the capabilities of the new F9 chip (20Hz update rate!!) when it's avail in a breakout board in a few months. Could be really cool I think...
Yep - can be done - once it gets a RTK Fix solution easy enough to do.

Might be asking you some questions on RTKLIB soon! What do you think about us starting a new thread on using Teensy with RTKLIB and uBlox???
Right now rtklib can not run on a teensy. It windows or Linux only. With that said there is a command line version called rtkrcv that I have been working with lately and most of it can probably work on a teensy except for the stream stuff since it uses a lot of tcp type connections etc. That whole piece would have to be rewritten as well as the screen portion. Is it doable - yeah its doable but I don't know enough about how to do the stream - think the different connections it uses are http, ftp, tcp/telnet, https, ntripcli, ntripsvr, etc. A little beyond me except for some pieces. Yes I was already thinking about how to go about doing it - big job but might work - would use a T3.6. For the base station of course. For the rover don't know yet.

avail in a breakout board in a few months.
All depends on the pricing for the F9 - probably will be expensive just to experiment with.

Mike
 
Mike,

I have one of Brian's Marmot boards, which plugs into a BeagleBone Black (arriving next week) running Linux Debian. So that (Beaglebone) might be an option. I'll be downloading RTKLIB this weekend or early next week, planning to run it on my Surface. Going to connect to CORS first to test, then will use the two additional M8Ts I have coming.

I've also gone back and am testing / cleaning up the last AHRS filters library you pulled together. It was MPU9250_FiltersV8, and I'm testing the various modes (w and w/o mag) and trying to fix any that aren't outputting correctly. I'll repost on the uNavAHRS area when I get it finished. I'm also adding a "fixed dt" option, which I think will be nice to have.

Don
 
tonton81,

you want the general form for standard deviation, the "population" version, where you divide by n,

not the "sample" form for standard deviation where they calculate it a bit different and divide by n-1

The link I sent on my post from last night has a nice example with real numbers that we can test with, using a population size of 20 samples. for his example of 20 samples, mean comes out to 7, and standard deviation comes out to 2.983.

Don

Been following along for a project of mine! I was using this calculator to test: https://www.surveyking.com/help/standard-deviation-calculator

Looks like the sample standard deviation is 41.3462 :cool:
 
Circular_Buffer library does all the calculation work for you to get all those values via mean(), variance() and deviation() :)
 
Just found this code and it looks very interesting. For my application, I need to have a remote antenna. I read in the thread that the PPS needs to be broken out. Besides the PPS signal is there any suggestions/recommendations for a GPS compatible with the example codes?

Also, for the IMU side has there been given any consideration to a solution like https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/ ? I have seen a lot of discussion about the IMU stability/initialization/calibration and so on and it seems that this may answer a lot of the issue "off board" the Teensy.

Your thoughts are appreciated.

Thanks

Bruce
 
Hi Bruce,

Sorry I haven't gotten to your email yet. I don't have a good recommendation for a uBlox 8 series receiver with external antenna. Most manufacturers include only a patch antenna and expect the receiver to be remote mounted. Another Teensy Backpack customer (AllanGH on the forum) has this breakout:
https://www.sgbotic.com/index.php?dispatch=products.view&product_id=2386

It looks like it would work well and has an external antenna, but I have no first hand experience with it. Similarly, CSG Shop (https://www.csgshop.com) has some boards that look promising (external antenna and breakout to 0.1" headers for power, ground, and UART) like this one:
https://www.csgshop.com/product.php?id_product=187

They tend to be more expensive and I don't have first hand experience with their 8 series boards. Any uBlox 8 series board should be compatible with my uBlox library:
https://github.com/bolderflight/UBLOX

PPS isn't currently used in the 15 state EKF - the GNSS data is applied as a measurement update to the current IMU data at the timestep when new GNSS data is detected. Any propagation delay in the GNSS receiver or the communications interface leads to some error and needing to use a higher uncertainty value (i.e. covariance) for the GNSS measurements. I've thought of using the PPS signal to apply the measurement update to the corresponding set of IMU data, which should remove this source of error, but I haven't gotten around to it yet and I'm not sure that it would make a noticeable difference on the filter output given the inaccuracy of the GNSS position measurements anyway. I think this may become more important when the newer dual band GNSS receivers become available - we're expecting dm levels of accuracy and at that point, taking care of the propagation delay might be worthwhile. But at this point there's so much uncertainty in the GNSS position measurements that I don't think it would make a difference.

Stability with the EKF 15 state INS filter is quite good if there is motion. Both filters (AHRS and INS) need motion for their estimations to work properly. For very low dynamic environments, something like a tilt compass would be more appropriate. The AHRS suffers due to its reliance on magnetometers, their susceptibility to noise, and the poor resolution of the MPU-9250 magnetometers. The 15 state INS filter here does not use magnetometers for heading. I don't think adding an extra layer of obfuscation through the tindie board would help, it wouldn't be able to run the INS filter presented here, so you'd be trying to cobble together the attitude estimate from the tindie board with the position and inertial velocity estimate from the INS. You would be estimating accelerometer and gyro corrections, but wouldn't have a method of applying those back to the tindie board to generate a better attitude solution. I think it's a good product for what it is - a low cost attitude solution, but it would be more accurate to have the 15 state INS filter estimate all of the states, including orientation, rather than that board.

Brian
 
Can you provide a link/location of any material which details the derivation of the 7 and 15 state EKF to which you have ported to GitHub?

Thanks

Bruce
 
Stability with the EKF 15 state INS filter is quite good if there is motion. Both filters (AHRS and INS) need motion for their estimations to work properly.
This still gets me frustrated, i.e., the performance of the Kalman filter with zero motion. In doing a bunch more research and going back to my notes from years ago I found this presentation on a project called OpenShoe (page 20 and 21) that is used for foot-mounted ins which uses a Kalman filter. To address it they seem to only do filter updates when there is motion, or acceleration exceeds a certain value. The approach I used to detect motion incorporates both the accelerometers and gyros. Anyway, don't know if this is an approach that can be adapted to the 15-state version of the uNavINS.

Mike
 
Hi Brian
Did something that I saw a long time ago.... I am now running the MahonyAHRS filter in parallel with the Kalman filter. When there is zero motion I use the yaw derived from MahoneyFilter and when the IMU is moving it uses the Kalman filter output. The Mahoney filter doesn't seem to be as susceptible to yaw drift as much as the Kalman filter.

Just thought I would let you know what I have been playing around with. A bit redundant but...

Mike
 
Back
Top