What is 'State of the Art' for IMU + GPS on teensy 3.x 4.x

ninja2

ninja2

Well-known member
Circa 2017 I was deep in playing with the MPU9250 using a beta version of Brian Taylor's library (and Kris Winer's) and Adafruit GPS module using NeoGPS by SlashDevin . I was running these on T3.5, Mega 2560 (I could even squeeze a fully functional datalogger onto a R3 UNO using NeoGPS).

I am keen to revisit and updating to the most suitable current hardware + libraries. The recent thread New Madgewick Fusion Filter provides a lot of tempting clues but the more I look and read it's seems I've uncovered just the tip of a massive iceberg.

I'm hoping to get pointers to good/best IMU + GPS + library combinations on T3.x or T4.x, all with highest precision possible (e.g. RTK cm accuracy) given a generous budget :)

Thanks in Advance ...
 
Define a generous budget?

I spend a lot of time playing with IMUs and GPS but not in teensy/Arduino environments so I can't comment on specific libraries.

From a GPS/GNSS the ublox F9 is generally the best price/performance compromise, you can get some cheaper systems from China but in my testing the performance isn't quite there.
But this is where the definition of "generous budget" matters, you can get some far better GNSS systems. Septentrio have some very nice modules that will get you better accuracies, more systems, higher output rates than the ublox. Plus things like built in NTRIP. But you're looking at 10-20 times the price.

One thing I would say on GNSS is if you are aiming for good accuracies then you want a module specific library. You will probably want to use some of the module specific configuration commands and standard NMEA outputs don't give good enough resolution. Well they can but that's non-standard so whether the library will parse it correctly matters. Plus if you are looking to use any sort of kalman filtering then output in ECEF makes more sense than latitude/longitude.

Other considerations to keep in mind - Good accuracies need a good antenna and clear view of the sky. And you will need some form of RTK correction source, either RTCM over serial or NTRIP over a network. And not all RTCM is equal, you need to ensure it includes the formats and messages your receiver can use. e.g. using a ublox base station to a different brand receiver will often result in the other system losing RTK at random times.

In terms of inertial analog devices have some nice modules for a few hundred dollars. But again budget matters a lot. For good inertial you can easily pay multiple thousands of dollars.
 
Thanks AndyA, much good info.
However I'm really looking for input on the best combinations of libraries with IMU and GPS that have proven to work well on teensy
After reading more on RTK overnight it's dependence on a fixed base station probably rules it out for my mobile platform.
Hopefully there are solutions using SBAS or DGPS.
As for my 'generous budget' ... ot unlimited = 100's not 1000's:)
 
Last edited:
ninja2 said:
After reading more on RTK overnight it's dependence on a fixed base station probably rules it out for my mobile platform.
Hopefully there are solutions using SBAS or DGPS.
Click to expand...

Any modern GNSS will include SBAS however that is only for GPS so you often have the choice of GPS+SBAS or GPS+GLONASS+Galileo+Beidou.
If you have a good clear view of the sky GPS+SBAS will be best, if your view of the sky will be partly obscured (trees, tall buildings, non-ideal antenna placement) then the extra satellites may be better, the best case position isn't quite as good but the solution will be more robust.

If you have a network connection then there are NTRIP services available which can give you national or global RTK coverage. You send them your location (normally NMEA GGA once every 1-10 seconds) and they either send you the data for the closest base station or calculate the values for a virtual base at your exact location. These network RTK solutions are available just about everywhere, most RTK GNSS providers have a service to supply this for a subscription and in some areas the national/state government makes them available for free.
Google is your friend here, throw network RTK or RTK corrections service and your location in and you'll get lots of options.

If you do use an RTK service rather than your own base then be aware of which datum is used. e.g. in europe most network RTK systems will use ETRF (European terrestrial reference frame) , stand alone GPS defaults to WGS84. The two are about 50cm different due to a few decades of continental drift. This isn't normally an issue, it's in the measurement error of non-RTK GNSS, but can cause lots of confusion if you notice the change in location and don't know why you're now getting a different location for the same point.
 
A good IMU+GPS integration could be found on the Ardupilot project. It is mainly based on STM32 hardware.

In the Plane sub-project, centripetal forces are taken in account. Depending on your application, you should use it.

Angelo
 
Unfortunately I've learnt SBAS rollout won't be completed here in Australia until 2026 !
 
