bjarnebitscrambler / orientationsensorfusion-esp Goto Github PK

Magnetic calibration is loaded on boot-up from NVM (EEPROM) if available. Though calibration is checked and generated during regular operation, it is not automatically saved to NVM unless commanded. Currently the only way that command is received is from the NXP Sensor Toolkit. Therefore the sensor has to generate a new magnetic calibration each time it is powered on, which takes a bit of physical manipulation and time.

It is desirable to implement a method in the interface class to cause an existing magnetic calibration to be saved to NVM.

It's desirable to have the orientation code function as a library compatible with the SensESP project.

Work is in-progress. ETA about end-December.

Hi @BjarneBitscrambler ,
First of all thanks for sharing such an awesome library and complete description in examples and header files, it's really helpful.
But with all these, implementing the library for another sensor is still confusing. I checked the whole library more than once and It looks like using this library for another sensors is a little bit impossible.
It's gonna be great if you help making a better and more understandable simple code :
Lets consider that I have my raw sensor data as ax,ay,az,gx,gy,gz,mx,my,mz variables which is in standard units and frequency for library.
1.Which header files have to be included in main script?
2.How should I feed these variables to sensor fusion?
3.How should I calibrate the whole IMU ACC,GYRO,MAG?(cause I couldn't find any calibration function for GYRO)
4.How should I get the Quaternion data as output?

also making a simple script like above looks like to be so challenging cause the main fusion header file is using build and board files and I couldn't find any possible way to pass the raw sensor data to filter.
anyways I hope there is an easier way.
Kind Regards,
Mason.

The fusion library has the ability to pass a SysTick parameter to the Toolbox for display, as a measure of how long an iteration of the filter algorithm took to execute. It would be nice to know how much CPU time is used in running the fusion algorithm.

The SysTick is available on ARM processors, and so is currently disabled in the code, but can probably be emulated on the ESP processors.

The fusion code has 7 different algorithms (with various combinations of accel, gyro, and magnetometer sensors, plus complexity). Each algorithm deposits its results in its own struct, named on the pattern SV_xxxx (e.g. SV_6DOF_GB_BASIC).

All these structs are part of the sensor fusion global sfg object. We could decrease memory used by creating a union of these structs and access them through a SV_COMMON struct. This might also reduce the number of conditional compilation #ifdef - #endif code blocks.

ESP-8266 compatibility isn't confirmed by actual testing on hardware.

I've ordered a d1_mini for this purpose.

Looking at the I2C transactions with a scope, it is apparent that there is sufficient time to perform additional reads of the magnetometer during each fusion cycle. Currently one one read is performed, and because the magnetometer portion of the FXOS8700 does not have a FIFO, that read only obtains a single data point. It should be feasible to perform a magnetometer read before and after the block read of the accelerometer, and possibly also after the gyro read. Thus there might be 2 or 3 data points per fusion cycle, which would improve the signal to noise ratio if they are averaged.

The sensor fusion code consists of a large number of source files. It isn't obvious which ones to modify for a given purpose, so documenting the structure of the fusion code and how it relates to particular files would be useful.

The comments in each source file are reasonably clear, but it's tedious to open up each file to have a look. Document the overall structure perhaps in the WiKi, or a Readme.txt file

@DanielG86 suggested adding a means for correcting the compass readings for Deviation. After the built-in magnetic calibration routine runs, there will likely be some residual error. If this error is repeatable then we should be able to correct for it, similarly to using a deviation table with a physical compass.

Depending on the type of error, the correction might be one or more of:

• a constant offset
• an offset that varies sinusoidally around the complete arc

When compiling the library using example main.cc with the source under /src folder the flash size is 701650 bytes, but when compiling as a library in the .pio folder the code size is 701898 bytes.

I'm about to post the sensor-fusion code that I've ported to the ESP32 platform. Before I do, I'm renaming this repository.
@tedenda and @DanielG86 - if you have bookmarks to this repository you may have to update them...

Hello Bjarne,
Great project and just wanted to let you know that I’m willing to support where possible.
Currently just prepared a test version on a breadboard, with some issues, as reported in the PR (I think #166)

The Doxygen-generated documentation is placed in the project's /html folder (access it via the index.html file in that folder). However, this has 2 bad side-effects:

• the size of the project itself has grown substantially, if one downloads a tarball or clones it
• Github assesses the content of the project incorrectly: it now says > 80% of the project is HTML.

Ideally, we want a link to the documentation pointing outside of the project code itself. A solution might involve GitHub Pages...

NXP's Sensor Fusion Toolbox displays a bargraph showing the reliability of the current magnetic calibration. It is desirable to add a method that reports the same/similar information to the library interface.

Some preliminary research shows that a combination of comparing the current magnetic field magnitude to the expected value, and the current magnetic field dip to the expected value, may be of use.

Depending on which sensor reports are enabled in main.cpp, additional header files might be needed. One example is the temperature report, which relies on a Linear transform to scale/correct the values.

Review the sample code, and add appropriate comments for needed header files.

For compatibility with Signal-K/SensESP project, it's best to allow program execution to continue, despite lack of comms with a sensor. SensESP may have multiple sensors attached, and failure of one should not bring down the whole system.

Will need a method for passing back the status of the sensors, and for retrying comms. Something like GetSensorStatus()...

Initial testing with the Sensor Toolbox indicates that the scaling of the accelerometer outputs (all axes) is incorrect. For example, there is not a 2 g difference in readings between an axis that is pointing down and when it points up.

Have to check whether this is related to the initialization of the accelerometer, or in the scaling and corrections that happen during calibration, or during translation into the packet that is sent to the Toolbox.

Currently the fusion code can output results and accept commands via the Serial object and via TCP socket. These are selected using some inelegant #ifdef - #endif brackets around multiple code sections in multiple places.

It's preferred to implement something that at the lower level would accept a stream pointer of arbitrary type and use it for input/output. The main.cc code could then instantiate whatever type of stream was needed.

Currently the code streams data via serial UART to the outside world. This is inconvenient for testing: the USB cable objects to being twisted into a pretzel while manipulating the sensor. Adding wireless streaming, e.g. via TCP socket over WiFi, would be handy.

The orientation code needs a wrapper to make it usable as a general Arduino library (note that compatibility with non-Espressif processors is a separate issue).

It will also need additional examples, a manifest, some supporting files, a release, etc.

Filenames should be standardized.
Consider removing SPI files and just leaving stubs that could be used later if desired.
Consider consolidating the user-edited files into one.
Read up on what's required to make an Arduino library.
Decide whether to convert to C++ or leave as (mostly) C.
Define an interface to outside world - one that will be compatible with SensESP.

Testing with the Sensor Toolbox indicates that the axes of the sensors might not be oriented correctly. It appears that the X and Y axes of both the magnetometer and the accelerometer are swapped. The file hal_axis_remap.c needs to be edited to correct this. The expected orientation for nautical use (and apparently aeronautical) is called NED, where X,Y,Z are in a right-hand coordinate system pointing North, East, and Down respectively.

@DanielG86 also suggested having a physical switch to trigger the saving of a magnetic calibration would be useful, in addition to the command-based software method.