Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
Old 22-02-2019, 09:56   #1
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 13,669
Hardware: GPS & DR

https://www.u-blox.com/en/product/neo-m8l-series


Continuous accurate navigation under all signal conditions
  • Integrated 3D sensors with speed information from vehicle
  • Continuous navigation during signal loss
  • Automatic configuration of wheel‑tick/speed input - < Car specific
  • Real‑time positioning up to 30 Hz rate
  • GPS/QZSS, GLONASS, BeiDou, Galileo
  • Zero‑PPM program for automotive grade NEO‑M8L‑03A
__________________

rgleason is offline   Reply With Quote
Old 22-02-2019, 11:32   #2
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 3,581
Re: Hardware: GPS & DR

Rick,

this is for cars in city canyons where you have GNSS signal loss or multipath reception very frequently.

The nice thing from a well designed IMU+GNSS is a stable and very precise heading and COG information. Here we shall see improvements in the next years.

Hubert
__________________

bcn is offline   Reply With Quote
Old 22-02-2019, 12:28   #3
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 13,669
Re: Hardware: GPS & DR

Yes, I was thinking about Dead Reconning and the Kalman Filter, in this thread Opencpn backup of multiple fixes using Kalman filter


It is possible that GPS devices could become more elaborate and independent position sensors at some point, utilizing GPS less frequently, or perhaps relying on other magnetic and acceleration sensors when GPS is not available. When in that mode the Opencpn GPS icon would need to change, I believe.


Navigation System Heading and Position Accuracy Improvement through GPS and INS Data Fusion

https://www.researchgate.net/publica...NS_Data_Fusion



Formulas for Kalman Filter

http://www.bzarg.com/p/how-a-kalman-...s-in-pictures/



Quote:
Originally Posted by bcn View Post
Rick,

this is for cars in city canyons where you have GNSS signal loss or multipath reception very frequently.

The nice thing from a well designed IMU+GNSS is a stable and very precise heading and COG information. Here we shall see improvements in the next years.

Hubert
rgleason is offline   Reply With Quote
Old 24-02-2019, 12:26   #4
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

Quote:
Originally Posted by rgleason View Post
Yes, I was thinking about Dead Reconning and the Kalman Filter, in this thread Opencpn backup of multiple fixes using Kalman filter


It is possible that GPS devices could become more elaborate and independent position sensors at some point, utilizing GPS less frequently, or perhaps relying on other magnetic and acceleration sensors when GPS is not available. When in that mode the Opencpn GPS icon would need to change, I believe.


Navigation System Heading and Position Accuracy Improvement through GPS and INS Data Fusion

https://www.researchgate.net/publica...NS_Data_Fusion



Formulas for Kalman Filter

How a Kalman filter works, in pictures | Bzarg

I use the BNO055, is very good device:
9 axis IMU, Integrated ARM Cortex M0+ with Kalman filter. 100 Hz output.

https://learn.adafruit.com/adafruit-...ensor/overview
Tehani is offline   Reply With Quote
Old 25-02-2019, 10:40   #5
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 13,669
Re: Hardware: GPS & DR

Thank you Tehani, Sean also probably very interested in this for Pypilot.
How are you using it's capabilities with GPS? Perhaps the idea is going to become more available.

rgleason is offline   Reply With Quote
Old 26-02-2019, 05:52   #6
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

Quote:
Originally Posted by rgleason View Post
How are you using it's capabilities with GPS? Perhaps the idea is going to become more available.
At the moment I use this device to generate the pitch and roll Euler angles. Yaw output agrees with Heading. It is very precise, fast, and can be mounted in any position in 90 degree steps because its axes can be configured.
I send this data with the XDR sentence to O. (PTCH, ROLL). The dashboard represents them well. It delivers data of comparable quality to the Maretron SSC300UM, and also self-calibrates in a similar way.
With this chip, the problem basically comes down to I2c communication and little else.

To calculate the "Dead Reckoning" it is necessary a little math, and follow corrections with GPS readings when they are valid. The work consists basically of integrating the gyro and accelerometer readings in discrete time. With double integration in the case of the accelerometer.
The latter is a project that I am considering for orientation underwater.
The problem is that the accumulated error grows a lot with the passing time, mainly due to the "bias" of the gyroscope. It is a general problem, not only of this sensor. (BNO055).

