Vector Thrusters and Vector Direction with a Pod

[zentiger]

I have been trying to write an expression for controlling a craft via advanced pod controller, and I wanted to use vector thrusters for lateral movement control.

For me to accomplish this, I know I need to get the forward vector, the right vector, and the up vector, all in relation to the craft itself.

I tried to accomplish this using the following method:
Create 4 GPSs (Front, Right, Back and Left)
Use each of the vector outputs from them as inputs
Determining the forward vector by subtracting Front from Back
Determining the right vector by subtracting Right from Left
Determining the up vector by cross-multiplying the forward and right vectors
So:

I@ F R B L W A S D
O@ Direction Mult
interval(40)
FB = vecnormalize(vecsub(F, B))
RL = vecnormalize(vecsub(R, L))
UP = vecnormalize(veccross(FB, RL))
W->Direction = -FB;
S->Direction = FB;
A->Direction = RL;
D->Direction = -RL;
Mult = 10

So if I press any of the directional keys I move in those directions, but regardless of the direction I am facing, the thrust still goes in the same directions, rather than the directions relative to the craft. I have local xyz on but these always seem to fire in world directions...
Eventually I want to have it stop movement when no keys are pressed.
How can I resolve the issue of the world directions vs local?
Am I doing something incorrect to cause this?
How would I implement the stop functionality, preferably using delta?

Thanks very much for your suggestions.

[zentiger]

Well I found an alternative approach that seems to work relatively well and I wanted to share it with everyone.

I@Forward Backward Left Right Up Down
O@Mul Fx Fy Fz
interval(T*1000)
T=0.03 ThrK=50 M=1000
XvelB=1000 YvelB=1000 ZvelB=1000
Xvel=XvelB*(Forward-Backward)
Yvel=-YvelB*(Left-Right)
Zvel=-ZvelB*(Up-Down)
Fx=-M/T/ThrK*(Xvel-extvelabsx())
Fy=-M/T/ThrK*(Yvel-extvelabsy())
Fz=-M/T/ThrK*(Zvel-extvelabsz())
Mul=sqrt(Fx^2+Fy^2+Fz^2)

A few notes about some constants:
T is Time
ThrK is the Thruster Constant (for vector thrusters its 50, for the pop-can its about 183)
M is Mass (or weight - this needs to be set to your total contraption weight, here its 1000)

Keep in mind too that if you use more than 1 vector thruster you would need to divide the total mass of the contraption by the number of thrusters.
I got this to work relatively well with the thrusters set to xy local z world.

My next objective is to make this work in E2, I trust the computations would be faster and more efficient.

If anyone finds any place where I could improve this please don't hesitate to suggest.
Thanks!

[zentiger]

Well I got this to work with e2:

@name Vector Directional Control
@inputs Forward Backward Left Right Up Down
@outputs Mul Fx Fy Fz Fvec:vector
@persist
interval(30)
T=0.03 ThrK=50 M=2400
XvelB=2400 YvelB=2400 ZvelB=2400
Xvel=XvelB*(Forward-Backward)
Yvel=-YvelB*(Left-Right)
Zvel=ZvelB*(Up-Down)

Vel = entity():vel()
Fx=-M/T/ThrK*(Xvel-Vel:x())
Fy=-M/T/ThrK*(Yvel-Vel:y())
Fz=-M/T/ThrK*(Zvel-Vel:z())
Mul=sqrt(Fx^2+Fy^2+Fz^2)
Fvec = vec(Fx,Fy,Fz)

In this example the craft I was making weighs in at a total of 2400. I also added a vector output so that its compatible with the Advanced Wiring Tool.
Note that this only helps with stability of motion, not angular stability.

[Captain Maim]

I wanted to do something similar, only rig it so that it's directional input was coming from the mouse. I look where I wanted to go. I just had one slight problem with calibration. I had it facing the right way at one point but when I welded the thruster back onto my little contraption it was offset at some perverse angle again.

