For anyone asking for the script to be released: it's in a messy state as is since I didn't code it with the prospect of ever releasing it. Also bear in mind that the guidance part is very similar to the PEGAS script by Reddy. The differences are in everything that wraps around the guidance loop (vehicle and staging handling, prelaunch etc..) and you may prefer to use his script since it's been tried and tested by many more people
Based on the behavior of your steering commands, it looks like you may be calling the "Lock Steering" command during each guidance loop. Doing this resets the steering PID each loop and essentially eliminates the stored integral and derivative data every time you call the LOCK command. This is why you're getting the overcorrection on every guidance loop. Instead, if you LOCK STEERING to a variable prior to entering your guidance loop, and then set that variable to what you would lock your steering to in every loop smooths that out. EDIT: I believe I saw that behavior in your shuttle reentry script as well
I'm well aware that locks inside loops are a bad idea and I can assure you there are none in my code. If the "behaviour" you refer to is the pitch steering during open-loop ascent that is because, although I only have one lock steering command, the vector I locked to is being re-calculated continuously. It's very noticeable because there's a lag inside the loop caused by refreshing the terminal window. During closed-loop there is an even greater lag, since now we also add the PEG calculations, but once guidance has converged, the difference between two steering comands is much smaller so it's barely noticeable. Besides, I don't think anything in this video is comparable to the steering issues I see with the Shuttle. The difference is that the kOS PIDs are well-tuned for engine gimballing and seem to be badly tuned for RCS or aero surfaces.
Hi, I'm trying to implement UPFG in kos using the space shuttle original paper but I don't understand what reference frame UPFG is using. Can you please explain what reference frame you are using? (se vuoi ita)
Position is simply a vector in space, in this case in a frame placed at the centre of the earth. So you can say that the length of this vector is the altitude + the radius of the earth, but that's it. In Physics you always want to describe events in term of things that don't change. Orbits are not easy to describe using state vectors, position and velocity, because they are always changing with time. In fact, the orbit is a law that predicts how position and velocity will change together. The invariants that describe the orbit are the five Orbital Elements, that can describe ALL the positions and velocity of the orbit, they are Semi-Major Axis, Eccentricity, Inclination, Longitude of Ascending node, argument of periapsis. Ap and Pe can be calculated form the SMA and the eccentricity. The orbital elements are handy to understand the shape of an orbit, the period and more, but they don't help you with kinematics, you really need the instantaneous position and velocity for that.
For anyone asking for the script to be released:
it's in a messy state as is since I didn't code it with the prospect of ever releasing it.
Also bear in mind that the guidance part is very similar to the PEGAS script by Reddy. The differences are in everything that wraps around the guidance loop (vehicle and staging handling, prelaunch etc..) and you may prefer to use his script since it's been tried and tested by many more people
Man I'd love a high detail step-through of this system
Sadly in many countries guided rockets are illegal
Very interesting. I like that you added the math. This is the type of content that makes me come back to RUclips and alike.
The rocket knows where it is because it knows where it isn’t. By subtracting where it is from where it isn’t…
Based on the behavior of your steering commands, it looks like you may be calling the "Lock Steering" command during each guidance loop. Doing this resets the steering PID each loop and essentially eliminates the stored integral and derivative data every time you call the LOCK command. This is why you're getting the overcorrection on every guidance loop. Instead, if you LOCK STEERING to a variable prior to entering your guidance loop, and then set that variable to what you would lock your steering to in every loop smooths that out.
EDIT: I believe I saw that behavior in your shuttle reentry script as well
I'm well aware that locks inside loops are a bad idea and I can assure you there are none in my code.
If the "behaviour" you refer to is the pitch steering during open-loop ascent that is because, although I only have one lock steering command, the vector I locked to is being re-calculated continuously. It's very noticeable because there's a lag inside the loop caused by refreshing the terminal window.
During closed-loop there is an even greater lag, since now we also add the PEG calculations, but once guidance has converged, the difference between two steering comands is much smaller so it's barely noticeable.
Besides, I don't think anything in this video is comparable to the steering issues I see with the Shuttle. The difference is that the kOS PIDs are well-tuned for engine gimballing and seem to be badly tuned for RCS or aero surfaces.
How does one calculate the omega_dot, and the V_GO? (timestamp 7:34)
i always wondered how rockets did this but my brain is melting
i just wish i knew how to math
Nice!
well done
Hi, I'm trying to implement UPFG in kos using the space shuttle original paper but I don't understand what reference frame UPFG is using. Can you please explain what reference frame you are using? (se vuoi ita)
we can talk about this over on discord, if you have it.
message me @ dolin #4214
What does position actually mean in this context? Ap, Pe and Altitude? or something else
Position is simply a vector in space, in this case in a frame placed at the centre of the earth. So you can say that the length of this vector is the altitude + the radius of the earth, but that's it.
In Physics you always want to describe events in term of things that don't change. Orbits are not easy to describe using state vectors, position and velocity, because they are always changing with time. In fact, the orbit is a law that predicts how position and velocity will change together.
The invariants that describe the orbit are the five Orbital Elements, that can describe ALL the positions and velocity of the orbit, they are Semi-Major Axis, Eccentricity, Inclination, Longitude of Ascending node, argument of periapsis.
Ap and Pe can be calculated form the SMA and the eccentricity.
The orbital elements are handy to understand the shape of an orbit, the period and more, but they don't help you with kinematics, you really need the instantaneous position and velocity for that.
@@giuliodondi thank you!
Man I need help with installing Katniss cape Canaveral can someone help me?
Hello there.... Do you still need help? 😅
@@Katniss218 haha nope, it turns out that it was just my hardware, I didn't have a great computer 😂
@@debs-3309 Aww, I see "didn't", I hope you got it now :P
Rockets get their computer data from onboard accelerometers and gyroscopes, laser range finders and satellite telemetry
It's true but, as long as the data is reliable, the guidance scheme does not care where the numbers come from.