Hello Mason!
I would like to know what are you trying to achieve in general. Perhaps it would allow me to give you better advice. As I said I fells to me that the Arduino IDE is getting in your way, and it may be simpler to use a different IDE, or perhaps a different controller.
The kalman filter in the notochord is an adaptation of this one which is specifically architectured for microcontrollers such as the ones in Arduino boards. What we did is to wrap the class Kalman_filter around the mathematical proceduces of the filter in order to adapt it to be executed in an embedded linux environment such as the one in the RPi. Using the original algorithm might be a good idea in your case, but it would require a significant amount of work to adapt it to the Arduino IDE, for example it relies in something called Real time operating system to obtain threaded execution. On our adaptation we relay in the OS threads. In arduino you can use FREERTOS but it would significantly increase the complexity of your code.
I'm saying all this in order to give you some context of the architectural part of what you are trying to achieve and suggest to rethink about the platforms you choose for your project. Perhaps a slight change might seem complex now, but it would prevent you from putting a good a amount of work in refactoring the code in further steps. For example, would you be able to achieve the same thing with a Raspberry pi? that way our library would work out of the box. Or would you be willing to dig a little into how microcontrollers work? that would allow you to adapt the original algorithm easily, perhaps implement use FREERTOS in Arduino, or get rid of the threaded execution (perhaps loosing some performance)
So, in order to directly answer your question:
mason_safavy is only a way, copying all of the script in a ino Arduino file.
The code you pasted will surely not work. For example it's using the kalman object which is an instance of the Chordata::Kalman_filter class defined in Chordata_fusion.h, you would need to put that too in you ino project and at some point create the instance and assing it to the kalman var.
If you take a look at the Chordata_fusion.h file you will notice that the original library headers are included like this:
namespace FSsf{
extern "C" {
#include "FS_sensor_fusion/build.h"
#include "FS_sensor_fusion/types.h"
#include "FS_sensor_fusion/fusion.h"
#include "FS_sensor_fusion/magnetic.h"
#include "FS_sensor_fusion/orientation.h"
}
}
Those are C files and we are working in C++, so they are wrapped around an extern "C" statement. You will need to make sure your IDE has access to them too. The Chordata_fusion.h file also requires #include "Chordata_communicator.h", you should be able to get rid of it and put your own output logic instead (perhaps based on Serial.print or similar).
But after this effort you might end up with similar include problems than the ones you are facing now.
mason_safavy all 3 components of ACC appears to be Zero in the same time. Is it okay?
It seems like the Accel sensor is not initiated. A working accel sensor will always give you some noise, and i laying flat on a table you should get 1g in the vertical axis because of gravity. Another thing to consider is calibration, but I guess for now it's better to focus in making the code work, just keep in mind that it's mandatory for good IMU processing.
I hope this long answer gives you some insights on how to continue with your project. And if you have some more questions you know were to find us