I'm not sure how to calibrate the vector thruster, it's got a little arrow on the model, but I don't think that points to any particular axis.

Maybe your work could be of use to me. If nothing else it looks like I could use what you have to create a 3 axis movement system...

What's e2? And where do I put your last expression, it looks a little different than what I understand the format of an expression chip to be.

What should I set the thruster power to when I use this?

[zentiger]

e2 = Expression Gate 2
It looks different because it is different. I recommend it but remember it still is in beta.

I have similar issues with the vector thruster. The arrow does not indicate a specific axis, but a vector. If you have the vector thruster set to xy local z world or xyz local it indicates which way is "front" I believe.

The Mul output is the one I assign to the Mul input on the thruster, and I have found my best results by setting the multiplier in the vector thruster settings to a value of 1. Afterward I tweak the weight.

My next objective is to make a reliable Pitch / Yaw / Roll control, as all this does is stabilize position. I want to essentially do what keep upright does, really. I like the idea of turning where you look, though.
Hmm...

[Captain Maim]

Yeah I got the idea when I looked up how to work vector thrusters (first I tried laser pointer and that worked great except you can't DRIVE by laser pointer. No weapons in a pod.) So after making something that chases my laser pointer I decided I'd make it so I could drive it with a cam controller and a GPS and just use mouse look to aim.

Attempts so far have proven that when it flies 1) the axis of rotation is totally berzerk, but apparently irrelevant if the roll of the craft isn't wired into the camera. 2) I'm not sure what the difference is between where I was looking and where it was going but it wasn't remotely similar. 3) I'm having troubles calibrating it to Pitch and Yaw. It looks like they're 90 degrees off so I wire pitch to yaw and yaw to pitch, still not sure if that's a solution yet though. But then I had inversion troubles, with it going 180 from where I was looking. I'm going to use a beacon sensor rather than direct input into an adv pod controller, see if that helps.


Also, which axis is considered "front?" X or Y? Cause I know Z is up and down.


Where can I find an e2? And, what advantages does it have over e1?

[Nick2345]

I have been trying to write an expression for controlling a craft via advanced pod controller, and I wanted to use vector thrusters for lateral movement control.

For me to accomplish this, I know I need to get the forward vector, the right vector, and the up vector, all in relation to the craft itself.

I tried to accomplish this using the following method:
Create 4 GPSs (Front, Right, Back and Left)
Use each of the vector outputs from them as inputs
Determining the forward vector by subtracting Front from Back
Determining the right vector by subtracting Right from Left
Determining the up vector by cross-multiplying the forward and right vectors
So:

I@ F R B L W A S D
O@ Direction Mult
interval(40)
FB = vecnormalize(vecsub(F, B))
RL = vecnormalize(vecsub(R, L))
UP = vecnormalize(veccross(FB, RL))
W->Direction = -FB;
S->Direction = FB;
A->Direction = RL;
D->Direction = -RL;
Mult = 10

So if I press any of the directional keys I move in those directions, but regardless of the direction I am facing, the thrust still goes in the same directions, rather than the directions relative to the craft. I have local xyz on but these always seem to fire in world directions...
Eventually I want to have it stop movement when no keys are pressed.
How can I resolve the issue of the world directions vs local?
Am I doing something incorrect to cause this?
How would I implement the stop functionality, preferably using delta?

Thanks very much for your suggestions.

Could you elaborate on what exactly it is you're trying to accomplish? My experience with the vector thruster wasn't a very good one, but it involved mouse control and dual-axis (Pitch and Yaw) maneuvering, so I never needed GPS devices.

What happens when you change the thruster to use normal world coordinates?

[Captain Maim]

You were able to fly it around by using the mouse to look where you wanted to go?
My GPS was for the cam controller only.

[Nick2345]

You were able to fly it around by using the mouse to look where you wanted to go?
My GPS was for the cam controller only.

If you mean me, yes. It's not perfect but the slight jitters in the controls (mostly due to the stabilization system, NOT the controls themselves) is worth accepting given the personal satisfaction of making it myself.