ninja2 said:
Unfortunately I've learnt SBAS rollout won't be completed here in Australia until 2026 !
Click to expand...
LOL! I worked on a military guidance and control application some years ago where our results with UBlox systems were very good at our test site in Arizona. I kept telling the management to adjust their expectations if the system was used outside the continental USA. The answer was usually something like "We'll worry about that if we get next-stage funding." That translated to "the unit cost and key distribution issues for military-grade GPS units won't fit in our budget."
 
AndyA said:
Going by this site
https://www.ga.gov.au/scientific-to...ational-positioning-infrastructure-capability you should be able to get RTK corrections over NTRIP for free. That will however require an internet connection of some sort. The bandwidth requirements are tiny so if you're paying for data used then it won't be much but it does need a connection.
Click to expand...
That looks quite promising ... 3cm accuracy would do nicely. Thanks AndyA.
Now I just nedd to work out best way to get mobile internet ..
 
OK, I've found a good mobile internet solution. Now I'm looking at the Sparkfun GPS-RTK-Kit (with u-blox's ZED-F9P) and pondering the details for setting up RTCM over NTRIP.

According to Google Gemini (yes, it's AI :)) NTRIP uses a client-server model where the client is a phone or a computer.
My design concept has the mobile internet connected to my phone by WiFi, and Bluetooth (or another WFi?) to my T4.1, hardwired to the Sparkfun GPS-RTK device.

Is this viable?
TIA
 
Last edited:
ninja2 said:
OK, I've found a good mobile internet solution. Now I'm looking at the Sparkfun GPS-RTK-Kit (with u-blox's ZED-F9P) and pondering the details for setting up RTCM over NTRIP.

According to Google Gemini (yes, it's AI :)) NTRIP uses a client-server model where the client is a phone or a computer.
My design concept has the mobile internet connected to my phone by WiFi, and Bluetooth (or another WFi?) to my T4.1, hardwired to the Sparkfun GPS-RTK device.

Is this viable?
TIA
Click to expand...
I would say yes. You can take a look at Sparkfun library examples for the f9p: https://github.com/sparkfun/SparkFun_u-blox_GNSS_v3/tree/main/examples/ZED-F9P which should give you an idea.

Or take a look at this: https://community.gpswebshop.com/20...ss-receiver-for-android-a-step-by-step-guide/
 
After further reading, and experimenting with my new NTRIP provider account / service, I've realised I can probably do without separate mobile internet hardware, instead just run the NTRIP client on my phone which has internet via 4G (still waiting for 5G in some areas around here) (as AndyA said "The bandwidth requirements are tiny" so this should be fine)

I'm looking at the Sparkfun Micromod ZED-F9P module fitted with the SparkFun MicroMod Teensy Processor . I haven't looked closely but I'm (maybe naively) assuming Sparkfun's teensy is (almost) equivalent to PJRC's T4.1? (it uses the MIMXRT1062 chip, with same bootloader and flash chips)
to add BT
... and I really hope PJRC get's a cut for the Sparkfun teensy clone! (I have purchased two PJRC T4.1 already)

hmmm ... just dawned on me: I've still got to add bluetooth somehow? Back to the drawing board ....
 
ninja2 said:
... and I really hope PJRC get's a cut for the Sparkfun teensy clone! (I have purchased two PJRC T4.1 already)
Click to expand...
The other chip on the board next to the IMXRT is PJRC's T4.x "bootloader" (which isn't strictly a bootloader at all). It's only available from PJRC so they do earn something from the micromods.
 
I had no luck with bluetooth in the USBHost_t36 library because even though it checks for supported features, it always issues LE commands regardless during initialization which fail on hosts that don't support it.
 
I asked this question on Sparkfun forum several weeks ago, with no response as yet :

I have a MM Main Double board, with Teensy 4.1, ZED-F9P GNSS Function board (in F0 slot) and ESP32-WROOM Function Board (in F1).

After studying all the schematics and pin-out it seems there is no Serial (Tx/Rx) channel to the ESP32. The ZED-F9P is working fine via Teensy Serial (Serial0) but AFAIK there is no way to communicate with the ESP32, i.e. there is no Serial1 or Serial2 from Teensy to ESP32.

On the off chance that the docs might be wrong, I tried to connect to ESP32 using Serial, then then Serial1 and then Serial 2. None would respond to “AT+GMR” command.

It seems there is no Serial path from teensy to ESP32. That would make it impossible to use. Is this correct ?
 

Attachments

  • MM ESP32 WiFi Bluetooth schematic.pdf
    207.6 KB · Views: 35
ninja2 said:
I asked this question on Sparkfun forum several weeks ago, with no response as yet :

I have a MM Main Double board, with Teensy 4.1, ZED-F9P GNSS Function board (in F0 slot) and ESP32-WROOM Function Board (in F1).

After studying all the schematics and pin-out it seems there is no Serial (Tx/Rx) channel to the ESP32.

It seems there is no Serial path from teensy to ESP32. That would make it impossible to use. Is this correct ?
Click to expand...
The teensy pins named Tx1/17 and Rx1/16 (I'm guessing Serial 1 but haven't double checked) go to Micromod connector pins 20/22 (Tx2 and Rx2).
On the base board these are called TX2_Processor and RX2_Processor and go to FC1 pins 13 and 15 (Rx and Tx). On the ESP function module these pins are called 16/Rx and 17/Tx and go to pins 16 and 17 on the WROOM.

So the teensy isn't connected to the primary serial port on the ESP but is connected to two pins that can be used as as serial port if the ESP is programmed correctly. You need to program the ESP with suitable firmware to use those pins for the UART and it should work.
The primary serial port on the ESP is connected to the USP port for firmware upload.
 
Thanks muchly @AndyA, you're suggestions made me take another deep dive into all the lists/schematics again and confirmed your points.

The numbering and labelling is all a bit of a nightmare but below is my detailed summary for the serial connection path to a Sparkfun ESP32-WROOM-32 board in F1 slot in Micromod land.

Curiously even though the serial path originates from [AD_B1_07/AD_B1_06] on the Teensy MMod processor (which normally maps to Serial4 on a standard T4.1) it is on Serial2 on the Micromod Teensy!

Code: 
General Config
--------------
MMod Main Double Board with:
Processor: T4.1
F0: ZED-F9P GNSS (on Serial1)
F1: ESP32-WROOM-32 WiFi/Bluetooth (on Serial2)

Connections T4.1 <-> ESP32
--------------------------
MMod Teensy 4.1   pins: K10/J12 (RX1/16/A2,TX1/17/A3)         [AD_B1_07/AD_B1_06] Serial2 to
MMod on processor pins:  20/22  (RX1/16/A2,TX1/17/A3)         [RX2/TX2] to
MMod Main Double  pins:  20/22  (RX2-PROCESSOR,TX2-PROCESSOR) [RX2/TX2] to
MMod for F1       pins:  13/15  (RX2-PROCESSOR,TX2-PROCESSOR) [TX/RX] to
MMod on ESP32     pins:  13/15  (17/TX,16/RX) to
ESP32-WROOM-32    pins:  28/27  (17/TX,16/RX) [IO17/IO16]

References:
-----------
MMod Standard     pins:  20/22  (UART_RX2/UART_RT2)
Standard T4.1     pins: 16/17 (A2/A3) [AD_B1_07/AD_B1_06] RX4/TX4 = Serial4

And to much delight I just proved this all works with this sketch:
Code: 
// use Serial1 for ESP8285 onb T4.1 dev board
// use Serial2 for ESP32 on Micromod board in F1 slot

#include <Streaming.h>

void setup() {
  while (!Serial && millis() < 1000);
  Serial << "\n\n============= ESP32_test =============\n";
  Serial << " * Open Serial2 to Micromod ESP32 ...\n";
  Serial2.begin(115200);                      // ESP8285 + ESP32
  while (!Serial2 && millis() < 1000);
  Serial << " * Check ESP comms:\n\n";
  delay(500);
  Serial2.println("AT+GMR");                                    // NB: SerialX << "AT+GMR\n"; doesn't work
  if(recFind("OK", 5000)){                                      // scan for "OK" from Serial 2, up to 5 secs
    Serial << "\n\n * Success\n";
    }
  else {
    Serial << "\n\n *** FAILED ***\n";
    }
  Serial2.flush(); 
  delay(1000);
  Serial << "---------- done ----------\n";
  }

void loop() {}

// Search serial RX buffer for the text provided. Fails if not
// found before expiry of timeout period. Returns true if found.
bool recFind(String target, uint32_t timeout){
  String rdBuff = "";
  unsigned long startMillis = millis();
  while (millis() - startMillis < timeout){
    while (Serial2.available() > 0){
      char rdChar = Serial2.read();
      rdBuff += rdChar;
      Serial.write(rdChar);
      if (rdBuff.indexOf(target) != -1) {break;}
      }
    if (rdBuff.indexOf(target) != -1) {break; }
    }
  if (rdBuff.indexOf(target) != -1){return true; }
  else                             {return false;}
  }
 
You must log in or register to reply here.
Back
Top