Advanced Question More Autopilot Questions (controlling linear velocity using hover engines)

[Hlynkacg]

Ok, I'm back with more autopilot questions.

Now I'm trying to set up a routine that will allow me to control my linear velocity using the hover engines in conjunction with pitch and roll.

The theory is pretty simple in itself. With the vessel established in a steady hover pitching down will cause the vessel to move forward, pitching up will move the vessel backwards ect...

The problem is figuring out the appropriate amount of acceleration to apply and the corresponding vessel attitude while also maintaining altitude.

I considered posting this in the math forum but what I really need is help developing code (or psuedo-code).

The story so far...
I have my thrust vector "vThrust" who's magnitude = Throttle-level*Maxthrust.

The vertical (y component) of vThrust must be equal to the force exerted by gravity "vGravity"

As a constraint this means that acos( dotp(vThrust, vGravity) ) can not be allowed to excede acos(Magnitude of vGravity / Maxthrust)

I also have my current airspeed "aSpeed", my desired airspeed "dSpeed", and the difference between them "delta".

Given these vectors and constraints I need to calculate desired pitch roll and yaw.

As it stands all vectors are being calculated in orbiter's horizon frame.

any ideas or assistance would be greatly appreciated.

 

[C3PO]

You can calculate the Max pitch angle when vGravty = vMaxThrust x cos Pitch. Then you can calculate Max horizontal acceleration.

 

[Hlynkacg]

Something like this?

maxAngle = acos( length(vGravity)/MaxThrust )

maxAccel = ( MaxThrust*sin(maxAngle) ) / VesselMass

 

[C3PO]

Yes. That should be the Max horizontal acceleration with zero vertical acceleration.

 

[Hlynkacg]

I had already been thinking in that direction but the problem is relating that to "Delta" and by extension Pitch & Roll.

So far I haven't figured out anything that doesn't result in wild oscillations.

 

[C3PO]

The oscillations shouldn't have anything to do with the DeltaV. The pitch only affects the time it takes to get to the desired airspeed.

That in turn depends on the situation you want this AP to work.

Have you tried to make the AP hold a set pitch? This way you can eliminate the pitch routine as the culprit.

BTW what exactly do you want this autopilot to do? Is it for hovering around at a set altitude?

 

[Hlynkacg]

At the moment this AP is intended to simply take the place of the default "Hold Alt" autopilot but with the added feature of zeroing out horizontal as well as vertical speed. Eventually I intend to expand it into something akin to LOLA's "hover-to" AP.

I've already eliminated the pitch & roll routines as culprits. They can rotate to and hold a commanded attitude with little fuss.

The occilations appear to be caused by over-correction. IE overshooting the desired speed and then "slamming the brakes".

 

[C3PO]

Well, one solution would be to set a time "tConst" to reach zero velocity. That would mean that you wouldn't actually stop, but you would need to compensate for the orbital drift anyway.

The optimal time constant would probably vary with the actual craft/gravity combination.

The required acceleration "rAccel" would be: aSpeed/tConst

You calculate the maxAccel like mentioned. (It would probably be better using 95-98% of maxThrust if the pitch isn't 100% accurate)

If you set the tConst to 2 sec, and it takes more than 2 sec to stop, you use maxAngle. When rAccel < maxAccel the vessel should ramp down trying to stop within 2 sec.

You can experiment with the time constant to get a smooth ramp down.

 

[Hlynkacg]

Well, one solution would be to set a time "tConst" to reach zero velocity. That would mean that you wouldn't actually stop, but you would need to compensate for the orbital drift anyway.

The optimal time constant would probably vary with the actual craft/gravity combination.

The required acceleration "rAccel" would be: aSpeed/tConst.

"aSpeed" not "delta"?

also how, would you suggest calculating optimal "tConst"?

Keep in mind that "dSpeed" is fixed as {0,0,0} for the moment but in future it will be variable.

 

[C3PO]

I'm afraid this method only works if dSpeed = {0,0,0}

tConst would depend on the available acceleration of the ROT RCS, so calculating it will not be easy. The easiest way would be to find the lowest stable number for a specific craft (like the DG) by testing it.

But if you want to make a powered descent autopilot, this method is useless anyway. Especially if it's going to be a generic autopilot.

 

[Hlynkacg]

Good to know.

---------- Post added at 08:40 PM ---------- Previous post was at 05:03 AM ----------

Hmm...

After a lot of trial and error I seem to have developed a system that works reasonably well.

First here's the bit we've already discussed.

double ofsAngle = acos(dotp((vGravity/length(vGravity)),-vThrust));
double maxAngle = acos(length(vGravity)/maxThrust);
double maxAccel = (maxThrust*sin(maxAngle)) / GetMass();
double tConst = ofsAngle/rRate; // Where "rRate" is the rate of rotation imparted by RCS control inputs.

Now for our vectors.

VECTOR3 delta = dSpeed - aSpeed; // Where "dSpeed" = desired airspeed and "aSpeed" = current airspeed 
VECTOR3 aAccel = (vThrust*maxThrust)/GetMass(); // Available acceleration
VECTOR3 rAccel = delta - (aAccel*GetThrusterGroupLevel(THGROUP_MAIN)); // Required Acceleration.

Which are fed to the attitude control program as follows

CommandedPitch = -maxAngle*(rAccel.z / maxAccel) - (tConst*Pitch);
CommandedRoll = -maxAngle*(rAccel.x / maxAccel) - (tConst*Roll);

 

[C3PO]

Why oh why didn't I try to learn C++ or just any type of code. :lol:

I'm happy you've managed to make it work, even if most of that is lost on me. It looks to me like you're leaving out the tConst when calculating rAccel, but putting it back in when you're calculating commanded roll and pitch. That would make the unit for rAccel m/s, not m/s^2. But if that's beside the point as long as it works. (I'm really out on a limb here because C++ is Greek economics to me)

 

[Hlynkacg]

Why oh why didn't I try to learn C++ or just any type of code. :lol:

I'm happy you've managed to make it work, even if most of that is lost on me. It looks to me like you're leaving out the tConst when calculating rAccel, but putting it back in when you're calculating commanded roll and pitch. That would make the unit for rAccel m/s, not m/s^2. But if that's beside the point as long as it works. (I'm really out on a limb here because C++ is Greek economics to me)

I'm learning as I go so don't feel too bad. :tiphat:

In this case multiplying tConst by the current pitch/roll gives me the amount of time it'll take the vessel to return to a "neutral" attitude. This way as rAccel decreases CommandedPitch/Roll ramps down proportionally.