Hardware: GPS & DR

[Tehani]

Originally Posted by boat_alexandra

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.

The problem is that we do not have that speed. (Absolute, not only relative to water...)

Originally Posted by boat_alexandra

I use this chip with i2c communication not spi. It works perfectly well using i2c so why use spi?

I use the DMA whenever I can, both for A / D converters and for communications (USART and SPI). Frees the CPU from work, and allows you to link transfers to hardware events (interrupts).
In the case of the MPU9255, I made a version of my PCB to adapt it using the sensor INT to launch the DMA transfer. I wrote a callback function for the "End of transfer" interruption service of the DMA in which I compensated bias (X, Y, Z) of the accelerometer, verified the validity of the magnetometer readings, and updated the arrays of all the axes for the 3 sensors. So, everything was prepared for the Kalman filter, and it was clean and very fast to execute.
Of course, the IMU had been programmed to operate the INT with a frequency of 100Hz. The magnetometer is much slower, and that's why I put the verification of data validity.
The Kalman filter task (fusion) was activated by request at the end of this process. Also, the task of calibration, at a rate 10 times lower (that I remember).

Originally Posted by boat_alexandra

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.

Its not that easy...
I have not accurately measured the CPU consumption of the Kalman filter. In any case, the computation (% of CPU) of that data I have to do it under a work environment in real time. That is, it is not enough to think of that 0.7% with windows of time of a few milliseconds, but I have to face situations where concurrent demands can be very varied (N2k, 6 USARTS / UART, SPI for radio, other I2c sensors) , and its associated processes with immediate response to the demands of communication protocols.
An example: In Seatalk, it is necessary to monitor the idle state of the data line before transmitting, and when it is transmitted, it is necessary to listen simultaneously to detect collisions, and in that case stop transmission, wait 4-10 mS and retransmit. The process of managing N2k at a low level is much more complex than that.

All hardware is handled directly by the processor.
I'm using FreeRTOS for the second version of this project.
The main task of general communication control is activated every 4mS. The concrete management is done at a low level, in the interrupts.
I have assigned a very studied priority scheme, but even so, I do not want to have a stack or watchdog problem. (The least priority task refreshes the watchdog.) The STM32 have 2 types of watchdog - window and independent - the window type I think is not compatible with tasks like fusion, because I started having stability problems in time.

Originally Posted by boat_alexandra

Where is your source code?

At the moment, it is in my house.

Originally Posted by boat_alexandra

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 a long time, we all know that things evolve. If the Bosch BNO055 or its family disappears, there will surely be alternatives.

Well, the PCB will have to be modified a little, and the software a bit. It is the law of life. In any case, I have the alternative of dusting the filtering software that I already have.
Surely a new mass extinction of life on earth will be more serious. We do not pay much attention to this ...

The BNO has an internal self-calibration process.
https://cdn-shop.adafruit.com/datash...5_DS000_12.pdf
In the manual says that the applications of the chip are:
- Navigation.
- Robotics
...
In that order.

Originally Posted by boat_alexandra

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

This point is very interesting.
(Hard and soft iron distorsions)
I have read that the problem is not so much the ship's material. This is compensated by the long-term calibration process.
Apparently, the most relevant magnetic disturbances occur with the nature of the cargo in the merchants, and in our case, with the metal objects that we can eventually leave near the sensor.
Maretron has the ability to stop the autocalibration process in these cases, but always at the request of the user.
Well, with the BNO055 (and with the MPU9255) we can stop the calibration task when we want, restore original values, etc.

Originally Posted by boat_alexandra

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.

Yes, sure. Everything influences the costs and the price of the finished product.
For our practical application (heading, attitude), the precision, speed and reliability of only one sensor is more than enough. That's what I've seen, and that's what I think too.
On the other hand, 2 sensors subjected to the same disturbances do not solve the problem "soft iron distorsions".


It's a pleasure talking to you.

[Tehani]

Now imagine ...
Activate your own sensors and:
See a offshore sunrise and hear something like this:

https://www.youtube.com/watch?v=rSGK1ntnzdw

[rgleason]

Jose and Sean, I enjoyed reading your discussion and learning about the struggle and the opportunity, sharing different techniques to reach a goal, etc. Very enlightening with a fine ending.