Advanced Question AP Developement and Decomposing Matrices

[Hlynkacg]

I'm not sure whether I should be putting this in the Math forum or here but I need help with rotation matrices.

My vessel Is a tail-sitter, it's axis of thrust is aligned with the y axis rather than the z. This has lead to various issues when it comes to autopilots and other functions having to do with vessel orientation.

A little ways back I developed a simple function that used the cross product of a target vector and my thrust vector to align my engine for a burn. This works fine for simple orbital manuevers (turning prograde Retro etc...) but is proving impractical for things like landing and ascent APs.

Therefore i'm back at the drawing board.

There are two problems with my initial approach.

* The first is that it does not acount for rotation that is around the axis of thrust. This would be roll in a standard orbiter vessel and yaw in mine. In orbit this is no big deal, (after all who cares if you are up-side-down as long as you're thrusting in the correct direction?) but it becomes problematic closer to the ground.

* The second is the one that's giving me headaches. You see, there are points in both the Ascent and Landing autopilot programs where the vessel's commanded pitch and roll approach or excede +/- 90 degrees and as a result Roll inputs become Yaw, trig functions start coming back undefined and the whole thing falls apart. My solution so far has been to strictly limit AP inputs whenever a problem angle approaches 90 but this is hardly an ideal solution, and introduces it's own problems. (For instance my Ascent autopilot is incapable of maintaining a VACC <= 0)

What I need is a way to define my orientation around arbitrary vectors indipendantly of the the standard Pitch, Roll, Yaw axise.

In other word I need a matrix.

Unfortunatly i'ts been a while since I messed with matrices and I am unclear about how how to go about finding what I want.

In general terms, what combination of pitch roll and yaw inputs do I need to make to produce an arbitrary rotation around an arbitrary axis?

Likewise how do I go about decomposing my global orientation into something I can actually use for navigation? (i.e pitch up and hold 100 degrees)

 

[Urwumpe]

Did you already bother making a proper flow chart of the control loop that shall control your vessel? Maybe things get easier then to understand.

Calculating with matrix is rather easy compared to using angles. And also the simplest way to get from one reference frame to another frame.

I often use "fake" matrixes in autopilots: Instead of calculating a proper matrix, I simply convert the vessel base axes (X, Y, Z) into global rotation coordinates (no position change) and then use these direction vectors for converting data between global and vessel coordinates or getting the attitude angles.

This is less nice as a matrix, but permits doing some simplified calculations, where using the full matrix (9 multiplications, 6 additions) is ineffective when I really only need a single dot product (3 multiplications, 2 additions).

 

[Mythos]

Here's one MFD developer and I already thoght about problems like this.

My vessel Is a tail-sitter, it's axis of thrust is aligned with the y axis rather than the z. This has lead to various issues when it comes to autopilots and other functions having to do with vessel orientation.

First I'm not really shure what exactly is a standard tail sitter.

1. A standard z-aligned main engine, but no hover engine, so main engine has to be used for landing / hovering purposes
2. A main engine that is not aligned in z-axis

The first one I think is indeed a topic for AP developers that expect a hover engine. Other APs designed to use main engine for interplanetary flight or whatever will like this design without any thoughts about tail-sitters.

The second one could be transformed by vessel developers so first version comes out. Otherwise both interplanetary AP developers (main engine is not standard axis) and hover AP developers (use main engine as hover engine but in hover-standard-axis) will have headache.

That's my opinion for now. I'm looking forward to learn from further posts here.

 

[Hlynkacg]

Did you already bother making a proper flow chart of the control loop that shall control your vessel? Maybe things get easier then to understand.

I did...

Calculating with matrix is rather easy compared to using angles. And also the simplest way to get from one reference frame to another frame.

I often use "fake" matrixes in autopilots: Instead of calculating a proper matrix, I simply convert the vessel base axes (X, Y, Z) into global rotation coordinates (no position change) and then use these direction vectors for converting data between global and vessel coordinates or getting the attitude angles.

This is less nice as a matrix, but permits doing some simplified calculations, where using the full matrix (9 multiplications, 6 additions) is ineffective when I really only need a single dot product (3 multiplications, 2 additions).

I'm not quite sure I follow.

My problem is that in writing the out my flow chart I realised that the base pit/roll/yaw were largely useless to me.

What I need is to beable to define my orientation in terms of direction of travel, direction of gravity, and the horizon.

I don't want my pitch to be 50 degrees, I want to set my pitch so that my axis of thrust is 50 degrees away from the gravity vector.

I then want to rotate the entire vessel around that gravity vector so that my thruster is pointing in the direction I actually want to go.