Previously I tested the MPU-9255 and had SPI communication problems, because this chip has a recognized design problem when translating to I2c for the internal magnetometer. In any case, if you use this chip, you have to consider the CPU load because it does not integrate decent filtering algorithms. With it I adapted and tested the filters Madgwick, Mahony and Kalman, the latter from a Freescale library. It was necessary to incorporate a real-time operating system (FreeRTOS) to manage the tasks "Fusion" and "Calibration".
I also had to pass the SPI communication with DMA, which is great, to the I2c communication, which also requires more CPU load.

With the BNO055 my problems were finished. Even with I2c. I Use STM32, ARM Cortex M3 and M4 microcontrollers.
There are other better IMUs within the BNO family. But this is not expensive, it works well and is very popular.
Tehani is offline   Reply With Quote
Old 26-02-2019, 06:21   #7
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

Suggested reading for retirees. (It's much better than visit a building site):

https://diydrones.com/profiles/blogs...dead-reckoning
Tehani is offline   Reply With Quote
Old 26-02-2019, 11:12   #8
Marine Service Provider

Join Date: May 2013
Location: Norway
Posts: 688
Re: Hardware: GPS & DR

Emlid, who makes drone flight controllers to be used with raspberry PI have a realtime raspbian image optimized for MPU-9255 and had SPI communication, the image can be downloaded by clicking the link http://files.emlid.com/images/emlid-...0180525.img.xz


Also, see link HERE https://docs.emlid.com/navio/common/...u9250_lsm9ds1/


/Petter

Quote:
Originally Posted by Tehani View Post
At the moment I use this device to generate the pitch and roll Euler angles. Yaw output agrees with Heading. It is very precise, fast, and can be mounted in any position in 90 degree steps because its axes can be configured.
I send this data with the XDR sentence to O. (PTCH, ROLL). The dashboard represents them well. It delivers data of comparable quality to the Maretron SSC300UM, and also self-calibrates in a similar way.
With this chip, the problem basically comes down to I2c communication and little else.

To calculate the "Dead Reckoning" it is necessary a little math, and follow corrections with GPS readings when they are valid. The work consists basically of integrating the gyro and accelerometer readings in discrete time. With double integration in the case of the accelerometer.
The latter is a project that I am considering for orientation underwater.
The problem is that the accumulated error grows a lot with the passing time, mainly due to the "bias" of the gyroscope. It is a general problem, not only of this sensor. (BNO055).

Previously I tested the MPU-9255 and had SPI communication problems, because this chip has a recognized design problem when translating to I2c for the internal magnetometer. In any case, if you use this chip, you have to consider the CPU load because it does not integrate decent filtering algorithms. With it I adapted and tested the filters Madgwick, Mahony and Kalman, the latter from a Freescale library. It was necessary to incorporate a real-time operating system (FreeRTOS) to manage the tasks "Fusion" and "Calibration".
I also had to pass the SPI communication with DMA, which is great, to the I2c communication, which also requires more CPU load.

With the BNO055 my problems were finished. Even with I2c. I Use STM32, ARM Cortex M3 and M4 microcontrollers.
There are other better IMUs within the BNO family. But this is not expensive, it works well and is very popular.
petter5 is offline   Reply With Quote
Old 26-02-2019, 13:27   #9
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

Quote:
Originally Posted by petter5 View Post
Emlid, who makes drone flight controllers to be used with raspberry PI have a realtime raspbian image optimized for MPU-9255 and had SPI communication, the image can be downloaded by clicking the link http://files.emlid.com/images/emlid-...0180525.img.xz


Also, see link HERE https://docs.emlid.com/navio/common/...u9250_lsm9ds1/


/Petter
I find it hard to believe that someone could communicate through SPI with the damn AK8963 through MPU9255 acting as internal I2c master. To me, and to the few who had tried, the reading of the low byte of the magnetometer was always 0xFF using this method.

I do not question what you say to me, but I have not been able to check the Emlid code because the image that I downloaded is corrupted.
Rapsberry has I2c and SPI on its expansion bus, so communication with the MPU9255 in the Emlid environment remains a mystery to me.
I already lost a lot of time with this chip a little over a year ago. In spite of everything, I have been interested in seeing the current situation of the problem, out of curiosity. It seems that the problem I have mentioned still exists, and the solution is not clear. (delay, delay and more delays in the setup and communication).
When you have to design something robust, you can not rely on a circuit to run for a while by chance. I think.

But thank you very much for the information.
Tehani is offline   Reply With Quote
Old 27-02-2019, 20:10   #10
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 13,669
Re: Hardware: GPS & DR

Tehani,


Thank you. There are some good links and discussion here. I suppose reliance on multiple GPS satellites is ok, however with the loss of Loran, there is no backup system. For shorter time periods where GPS gets interrupted perhaps DR would be useful. or perhaps a sextant for long distances.


How likely do you think these DR features (and software) will become an off the shelf added feature? I believe Sean is using these kinds of sensors to improve the response and anticipation of his pypilot autopilot.
rgleason is offline   Reply With Quote
Old 28-02-2019, 07:28   #11
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

Quote:
Originally Posted by rgleason View Post
How likely do you think these DR features (and software) will become an off the shelf added feature? I believe Sean is using these kinds of sensors to improve the response and anticipation of his pypilot autopilot.

A modern pilot calculator receives a good amount of signals, which it must manage in different ways.
It is not easy to explain it in the context of this thread, but I will try to be concise.
The power drive to the motor or pump of the pilot is governed by the output of a position servo that receives the following data and adds its value in a PID system:
- Magnetic heading as the main reference source. Proportional and adjustable servo response according to user setup.
- Gyro. Automatic adjustment based on the immediate response of each type of boat. Derivative action with high coefficient.
- GPS COG reference, or TWA according to the operating mode of the pilot. Follow-up and integrative error correction with a low coefficient.
To this information, engine blocking sensors, rudder angle are added. The pitch and roll can also be processed. All of these can be used for the supervision and security system.

Now I will try to give my answer to your question.
I interpret that the objective of the IMU system that you mention to me should serve to compensate the drift variations in order to replace the COG data when the GPS fails. The DR calculation to obtain the position is much more imprecise.
The problem is that the signal produced by these slight variations in the sensors is very weak compared to the large accelerations produced by the waves. My opinion is that it is more practical to maintain the current heading with the help of the Gyro during the GPS signal losses, and then assume that the COG is maintained. In this way you can establish the distance with the slide previously calibrated with the last valid readings of SOG.
I believe that the DR can be calculated with reasonable precision from these empirical data.

This is my humble opinion. Please, do not hit me.

Jose Luis
Tehani is offline   Reply With Quote
Old 28-02-2019, 07:43   #12
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 13,669
Re: Hardware: GPS & DR

Quote:
Originally Posted by Tehani View Post
A modern pilot calculator receives a good amount of signals, which it must manage in different ways.
It is not easy to explain it in the context of this thread, but I will try to be concise.
The power drive to the motor or pump of the pilot is governed by the output of a position servo that receives the following data and adds its value in a PID system:
- Magnetic heading as the main reference source. Proportional and adjustable servo response according to user setup.
- Gyro. Automatic adjustment based on the immediate response of each type of boat. Derivative action with high coefficient.
- GPS COG reference, or TWA according to the operating mode of the pilot. Follow-up and integrative error correction with a low coefficient.
To this information, engine blocking sensors, rudder angle are added. The pitch and roll can also be processed. All of these can be used for the supervision and security system.

Now I will try to give my answer to your question.
I interpret that the objective of the IMU system that you mention to me should serve to compensate the drift variations in order to replace the COG data when the GPS fails. The DR calculation to obtain the position is much more imprecise.
The problem is that the signal produced by these slight variations in the sensors is very weak compared to the large accelerations produced by the waves. My opinion is that it is more practical to maintain the current heading with the help of the Gyro during the GPS signal losses, and then assume that the COG is maintained. In this way you can establish the distance with the slide previously calibrated with the last valid readings of SOG.
I believe that the DR can be calculated with reasonable precision from these empirical data.

This is my humble opinion. Please, do not hit me.

Jose Luis

Ah ha, That is why a friend who was a Navy Submarine Captain asked about using Kalman filters to obtain DR! They have no waves under water and they surely need to know where they are. In that case these sensors would make a big difference.


But isn't the wave problem the same for Airplanes with wind being like a wave?


Thank you.
rgleason is offline   Reply With Quote
Old 28-02-2019, 08:01   #13
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 85
Re: Hardware: GPS & DR

I do not know for sure, but I believe that the variations of the wind speed in height are not as fast as the accelerations produced by the waves. The quotient of ship speeds with respect to the environment is also very different.
Tehani is offline   Reply With Quote
Old 28-02-2019, 09:04   #14
Moderator
 
a64pilot's Avatar

Cruisers Forum Supporter

Join Date: Oct 2013
Location: Albany Ga.
Boat: Island Packet 38
Posts: 28,062
Hardware: GPS &amp; DR

Quote:
Originally Posted by rgleason View Post
Ah ha, That is why a friend who was a Navy Submarine Captain asked about using Kalman filters to obtain DR! They have no waves under water and they surely need to know where they are. In that case these sensors would make a big difference.


But isn't the wave problem the same for Airplanes with wind being like a wave?


Thank you.


The inertial nav system in the original Apache helicopter used Kalman filters.
It wasnít a pure interval Nav system, it was coupled to a Doppler Radar Nav system that used four beams to determine speed and direction also, and I believe the Kalman filters went between the HARS and the Doppler.
Primary use for Kalman filters is aircraft and spacecraft.
However if I understand it correctly, I would assume a Subís inertial Nav system would be heavily dependent on Kalman filtering, and would I would also assume led the way in its and INUís development.
https://en.m.wikipedia.org/wiki/Kalman_filter
a64pilot is online now   Reply With Quote
Old 28-02-2019, 21:01   #15
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: charleston
Boat: bristol 27
Posts: 3,516
Re: Hardware: GPS & DR

Quote:
Originally Posted by Tehani View Post
To calculate the "Dead Reckoning" it is necessary a little math, and follow corrections with GPS readings when they are valid. The work consists basically of integrating the gyro and accelerometer readings in discrete time. With double integration in the case of the accelerometer.
The latter is a project that I am considering for orientation underwater.
The problem is that the accumulated error grows a lot with the passing time, mainly due to the "bias" of the gyroscope. It is a general problem, not only of this sensor.
Generally the kalman filter can estimate the gyro bias, but many simple kalman filters do not implement this.



I don't think you will have much success double integrating accelerometers in waves because the noise is considerable. It is even a problem for submarines. If you had water speed then only a single integration, and much more accurate results.

Quote:

(BNO055).

Previously I tested the MPU-9255 and had SPI communication problems, because this chip has a recognized design problem when translating to I2c for the internal
I use this chip with i2c communication not spi. It works perfectly well using i2c so why use spi?

Quote:

magnetometer. In any case, if you use this chip, you have to consider the CPU load because it does not integrate decent filtering algorithms. With it I adapted and tested the
Running kalman filter uses 0.7 % cpu of a single core of a raspberry pi and it is not at all optimized. I don't think the cpu load is a consideration, even on much slower stm32 it should be a small percentage.



Quote:

filters Madgwick, Mahony and Kalman, the latter from a Freescale library. It was necessary to incorporate a real-time operating system (FreeRTOS) to manage the tasks "Fusion" and "Calibration".
I also had to pass the SPI communication with DMA, which is great, to the I2c communication, which also requires more CPU load.
Where is your source code?
Quote:

With the BNO055 my problems were finished. Even with I2c. I Use STM32, ARM Cortex M3 and M4 microcontrollers.
There are other better IMUs within the BNO family. But this is not expensive, it works well and is very popular.

I think it cost a lot to save less than 1% cpu. But the main problem is, what algorithms are they running internally? We don't have the sources, can we even trust it, is it any good? If BNO055 goes away, what will you do? It is unlikely to be optimized or tuned specifically for boat motions.





For example, the case of traveling under a steel bridge in a boat. It is unlikely the bno055 authors considered this.



What about using redundant sensors, like 6 or 9 of each instead of only 3. This can give lower noise and autocalibrate very fast. For these algorithms the BNO055 must just read raw sensor values: you might as well use mpu9255.
__________________

boat_alexandra is offline   Reply With Quote
Reply

Tags
gps, hardware

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
For Sale: BRONZE: Chainplates, Anchor Roller, Bowsprit & bulwark hardware ~36+' boat pressuredrop Classifieds Archive 26 21-07-2013 15:57
For Sale: Sailboat Hardware and 30 amp Battery Charger silverp40 Classifieds Archive 1 20-12-2010 17:05

Advertise Here


Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 20:07.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
×

ShowCase vBulletin Plugins by Drive Thru Online, Inc.