Well, admittedly I find the whole detour to what direction to turn the handle a bit silly in the first place - so if we must take that detour for whatever reason, then we should take it based on what my words actually mean. If it's important in detail by what motions to steer a bicycle, then why is it not important what 'to steer' really means? I mean, if you want to toy around, I can do that. But I'd prefer to have the original discussion.
The discussion was about how complicated the math underlying certain things is, whether you need a differential equation solver or can just 'do it'. And my point was that you can just do it without understanding differential equations, and that point is what matters.
If you want to stop a bicycle at traffic lights, you need to get the position to a certain value and at the same time velocity to zero. In terms of differential equations, you simultaneously monitor errors from velocity integrals and velocity itself. And if you brake too hard, you'll fly over the handlebar, so you also have constraints on velocity differentials. That's Urwumpe's PID controller.
Yet - we can do this quite easily. We don't need to solve the math in our heads, we can just stop a bicycle at traffic lights. In the same way, it's far easier to fly a Shuttle back to the runway after re-entry than to write the guidance software that does it for you (I've been amusing myself playing with some AP filters for guided re-entry, and I agree with Urwumpe that this is a fairly tough problem to code in a stable manner).
Yeah, I know that control theory is just making adjustments to inputs based on outputs, but differential equations and applied maths in general really interest me.
Well, that's a different direction from the original thread. I think the math isn't that terribly hard to understand. What's hard in coding a guidance system is to tune it, i.e. to avoid overcorrections and pilot-induced oscillations - so to make it respond rapidly enough so that it can respond to changing environment, but not too rapidly so that it doesn't oscillate.
What I've tried for my re-entry guidance code was to define a target deceleration.
So in every timestep, I can compute Delta_a = a_actual - a_desired. Based on that, I adjust lift/drag from zero to some max. value of my spacecraft (technically I could control this via bank angle).
One trick is what filter to use - I've chosen a linear response such that there's full response if |Delta_a|>1
So that leads to oscillations. These I've damped by requiring that L/D
- L/D(n-1) < step, so each timestep I may only change the response of the spacecraft by so much. That helps a bit, but still leads to oscillations.
Next I've been monitoring the derivative of Delta_a, arguing that the guidance system should drive to make the change of acceleration small when we're close to the target value, so we won't overshoot.
So a second filter monitors Delta_a
- Delta_a (n-1) if |Delta_a|< 0.3 and adjusts L/D such as to drive the derivative of Delta_a to zero if its value is that close to target.
That gives me a satisfactory guidance, but I have to adjust all constants, the response and the timings, to the particular spacecraft layout in terms of L/D, and also somewhat to the trajectory - so it's a three parameter tuning problem. And in the acceleration curves, you can see how the guidance system struggles to keep the limit, but by and large it does a decent job. But I could do it better by hand, see above.
It's this kind of thing you need to consider. Actually my code isn't very lengthy - if you're interested and want to play with re-entry dynamics and the rudimentary guidance, I'd be happy to let you have it.
