enhancement: autopilot

[Assert1]

I know, you are making an autotuned autopilot, but i can't use it, because of absence of some required features. I need a very pricies control over the vessel attitude and attitude rate in the space (or suborbital) flight to implement an optimum closed loop guidance algorithm. Even small discrepancy can produce a very large errors at the orbit attachment point. The main feature that i need, is an attitude control with an attitude rate augumentation. In other words, by attitude value and it's rate of change simultaneously to provide base trajectory, trajectory dynamics and corrections (for earth curvature as example). I need a good atmospheric control for badly controllable vehicles, and ability to make rapid and large attitude transitions without an overshot. So, a very long time ago (even before you was added inertial tensor computation) I am implemented my own model based autopilot with my own available torques and inertial matrix computation (it is replaced by yours for now). It is completly free of any autotuning, and have a few uniform and independent from the vessel gains, because it is based on the physics behind controlling process, and not on the plain PID (actually, this is PID where proportional part replaced with constant acceleration part). More over, it is not required to tune this gains for any vessel, it works very fine with default values, even with great delays (that have very bad impact on the closed loop control performance) introduced by kRPC. I am tested it alot with many ships in the atmospheric and vacuum flight phases. A small oscillations about zero point can occurs for some cases, but this is acceptable for me. The main advantage of my scheme is a very good time performance (nearly optimal) without any significant overshots even with very small available torques, and ability to provide target angular rates, that is absolutly required in my case.

So, i am uploading my sources, it uses my math library, but everything should be clear. I am also providing a simple model of the control law which i am used to investigate and tune the controller with respect to kRPC delays. It is very easy to implement my scheme. May be if you try it, you can get some ideas how to improve your autopilot, make it completly free from any tuning and add target angular rate augumentation. I've expect much better performance when it will be implemented on the server side (but it requries some retuning).

AttControl.h.txt
AttControl.cpp.txt
model.txt

Also, i have a problem with the engine cutoff. kRPC delays prevents me to accuratly stop the engines when i need this. It becomes a big problem for unthrottable engines that produces alot of thrust because even 0.1 delay can result a few kilometers orbit change. It will be very usefull to add an autothrottle system with an option to stop engines by reaching the specified speed.

[Assert1]

I have no idea why do you skip this ticket, but i have made some investigation about current AP implementation. It works very bad, compared to my implementation. Test is to guide rocket by the optimum path to the orbit. Guidance command (pitch, yaw, roll), is recomputed few times per second. Same rocket, same conditions, same target orbit, nearly same smooth guidance commands until kRPC AP version makes significant errors, and path prediction and optimization system try's to compensate it. No tuning for my AP at all, autotuning for kRPC AP.

My AP pitch command (black) and actual pitch (blue):

kRPC AP pitch command (black) and actual pitch (blue):

My AP yaw command (black) and actual yaw (blue):

kRPC AP yaw command (black) and actual yaw (blue):

As you can see, kRPC AP is completly unusable at this moment...

[djungelorm]

Don't worry, I've not skipped this ticket! My time is limited and I haven't gotten round to reading and understanding your design yet.

[Assert1]

Sorry, but i do not know how long i will play with kRPC at this time, before my work gets me to switch off for a long period, and i can't answer anymore. So, any questions about my AP are welcome. The main idea, is to replace linear PID model with angular acceleration based PID model. Where proportional part is not a errorK but sqrt(abs(error)2/K)Ksign(error). The main problem of the classical PID, is that you trying to approximate constant acceleration moition (vt=v0+at^2/2) with linear law (vt=v0+at), that is wrong.

[djungelorm]

Thanks for the graphs!

It is possible I don't understand (I taught myself classical control theory when implementing the autopilot, and have no previous experience of the topic!) -- but I thought the kRPC autopilot does model constant acceleration using vt=v0+a*t^2/2??? That equation is used to work out the target deceleration time (documented here http://krpc.github.io/krpc/tutorials/autopilot.html - see the third bullet point in the section titled "Computing the Target Angular Velocity")

Also, the PID controller in the kRPC autopilot does not deal with acceleration. It tries to achieve a target velocity. This target velocity is calculated from the target pitch and roll (set by the user) and the moment of inertia and available torque of the vessel.

