Compass/Gyro Module

[Tmktahu]

A huge + to using a coordinate system is knowing what direction you are flying. But pulling this off is tricky.

We can represent a direction as a vector, and we can get this directional vector by subtracting our current coordinate from our previous coordinate. But this only gives us pitch and yaw information relative to the axes. Technically, this is enough to display a direction, but the rotation of the display depends on the ship's roll.

To calculate roll, I can think of 2 options:

1. Calculate coordinates for a left and right edge of the ship to define a left-right axis. Then compare the rotation of this axis to the coordinate grid to get the roll. This method requires at least 2 independent coordinates.
2. Assume the rotation based on change in direction combined with player input. If we store the previous directional vector and compare it with the current directional vector, we can get the change relative to the coordinate grid. From there we check the user's FCU input controls to see what they are pressing. With all that, we can assume the ship's rotation.

Option 1 is probably the cleanest, but requires at least 2 independently calculated coordinates. Since we would like the Module to be as accurate as possible, these would have to be quad coordinate systems, which is a lot of receivers. It would work, but the construction overhead is eh.

Option 2 would be the cleanest design-wise, but probably the most tricky and error prone. My instinct is the update speed may not be great either given the additional calculations and then tapping into the FCU values. But it could work.

TODO:

• Research options 1 vs 2 to see what the code and construction overhead of each would be.
• Brainstorm display options. How do you go about displaying direction with current control devices?
• Look at methods of comparing two directional vectors. Dot product with law of cosines?

[Thaccus]

One of the reasons the systems I have worked with use three coordinates on the ship is so that you can get both a forward and a perpendicular vector and use them to calculate a third. If you end up using the DeltaV as facing info then the system has to calculate and include ship drift. It also does not work when stationary(which I think is the more critical issue of the two.)

I do wonder if one receiver for forward and another for down would be enough. If one were to instead calculate a new coordinate off of three of the quad receivers and the one forward/down receiver, would the distance discrepancy of that single receiver(and possibly its counterpart) be enough to continue the 0.2s accuracy? I think if one had a known distance offset of the forward and down receivers it might be.

[Tmktahu]

Yea after messing with velocity calculations based on coordinates, I agree that using it is very brittle and prone to a ton of errors. Going with 3 separate points for establishing a plane on the ship is the way to go.

Unfortunately, it's impossible to calculate a third point off of 2 others regardless of the setup. If you only have 2 coordinates, then you only have a line between those 2 coordinates. Even if you know the distances to a third, that third coordinate could be anywhere in a circle around the other two. Almost like the line created by the 2 points is a hinge that the third rotates around.

But I do think it may be possible to construct the needed vectors even when the receivers are very close to each other. I would be working with very small numbers, but it may be enough. If it works, I should be able come up with a very small, single module rather than a 3-piece system.

[xyberviri]

You could have a 2nd system that is below the main system to give you roll orientation of the ship. you could then at least orient the ship upright before attempting to find the heading/pitch of the ship with movement.