Closed AlexisTM closed 4 years ago
Actually, some convenience functions are used, for example here:
In my opinion, the stateless orientation is only useful for one thing: It's used to estimate the initial orientation of the IMU and initializing the filter with it. Before it was added, the filter was initialized with a neutral orientation (0, 0, 0) and took around 5-10 seconds to converge to the actual orientation. So having the stateless orientation for that purpose is useful. For any other purposes I'm not so sure, because setting the parameter "stateless" to true basically disables the whole rest of the filter.
Do you have a use case for using the stateless orientation outside of ROS? If not, I wouldn't spend any effort on making it ROS independent.
Indeed, I missed the part of using TF2 matrixes & conversions. It is much less trivial to convert it than expected.
We are planning on using the imu_tools in a non-ROS environment where we use it as a shared library right in our position filtering to reduce delays and unpredictability of ROS(1) communications.
For such use-case, when not initializing the filter with the stateless orientation, the gravity removal fails (is unreliable) until convergence. In the meantime, we will still have the ROS API available and I will convert it & share it if time allows.
I am closing it for now, until someone has added value for it and is willing to pick this up.
Sure, if you submit a PR, I'm open to accepting it. I just wanted to make sure you really have a use case for this and don't spend your time just on "making it nice" for aesthetic purposes. :)
But aesthetic is key! :innocent: (And obviously I have no time for it :eyes:)
The StatelessOrientation is dependent on ROS while the rest of the filter is not.
The dependence is only for the types (Vector3 and Quaternion) but no "convenience" function is used.
Should we make the StatelessOrientation ROS independent?