The various tunable parameters then affect the target velocity that is passed as the setpoint for the PID. They control things like how aggressively you want the vessel to turn. Also with tuning, the default values should work for any vessel - in theory. They just control things like how much of the vessels available torque you want it to use to turn etc.

From the graphs, it looks like the two autopilots basically work identically well, up until the point when the kRPC autopilot has been in a steady state for a while. This suggests that the dead zone (controlled by the attenuation angle parameter) needs increasing? I also wonder if this erratic behaviour could be caused by interaction between your target pitch/yaw code and the autopilot?

PS. I've not had time to look through your code, so not clear how your autopilot actually works. When I have more time I'll see if I can understand it and then improve the kRPC autopilot. Also, do you have an example of a stock vessel and kRPC script that experiences the dodgy behaviour in those graphs. Would be useful if I could reproduce it.

[Assert1]

To properly control something, we need to represent this process as a mathematical model. Then build a control of this model. PID controls, is an approximation of underlaynig process model to a simple linear process. But this is a VERY BAD approximation of rigid body rotation process under an external torque acpplication. Command output of the controller is an angular acceleration term, so we need to deal with an angular acceleration in any way. And you doing this, but assuming somthing other instead of angular acceleration. The model of the system is (expanding partial derivatives differential equation):

    ang_acc=command*(torque/mass);
    ang_vel+=ang_acc*dt;
    ang_pos+=ang_vel*dt;

This is how the vessel rotates about it's axis with respect to time. If we want to control ang_vel, we need to reverse this system with respect to it and command. That is:

    command=ang_acc/(torque/mass)
    ang_vel_tgt=ang_vel_cur+ang_acc*dt
    ang_acc=(ang_vel_tgt-ang_vel_cur)/dt

and finally:
command=((ang_vel_tgt-ang_vel_cur)/dt)/(torque/mass)
where (ang_vel_tgt-ang_vel_prev) is a velocity error, and (ang_vel_tgt-ang_vel_prev)/dt is actually an angular acceleration.

But, in the original problem, we need to control not an ang_vel, but an ang_pos. We can rewrite body dynamics system for ang_pos as ang_pos+=ang_vel*dt+ang_acc*dt^2/2 because ang_vel is a strict function of ang_acc. Assume (torque_max/mass) as accel_max:

    ang_pos_tgt=ang_pos_cur+ang_vel_cur*dt+ang_acc_cur*dt^2/2
    ang_pos_tgt=ang_pos_cur+ang_vel_cur*dt+(command*accel_max)*dt^2/2
    command=2*(ang_pos_tgt-ang_pos_cur-ang_vel_cur*dt)/(accel_max*dt^2)
    command=2*(pos_error-ang_vel_cur*dt)/(accel_max*dt^2)

THIS is an ideal control for the system, not the something you trying to approximate with linear function. And it is a background for my controller. Actually, we need to add disturbances compensation, command limit boundaries, near zero damping and normalize all gains.

it looks like the two autopilots basically work identically well

1. kRPC autopilot can't exit from the pure vertical ascent with required yaw. This results a horizontal speed buildup to the wrong direction in the gravity turn phase (black line jump compensate it when Q premits exceccive yaw manuvers).
2. While in gravity turn phase (pitch command is very close to the flight path angle to minimize drag, loads and momentums), it makes errors from 5 to 10 degrees, that result a wrong pitch at the gravity turn final point.
3. Immidiatly after second stage decoupling, it starts to oscilate significantly while commanded pitch is stable (it becomes unstable while approaching the orbit, and it tryes to make required injection).

I will make a stock vessel to reproduce and send a special version of my launch control with stock AP soon.

[djungelorm]

Ahhhhhh!! It just clicked - now i understand what's wrong :) Thanks!

[nateberkopec]

Just swinging through to say @Assert1's graphs of the KRPC autopilot's behavior replicate my experience.

[Cightline]

+1

[Cheaterman]

+1

[Cheaterman]

Seriously the auto-tuned autopilot doesn't work at all - I only tried it on planes so far, but it's unusable for them.