I think you have the concept down. I'm not sure what the "some strange frame" would be, or how you would have a transform to that frame.
You know, by physics, that gravity points down in the world frame. You know, by your sensor's orientation quaternion, how the sensor is oriented relative to the world.
So, as you mention:
- Rotate acceleration data by the quaternion from the sensor frame to the world frame.
- Subtract gravity from the down axis (typically z or y - be sure to read the sensor's data sheet!)
- Rotate the acceleration data from the world frame to the sensor frame.
I'm not positive why you would want that last step though, unless you were doing something strictly in the local frame. Generally you would care about how an object is oriented or how it moves with regards to an arbitrary start location in the world frame.
That is, once you rotate the acceleration data to the world frame, you can remove gravity, and then perform your single and double integrations to get speed and position with respect to the world frame. I'm not sure what you get by going back to the sensor frame after removing gravity.
Maybe this is your fourth point?
Second inverse rotation? (goes to NED frame??)
Right, because again you care about how the object moves with respect to the world. If you don't care about that relationship then you're in a pretty small minority of IMU applications, and I personally can't really imagine the scenario you're working with.
But, if you look, your points three and four cancel and you're left with one and two - rotate to world frames, remove gravity.