Old engineer here (66 years old and a metallurgical engineer for 45+ years). One thing I noticed in the video, was that the gimbal tended to increase oscillation - it did not look damped at all. You have 2 problems - one is getting the rocket to go straight up using the gimbal, and the second is getting the motor curve right to land and actuate the gear. Simplify the problem and break it into the two parts. For instance, to reduce the oscillation of the gimbal during ascent (and to get the proper height), add some small fins to the body of the rocket. This is only a temporary thing, to allow focus on the landing portion (hardest problem). This minimizes gimbal oscillation during ascent and helps overcome the wind loading on the airframe (and allow the rocket to get to the desired height). Once you have the issues with landing resolved, you can take off the fins, and concentrate back on reducing the gimbal oscillation during ascent. You are so close. I have been following your work for quite a while and am very impressed. The interdisciplinary approach needed (mechanical engineering, electrical engineering and material science), gives me hope. Good job.
@@davidf2281 That is a good point as it would change the center of pressure. It the fins were just small enough to minimize gimbal oscillation, but not large enough to significantly change the center of pressure, it might not destabilize on the descent.
this was also my first thought when I saw the flight in slow motion. The feedback control of the gimbal system tends to build up the amplitude instead of dampening the oscillation. Finetuning the PID element could solve the problems with the oscillation.
Scott….60 yr old aeronautical engineer checking in. Your assessment is spot on. The oscillation, or negative dynamic stability issue is extremely difficult to overcome, however as with anything the devil is in the details, or in this case, being meticulous. I’m very confident that Joe is made of the stronger stuff that most of us can only aspire. He will not only solve these things, he will open doors he yet knows exist. God speed Joe!
So, I had a think... You don't need to work with one landing curve, you can work with many! If AVA has enough memory, try a set of landing curves, say one per meter of altitude between 15 and 30 is those extremes are within the range the throttle can vary thrust for, and have the computer calculate expected apogee at burnout, then go into a lookup table and pull the correct curve. Depending on memory, you can vary the apogee resolution to just fit. 7 meters is obviously way out of line (as demonstrated), but depending on various factors a meter might be plenty. Alternatively, are there any weird discontinuities between the landing profiles needed for various apogees? If not, a scaling factor or two derived from that particular flight's predicted apogee might be enough, and that's both smaller and faster to execute.
Why not use pencil beam liar? You can get them in a really small package. But I think closing the loop while trying to land would solve these problems.
I think I'm thinking the same thing as OP. The flight controller should be determining when to start the second motor, etc. on the fly. It shouldn't be replaying one thrust curve which was set before the flight. AVA has inertial data so it can decide whether it needs more or less thrust at any given moment. If I were Joe, I'd write a function that takes intertial data and motor gimbal as parameters and outputs thrust %. I can't imagine AVA's memory or clock speed being a limitation here.
I dug out the code from a mars landing simulation I worked on a while ago and here's how I handled powered descent. Is your thrust at minimum throttle below your dry weight? If so, you could use a similar approach: If above 5 metres, the target velocity 'v' is set assuming constant deceleration: v = sqrt(u^2 + 2as), where 'u' is our desired end velocity (zero), 's' is our altitude plus 5 metres, and 'a' is our maximum theoretical deceleration rate at this exact moment in time including gravity. This makes optimum use of delta v. If below 5 metres, the target velocity is set linearly based on altitude, decreasing to 0.5 m/s at zero altitude to ensure a firm touchdown at which point the engine is cut. By trying to get to zero velocity by 5 metres, we build in a safety net in case we under perform. A PID controller uses the throttle to achieve target velocity. I found this worked reliably under all sorts of descent conditions. The code is in vector form. double target_velocity = sqrt(2 * ((MAX_THRUST - Fg.abs()) / lander_mass) * (position.abs() - MARS_RADIUS - 5)); if (position.abs() - MARS_RADIUS < 5) target_velocity = 0.5 + Kh * (position.abs() - MARS_RADIUS); velocity_error = -(target_velocity + velocity * position.norm());
Instead of the radius of Mars they would need to use the altitude to ground. I am not sure they have this measurement or maybe they use barometric altitude (slow). Or maybe they integrate the forces from the accelerometer... I think in reality you would use radar altitude measurements. Although small versions of such sensors are available, they will still be rather large for a rocket. Maybe the best bet for the last 5 meters is a simple ultrasound distance measurement. The control problem itself is not very hard to solve, but the noise on the measurements are high and the process is very quick, so a small error will already be catastrophic.
Reasons why I love this channel: Awesome projects Never gives up Great techincal information *Puts what everyone wants to see at the start of the video*
First of all: MAD respect for what you have done so far!!! Regarding your invitation for feedback: I am studying aerospace and rocket science in Germany and in one interesting lab on the calibration of sensors we learned about one possible source of the problem with the "wiggling". Broadly speaking if you want to measure something correctly you need to measure at least 10 times more often than the expected change rate of what you are measuring. For example if you are measuring something that would plot a sinus wave and you start at 0 and measure it only every "pi" interval the results will be a constant 0. If you measure it every "pi/2" the result will be a weird "wiggle" of 0, 1, 0, -1, 0,.... if you measure it in smaller increments of "pi/10" you actually start getting a kinda smooth sinus wave. What I am hinting at is that one possible problem is that the interval in which your sensors measure (or your servos react) are to slow compared to the change rate of what you are measuring / trying to correct. Secondly, someone else has encountered your problem and has solved it. It is a guy trying to build a solar tracker, but it kept over correcting and started to "wiggle". The video is short and about half way through he talks about this initial problem and how he solved it. th-cam.com/video/Oj1E7o7J3qc/w-d-xo.html "World's simplest sun tracker." by "3D Printer Academy". Hope that helps. Would love to see you succeed!!!
The data shown at 5:14 clearly tells me, that the rate at which you are currently measuring is far too low... the way the graph looks tells me that you actually do not have the data. In between the horizontal bar at the peaks could be a temporary spike that is 2 times higher that you just don´t know about and thus cannot correct
I bet if you just get a sensor that measures 10 times faster or more you actually get a completely different looking graph and would thus have to adjust the input of your servos
I think this is a good point. The other thing that came to mind is that it seems like it needs some kind of smoothing function to average the inputs over time to avoid over-correcting and therefore bouncing back and forth between extreme opposites. Either that or some way of mechanically isolating the sensors from the vibrations to reduce "false" inputs. Overall, this is awesome work and I've been a huge fan of your videos for the past few years!
I took a digital signal processing course this semester and the term you are probably looking for is called "alias" or a violation of the Nyquist Theorem. I suppose those shown data points are at a much lower rate in the telemetry data than in the actual control loop. But this might be an important point to look into. Once you're sampling at a sufficiently high rate (using DMA for example) you can filter high frequency garbage much easier an avoid the control system becoming unstable because of high frequency noise coming back to haunt you as alias in low frequency data
I wonder what the tradeoff would be vis-a-vis cost of increasing the measurement frequency (does it require more computing power, battery, higher quality sensor or actuator, etc)? Sometimes a simple interpolation algorithm will help quite a bit in these cases. This is such a cool project and so close to landing as well.
I’ve been following you since you had 5k subs. You are so close to sticking a landing and I’m going to be super proud when you do. It’s been years in the making and you’re super close!
9:39 perhaps the solution is to not calculate it at peak thrust, but rather at peak apogee, therefore you have a consistent way to slow the rocket down to touchdown? Another possible solution is to have multiple plot points set for different altitudes, for example one at 25m, 20m, and 15m, and switch to them based on reached height of the rocket.
For the higher level control of when to light motors you are already getting dangerously close to model predictive control that you might as well make an MPC.
As a new aerospace engineering graduate, your videos are AMAZING and help me to get excited again for the work I do and the projects I want to work on!
As a computer scientist, since you have access to real-time flight metrics and know you're landing burn constraint I would develop an algorithm or deterministic computation that would be able to handle landing at any given real-time descent. That way you aren't "hard-coding" for 25m +/- 3m. This is an incredible project, nice work!
Am I the only one who sees a notification for a new BPS video and waits until they have spare time in the day to enjoy every second of the video to gobble it all up! Love it Joe! Great work!!
Joe's enthusiasm for his failures (that still return useful data) reminds me of the running joke from Milk: "We lost, but with more votes than ever!" That, and the fact that he doesn't make you wait for the money shot are two of the biggest reasons I love his work.
I had a couple of dangerous ideas of how you could control of the throttle on a solid rocket motor. Activity control the amount of exposed surface area of the fuel grain. One way was to push a carbon rod into the top center of the rocket motor. Then during flight, have a linear servo push or pull the rod. Another idea would be to split the rocket motor vertically into 3 or more shafts. Then rotate them together like an iris
Dude this is really awesome!!! Bears close resemblance to the Grasshopper tests and the Falcon 1....and yeah knowing how that lil program turned out....you'll get there too!!! Awesome work..!!!
Only just recently found your channel and 1) I’m not an engineer 2) yesterday I tourney 70, 3) launched my first model Rocket a simple old Centauri Model that I launched and it just flew out of sight and the parachute drifted my first rocket out of sight never to be seen again. 😂 that was in 1965 😳😂 watching your channel is just amazing entertainment for one who remembers vividly the early space race days. I stayed home from school to watch Alan Sheppard’s first suborbital flight and I still can’t believe Mom allowed me to do that! Undaunted I built more rockets and flew them until I discovered the opposite sex 🤦🏻♂️😉. Then when I had kids, I reentered the model rocketry hobby and got my son and daughter involved and it was great family fun.
I think the easiest thing to try first would be computing multiple landing trajectories for different initial conditions, and looking up the closest match on descent. Check out LQR trees from Rus Tedrake’s lab, and watch the underactuated robotics series for more ideas. If you wanna get fancy, I’d suggest PPO+dynamics randomization to get a controller that works well on any descent
Moving the accelerometers up to the CM should help reduce the impact of the wiggle, and if you leave the battery back at the motor mount the CM shouldn't shift too much.
Great progress, word to the wise softmounting your imu/gyro board will change your life! look for rubber gummies or anti vibration standoffs used for flight controllers! Another material is alpha gel! Adding these will allow you to tun your PID loop - good luck x
great vid. Just had a thought (i'm sure easier theorized than executed) - can you redesign the throttle arms, such that when they are close, they redirect the thrust sideways in 4 (or at least 2) axis, or reversing the thrust, aiding with keeping the rocket in place. example of this can be seen in the Boeing 737 Thrust reversers.
@@clonkex if reversed (pushing down), sideways just enables zero thrust - though i agree with you that it seems (could not find too much info, any pilots here?) bucket thrust reversers don't truly REVERSE the thrust.
Came here to say just this. Rather than trying to block the efflux, redirecting it with 'open-backed scoops' might allow deeper throttleability, and could add a method of vectoring the thrust in the terminal phase.
Running a simulation that attempts to characterize the rocket in real time could be an option. Might need something with a bit more processing power to make that work though.
I have used this approach on many occasions. Accurate state estimation is really the only way to control such a dynamic system. However, there are so many parameters that it becomes computationally expensive quite quickly, especially for higher polling rates.
Add a Prox(imeter) Center to the bottom of your rocket. When the prox hits, the 4 axis (0-90-180-270) thrust cancelling defectors activate, (with the possibility of thrust vectoring for the last 1-5 secs). So if the initial burn w/weight did/didn't achieve the proper height with the payload; it then would then wouldn't matter (On Target, No. Landed, Yes.).
Perhaps your ceramic thrust reduction pincers should be cup shaped to redirect exhaust gasses slightly upward which would not only reduce upward force via downward thrust reduction, but could also reduce it further via the gasses redirected upward providing a downward force. This would increase the range of upward force control and also allow landing lock by fully closing to direct thrust upward once landing leg contact is detected.
In my ignorance I think that one of the problems of the rocket falling on landing is the landing charge lasts for a long time there would have to be the possibility of ejecting or turning off the charge as soon as it touches the ground. the second visible problem is the landing support that perhaps should be more supported above the middle of the rocket. I really admire your project.
I'm 1:10 in, but holy crap! I'm so glad to have seen the progress for as long as i have! What a brilliant flight! oscillation was definitely it saying it's happy as Nicholas has!!
Joe, great job. I have some questions and suggestions: 1) Your rocket is unstable by design. During ascent phase it uses TVC to stabilize it and you lose performance (max altitude). Every take-off is affected by that and it is an additional variable which is not covered by your simulations. Why don't you make the rocket stable at ascent? Just add fins, move center of gravity and center of pressure, keep TVC switched off for take-off and turn it on for landing only. Maybe this will make your flights more predictable and repeatable. You have already proved that you can stabilize unstable rocket at ascent. You do not have to prove it every time. What you struggle with is the landing (as I understand from all you movies on YT, I spent a lot of time watching and enjoying them ;-) ). Remove the uncertainty that affects landing phase. 2) You use reaction wheel to reduce tendency of the rocket to rotate along its axis. It is heavy. Have you compared the weight of the reaction wheel system and for example actuators to fins that would rotate all of them in one direction (clockwise or counter-clockwise)? Would it be lighter even if you have to include fins (see point (1) above)? Just a trade-off study. 3) The landing legs are deployed just before landing. As I understand each leg has 2 bars. Is the upper bar attached to the rocket tube below or above the center of gravity (CG) of the landing rocket (all fuel of the landing motor used)? If it is below then maybe moving it (much) above CG would help to improve landing? 4) I would propose the modification of the landing procedure and hardware. Assume that the rocket is approaching the ground and the motor is still working. If one of the legs touches the ground (or the rocket is really close to the ground) then the direction of thrust should be reversed as in thrust reverser of jet engine on an aircraft. At this moment the thrust would push the rocket to the ground and keep it there as long as the motor works (from your movies it might be 1-2 sec). If the motor stops working before that then nothing happens. Thus it would require modification of the hardware: attachment of contact sensors to the legs, adding clamp shells (four) that will close completely (no leaks) and that would move with TVC. The sensors would trigger closing of the clamp shells. The landing procedure and the software controlling TVC would have to be modified as well. 5) I am not sure if you noticed how quality of your movies improved over the time. You are doing really good work here!
Maybe one more thing ... the landing legs ... they are very elastic and make the rocket bounce at touch-down. You either need: a) a damper added to the legs or b) a part that will deform permanently at landing and does not cause return to the original shape (=plastic deformation) - this approach was used during Apollo program in LM legs
Fins only work at high speed. If Q is low the rocket is still inherently unstable. That’s why model rockets and military fin stabilized rockets are launched on rails or in tubes that stabilize until its moving fast enough.
My god that's a beautiful bit of engineering from beginning to end, even if there it's not a perfectly outcome. This is the scientific method in practice and how to find solutions to problems via rigorous data collection and honest analysis of the system and decisions made to get it there. Our governments could learn from this (in no small way!). Brilliant stuff, Joe.
If you have two or more motors that rotate into opposition and then finally upside down~ish to be a near instant down force. Some leg wiskers can start the engine flip. The legs can have a progressively stiffer "crush" function.
This is probably my favorite project going on on YT by far. Scammer Paybacks or Mark Robers big videos are cool and all, but this is something different. Don't lose hope, I think the hardware is pretty much done. With a very good worked out brain this thing will go places, high places! Take your time to give the problems the care they need and we'll see a beautiful touchdown with the rocket standing straight up! Cheers!
On landing, add another constraint to override the profile and cutoff as much thrust as possible if the landing legs hit the ground. One more sensor to detect the legs impacting ground or maybe acceleration sensor can detect the landing.
A few suggestions here: 1. Use a function which takes in the current velocity of the rocket, the vertical and horizontal distance from the landing zone and the burn time left to calculate the appropriate throttle value.
Amazing! You should consider a bang-bang baseline control with state matching blending into a PID. I do this for an ultra fast steering system that has lots of viscous and dry friction damping. I think you already know that your gimbal simulation needs full multi-body dynamics.
1) the wiggle cost you apogee, but it looks so cool! 2) There’s plenty brainy folks about, but your you are real good at presenting the engineering design thinking - I hope you make it to space, but I think you may have a reasonable chance for the next prize to be a position as a professor somewhere! 3) looking forward to the next one!!
On guidance control a frequency of 400 Hertz is used, that is the time from angular transducer sensing delta to control servo reacting in minute increments to stabilize trajectory path.
Awesome video, Joe! I just wanted to share some ideas. You said your ceramic motor modulators can only bring down the force to 20%, which I don't think is an issue. It seems you have good control of getting the rocket close to the ground stably, but you need more precision in the last couple meters. I feel like adding a small distance sensor for this little portion would be very helpful for this. You can get a small, light one to get precise measurements for the last bit of the landing. I think it is also important to have your engine be able to exert the force around the weight of the rocket around landing. This will bring the rocket's velocity to zero. Then with your ceramic modulators and your distance sensors, you can close the distance to the ground with active control, instead of a more timing/guessing method. In short, I feel like the key for the landing is getting distance measurements from the ground (via the distance sensor), and the engine having a profile where it can exert a force near the weight of the rocket, to bring the rocket to the ground with close to zero velocity. Once you're on the ground, that 20% shouldn't matter so much, so long as you are doing less force than the weight of the rocket, you won't be exerting much vertical force. Hope this helps!
so i had an idea yesterday, inject some kind of extinguishing gas/liquid/powder into the combustion chamber to give solid rockets throttling capability. extinguishes the flame if you do too much but im sure the right balance and correct element youd be able to just choke the combustion and be able to raise/lower throttle via the amount of stuff you pump in/speed/temp
I feel like this is a sign for you to move to a liquid fueled rocket, massively increasing the complexity, while also increasing the scalability (for being able to land under various loads) and how high you can go.
Top fuel jet boats will use a neutral bucket to redirect water 90 degrees to each side that will negate any forward thrust while staging. You might be able to use that instead of outright trying to block the thrust.
This is the first time I've tripped over one of your videos, and I'm really impressed with what you have accomplished. I assume you are familiar with the concept of PID loops, but if you aren't you definitely should look them up. PID = Proportional, Integral, Differential. It is a general control strategy applied to continuous industrial processes, and your rocket is a continuous process when it is operating. The general idea is to use a PID control algorithm in a feedback loop, such as your gimbal control. You tune the PID parameters for the general way the process is observed to operate, but there is generally enough wiggle room in the control algorithm to account for things going to the limits (or even beyond) and getting back in control. In this case there wasn't near enough damping in the motor control, resulting in it slamming to one side, the control noticing that the rocket is now leaning to the opposite side as at first, and then slamming back. A longer integration time would help with that. On the landing burn, I think your right that your current control strategy isn't optimal. I've never done what you are doing, so I'm just thinking out loud here. I think that the viewpoint I'd take is that you have an unpowered object of some approximately known mass, descending at a measurable speed and acceleration (which is approximately g less some empirical wind resistance), and which needs to stop at some determinate point. If your altitude measurement is good enough you should know the distance to the landing altitude. Then the goal is to apply some integral force F over some time T such that V=0 at the desired altitude. You should be able to calculate the ignition start time from those parameters, and be able to resulting change in vertical acceleration and speed based on the force. This algorithm should be independent of total time of flight and of peak altitude reached, assuming that the altitude is high enough that you can completely burn the descent stage by impact time. I guess your descent rocket force is approximately a constant value and is then reduced by your control pinchers. Since F=MA and the F is known for the descent rocket and M is known from initially weighing the rocket less the ascent tube, you can calculate a constant A to result in V=0. Then the question is to calculate the altitude to start the burn, which is done by (if I recall my long-ago math correctly) differentiating MA to get a known distance with a known F. Well, I hope some of that made some sort of sense, and might be useful to you.
Joe, I just hit subscribe and like. You have got a great idea for a learning video about space. Lovely how you modulate engine thrust by diverting the plume. Just wow. DIRECTIONAL control by gimbal. Fabulous.
if i had to guess, and i never worked in something like this(disclaimer), i would try to corelate thrust and mass flow rate with altitude. that would be my landing system. I think mass flow rate is the key here. It should also be taken in consideration when you are estimating your center of mass and how much it drifts when you gimbal the rocket. For this i would have separate algorithms because of the discontinuity in the mass curve, when you eject the firts engine. Again, i'm "thinking out loud" here. I'm actually graduating in eletrical engineering so...
Amazing progress so far! The way I would approach it is to calculate the total change in velocity your landing impulse can obtain, and do a running calculation of how much thrust you need to land perfectly. When the two line up appropriately (With timing and tolerance of the engine specs, etc), you fire the landing impulse. Start with this. Take a random set of drop altitudes and figure your curves as you mentioned, finding the ideal time to start the ignition in each case. Plot the drop altitude vs ideal time to start and see if you can find a formula, there should be a clear one. With that you can know when to start. The idea is to have a well generated curve that is based on the actual conditions, not the expected ones. With this approach, the goal of the ascent is to go as straight up as possible, because it is very difficult to recover if the vehicle isn't stable. Still, I'm sure you'll get this! Keep it up!
For the vectoring oscilation. You can create situations where the negative short term relation between control and observation (non minimum phase system) "causes" the instability. Your rocket should behave simular to a segway like system, but just with different parameters . A lot is writen about it so I recomend you look at ways they deal with possition control. Can't remember if there is much usefull to find about it regarding your situation though. You can also change the system so you don't control the rocket but the rocket-motor system combined. But this means you have to reconstruct that systems state from the rocket measurements, and how moving the motor influences the system.
You could study the apogee perturbation problem by using an Extended Kalman Filter (dynamic model of descent portion of flight assuming apogee is known) by making a Monte Carlo simulation for the different initial conditions to quantify state covariance of that portion of the model. I'm thinking the EKF could even produce the PID set points once you know how much "noise" the EKF has to take into consideration. I would even estimate apogee with an EKF.
To fix the bounce issue on landing; try using sharp pegs that are angled towards the centre instead of flat feet, these should dig / hook into the ground on landing with no need for a landing pad. Good luck!
You should look at the internal model principle if you want the height PID to track the set-point without any error. You could try to develop a linear model predictive controller for the altitude with the constraints that the final altitude and velocity in z direction are zero.
Some interesting physics on this: if you assume a constant deceleration over a known time (burn time of the second engine), that implies a ratio between the velocity and altitude at the beginning of the deceleration, regardless of the deceleration value. I suspect that starting the engine at that sweet spot and choosing a flight profile such that the required deceleration is in the middle of the control range would minimize the required control effort
IMO, I'd prioritize stability in flight by moving the CG as far forward. Then there should be less lateral movement for the legs to deal with on landing.
My thought is to shift 'the "X" marks the spot' for landing to a "is the craft upright and not precessing" requirement. Unless you are tracking winds onboard the system, where you 'want to land' doesn't matter as much as will it still be upright when the smoke clears.
During the wiggle it also appears to be causing the fuselage to oscillate on ascent. Either fixing the wiggle or verifying that the fuselage oscillation potential is as low as possible should also help.
Landing rockets can be coded and simulated in simplerockets2, well I'm not having had hands on real rockets since about 5 years but I find it very helpfull
Many people may not see it to my extent but even tho scout failed its mission i find it a masterpiece like the way it stabelized itself using a not so diy but still diy system then cut its thruster and reactivate it along with the landing legs. Masterpiece.
Sometimes the wiggle just means it’s happy to finally be flying
I second this notion!
That makes sensr
It does have a dog name after all
Give it a bone afterwards.
I'd like to see you wiggle, wiggle, for sure
It makes me wanna dribble, dribble, you know
"I did a bad job" is a shocking statement for the incredible job done so far. That rocket is 90% complete, no doubt. Very impressive work!
the last 10% takes 90% of the time
@@KX36 INDEED
Pareto principle
You see the problem here is when it stopped moving it was on its side, you want it to stop with the pointy bit facing up.
I think the maths would be easier if you reinforce the pointy end and spear it into the landing zone. Guaranteed no troublesome bouncing issues too...
Good observation. You've got a keen eye for science
Or just redefine the objectives
Lol
So pointy down flamy up?
Old engineer here (66 years old and a metallurgical engineer for 45+ years). One thing I noticed in the video, was that the gimbal tended to increase oscillation - it did not look damped at all. You have 2 problems - one is getting the rocket to go straight up using the gimbal, and the second is getting the motor curve right to land and actuate the gear. Simplify the problem and break it into the two parts. For instance, to reduce the oscillation of the gimbal during ascent (and to get the proper height), add some small fins to the body of the rocket. This is only a temporary thing, to allow focus on the landing portion (hardest problem). This minimizes gimbal oscillation during ascent and helps overcome the wind loading on the airframe (and allow the rocket to get to the desired height). Once you have the issues with landing resolved, you can take off the fins, and concentrate back on reducing the gimbal oscillation during ascent.
You are so close. I have been following your work for quite a while and am very impressed. The interdisciplinary approach needed (mechanical engineering, electrical engineering and material science), gives me hope. Good job.
I should imagine ascent damping fins would become destabilization fins on descent, thus making the hard problem harder, no?
@@davidf2281 That is a good point as it would change the center of pressure. It the fins were just small enough to minimize gimbal oscillation, but not large enough to significantly change the center of pressure, it might not destabilize on the descent.
this was also my first thought when I saw the flight in slow motion. The feedback control of the gimbal system tends to build up the amplitude instead of dampening the oscillation.
Finetuning the PID element could solve the problems with the oscillation.
Scott….60 yr old aeronautical engineer checking in. Your assessment is spot on. The oscillation, or negative dynamic stability issue is extremely difficult to overcome, however as with anything the devil is in the details, or in this case, being meticulous. I’m very confident that Joe is made of the stronger stuff that most of us can only aspire. He will not only solve these things, he will open doors he yet knows exist. God speed Joe!
Adding a bit of derivative feedback is a traditional way to reduce oscillations in a feedback control system.
So, I had a think... You don't need to work with one landing curve, you can work with many!
If AVA has enough memory, try a set of landing curves, say one per meter of altitude between 15 and 30 is those extremes are within the range the throttle can vary thrust for, and have the computer calculate expected apogee at burnout, then go into a lookup table and pull the correct curve.
Depending on memory, you can vary the apogee resolution to just fit. 7 meters is obviously way out of line (as demonstrated), but depending on various factors a meter might be plenty.
Alternatively, are there any weird discontinuities between the landing profiles needed for various apogees? If not, a scaling factor or two derived from that particular flight's predicted apogee might be enough, and that's both smaller and faster to execute.
Why calculate apogée doesnt scout has a pressure sensor and detects apogee anyway for the state machine
@@nikoheinz1213 Yep, but knowing a bit earlier might help. That, and barometric pressure is subject to all sorts of oddities.
@@littlegrabbiZZ9PZA yup makes sense
Why not use pencil beam liar? You can get them in a really small package. But I think closing the loop while trying to land would solve these problems.
I think I'm thinking the same thing as OP. The flight controller should be determining when to start the second motor, etc. on the fly. It shouldn't be replaying one thrust curve which was set before the flight. AVA has inertial data so it can decide whether it needs more or less thrust at any given moment. If I were Joe, I'd write a function that takes intertial data and motor gimbal as parameters and outputs thrust %. I can't imagine AVA's memory or clock speed being a limitation here.
I dug out the code from a mars landing simulation I worked on a while ago and here's how I handled powered descent. Is your thrust at minimum throttle below your dry weight? If so, you could use a similar approach:
If above 5 metres, the target velocity 'v' is set assuming constant deceleration: v = sqrt(u^2 + 2as), where 'u' is our desired end velocity (zero), 's' is our altitude plus 5 metres, and 'a' is our maximum theoretical deceleration rate at this exact moment in time including gravity. This makes optimum use of delta v.
If below 5 metres, the target velocity is set linearly based on altitude, decreasing to 0.5 m/s at zero altitude to ensure a firm touchdown at which point the engine is cut.
By trying to get to zero velocity by 5 metres, we build in a safety net in case we under perform. A PID controller uses the throttle to achieve target velocity.
I found this worked reliably under all sorts of descent conditions. The code is in vector form.
double target_velocity = sqrt(2 * ((MAX_THRUST - Fg.abs()) / lander_mass) * (position.abs() - MARS_RADIUS - 5));
if (position.abs() - MARS_RADIUS < 5) target_velocity = 0.5 + Kh * (position.abs() - MARS_RADIUS);
velocity_error = -(target_velocity + velocity * position.norm());
Instead of the radius of Mars they would need to use the altitude to ground. I am not sure they have this measurement or maybe they use barometric altitude (slow). Or maybe they integrate the forces from the accelerometer...
I think in reality you would use radar altitude measurements. Although small versions of such sensors are available, they will still be rather large for a rocket.
Maybe the best bet for the last 5 meters is a simple ultrasound distance measurement.
The control problem itself is not very hard to solve, but the noise on the measurements are high and the process is very quick, so a small error will already be catastrophic.
Reasons why I love this channel:
Awesome projects
Never gives up
Great techincal information
*Puts what everyone wants to see at the start of the video*
Best yt channel
First of all: MAD respect for what you have done so far!!! Regarding your invitation for feedback: I am studying aerospace and rocket science in Germany and in one interesting lab on the calibration of sensors we learned about one possible source of the problem with the "wiggling". Broadly speaking if you want to measure something correctly you need to measure at least 10 times more often than the expected change rate of what you are measuring. For example if you are measuring something that would plot a sinus wave and you start at 0 and measure it only every "pi" interval the results will be a constant 0. If you measure it every "pi/2" the result will be a weird "wiggle" of 0, 1, 0, -1, 0,.... if you measure it in smaller increments of "pi/10" you actually start getting a kinda smooth sinus wave. What I am hinting at is that one possible problem is that the interval in which your sensors measure (or your servos react) are to slow compared to the change rate of what you are measuring / trying to correct. Secondly, someone else has encountered your problem and has solved it. It is a guy trying to build a solar tracker, but it kept over correcting and started to "wiggle". The video is short and about half way through he talks about this initial problem and how he solved it. th-cam.com/video/Oj1E7o7J3qc/w-d-xo.html "World's simplest sun tracker." by "3D Printer Academy". Hope that helps. Would love to see you succeed!!!
The data shown at 5:14 clearly tells me, that the rate at which you are currently measuring is far too low... the way the graph looks tells me that you actually do not have the data. In between the horizontal bar at the peaks could be a temporary spike that is 2 times higher that you just don´t know about and thus cannot correct
I bet if you just get a sensor that measures 10 times faster or more you actually get a completely different looking graph and would thus have to adjust the input of your servos
I think this is a good point. The other thing that came to mind is that it seems like it needs some kind of smoothing function to average the inputs over time to avoid over-correcting and therefore bouncing back and forth between extreme opposites. Either that or some way of mechanically isolating the sensors from the vibrations to reduce "false" inputs.
Overall, this is awesome work and I've been a huge fan of your videos for the past few years!
I took a digital signal processing course this semester and the term you are probably looking for is called "alias" or a violation of the Nyquist Theorem. I suppose those shown data points are at a much lower rate in the telemetry data than in the actual control loop. But this might be an important point to look into. Once you're sampling at a sufficiently high rate (using DMA for example) you can filter high frequency garbage much easier an avoid the control system becoming unstable because of high frequency noise coming back to haunt you as alias in low frequency data
I wonder what the tradeoff would be vis-a-vis cost of increasing the measurement frequency (does it require more computing power, battery, higher quality sensor or actuator, etc)? Sometimes a simple interpolation algorithm will help quite a bit in these cases.
This is such a cool project and so close to landing as well.
I’ve been following you since you had 5k subs. You are so close to sticking a landing and I’m going to be super proud when you do. It’s been years in the making and you’re super close!
Personally I'm surprised he hasn't done it yet.
9:39 perhaps the solution is to not calculate it at peak thrust, but rather at peak apogee, therefore you have a consistent way to slow the rocket down to touchdown?
Another possible solution is to have multiple plot points set for different altitudes, for example one at 25m, 20m, and 15m, and switch to them based on reached height of the rocket.
I've been waiting for this upload for ages
Finally. I just watched and hoped to release a new video and it came true. well thank you
The fact that youre doing things this advanced this young is astonishing. You seem like you will be successful
Congrats on an awesome sponsor like onshape 👌
i have been following u now for couple of years ...the kind of dedication u have...that gives me motivation
Can’t wait to see the future of Scout F! Good luck with the attempts!!!
For the higher level control of when to light motors you are already getting dangerously close to model predictive control that you might as well make an MPC.
Onshape is awesome, cool to see you getting more sponsers
I've followed you for years now, you are amazing and so inspiring. keep the awesome work and education coming !
As a new aerospace engineering graduate, your videos are AMAZING and help me to get excited again for the work I do and the projects I want to work on!
MY DUDE! Excellent execution here! The setup is looking so mature at this point. Scout will 100% nail this, I'm convinced! Next flight will be!
As a computer scientist, since you have access to real-time flight metrics and know you're landing burn constraint I would develop an algorithm or deterministic computation that would be able to handle landing at any given real-time descent. That way you aren't "hard-coding" for 25m +/- 3m. This is an incredible project, nice work!
Have used Onshape for years at work and it's great. 👍👍
You are so close! This is super impressive. Love your videos. Keep it up!
bro you're so cool no matter all the accidents you have you can easily just brush it off and I hope your dreams come true one day
So close!! I am incredibly impressed by how much work you've put into this and how good of results you're getting.
Am I the only one who sees a notification for a new BPS video and waits until they have spare time in the day to enjoy every second of the video to gobble it all up! Love it Joe! Great work!!
Joe's enthusiasm for his failures (that still return useful data) reminds me of the running joke from Milk: "We lost, but with more votes than ever!"
That, and the fact that he doesn't make you wait for the money shot are two of the biggest reasons I love his work.
You are f*cking genius dude. Amazing work
Your Passion for this Project is inspiring!
I had a couple of dangerous ideas of how you could control of the throttle on a solid rocket motor. Activity control the amount of exposed surface area of the fuel grain. One way was to push a carbon rod into the top center of the rocket motor. Then during flight, have a linear servo push or pull the rod. Another idea would be to split the rocket motor vertically into 3 or more shafts. Then rotate them together like an iris
Dude this is really awesome!!! Bears close resemblance to the Grasshopper tests and the Falcon 1....and yeah knowing how that lil program turned out....you'll get there too!!! Awesome work..!!!
Only just recently found your channel and 1) I’m not an engineer 2) yesterday I tourney 70, 3) launched my first model Rocket a simple old Centauri Model that I launched and it just flew out of sight and the parachute drifted my first rocket out of sight never to be seen again. 😂 that was in 1965 😳😂 watching your channel is just amazing entertainment for one who remembers vividly the early space race days. I stayed home from school to watch Alan Sheppard’s first suborbital flight and I still can’t believe Mom allowed me to do that! Undaunted I built more rockets and flew them until I discovered the opposite sex 🤦🏻♂️😉. Then when I had kids, I reentered the model rocketry hobby and got my son and daughter involved and it was great family fun.
I think the easiest thing to try first would be computing multiple landing trajectories for different initial conditions, and looking up the closest match on descent.
Check out LQR trees from Rus Tedrake’s lab, and watch the underactuated robotics series for more ideas.
If you wanna get fancy, I’d suggest PPO+dynamics randomization to get a controller that works well on any descent
Never thought i would understand the physics of rocket dynamics but you did an excellent job explaining everything
Moving the accelerometers up to the CM should help reduce the impact of the wiggle, and if you leave the battery back at the motor mount the CM shouldn't shift too much.
Great progress, word to the wise softmounting your imu/gyro board will change your life!
look for rubber gummies or anti vibration standoffs used for flight controllers! Another material is alpha gel!
Adding these will allow you to tun your PID loop - good luck x
great vid.
Just had a thought (i'm sure easier theorized than executed) - can you redesign the throttle arms, such that when they are close, they redirect the thrust sideways in 4 (or at least 2) axis, or reversing the thrust, aiding with keeping the rocket in place. example of this can be seen in the Boeing 737 Thrust reversers.
Keeping the rocket in place? Sideways thrust would cancel itself out and not provide any additional horizontal stability.
@@clonkex if reversed (pushing down), sideways just enables zero thrust - though i agree with you that it seems (could not find too much info, any pilots here?) bucket thrust reversers don't truly REVERSE the thrust.
@@MI-wc6nk Ah I thought you were saying it would keep the rocket in place horizontally, but I see I misread your comment.
Came here to say just this.
Rather than trying to block the efflux, redirecting it with 'open-backed scoops' might allow deeper throttleability, and could add a method of vectoring the thrust in the terminal phase.
@@MI-wc6nk Yeah, bucket thrust reversers really just kill thrust and add drag, throttling up in REV mostly just makes noise.
Running a simulation that attempts to characterize the rocket in real time could be an option. Might need something with a bit more processing power to make that work though.
I have used this approach on many occasions. Accurate state estimation is really the only way to control such a dynamic system. However, there are so many parameters that it becomes computationally expensive quite quickly, especially for higher polling rates.
wow, that link is so cool, it’s like magic!
Yes
@@orbitalthrust1526 I posted this 3 hours before it was public
@@fullflowaerospace right? You are the guy from tiktok i think? 😅 Same profilpicture
@@orbitalthrust1526 yes
This dude actually does what people think Elon does.
Thanks for being open with your process. Love what ya do.
Add a Prox(imeter) Center to the bottom of your rocket. When the prox hits, the 4 axis (0-90-180-270) thrust cancelling defectors activate, (with the possibility of thrust vectoring for the last 1-5 secs). So if the initial burn w/weight did/didn't achieve the proper height with the payload; it then would then wouldn't matter (On Target, No. Landed, Yes.).
You are inspiring. Thank you for the way you engineer and think through these issues. I really appreciate this.
SCOUT! .. I am so happy you have returned to the task that first brought me to your channel ... Dont worry too much, you've got this 🙂
Perhaps your ceramic thrust reduction pincers should be cup shaped to redirect exhaust gasses slightly upward which would not only reduce upward force via downward thrust reduction, but could also reduce it further via the gasses redirected upward providing a downward force. This would increase the range of upward force control and also allow landing lock by fully closing to direct thrust upward once landing leg contact is detected.
We had the same thought. I scanned the comments to try to spot any duplicates, but there’s a lot here to sift through!
This is absolutely epic. You’ve come a long way
i love your channel. i've been following it for quite a while. i'm so glad you're not giving up. Greetings from Germany
Came to have a look after Marcus House gave you a shout out on his channel. So glad he did. Really looking forward to seeing up coming videos!
I'm always amazed whenever I look at your rockets,
In my ignorance I think that one of the problems of the rocket falling on landing is the landing charge lasts for a long time there would have to be the possibility of ejecting or turning off the charge as soon as it touches the ground. the second visible problem is the landing support that perhaps should be more supported above the middle of the rocket. I really admire your project.
just before I watch, the celebration and excitement I had when I saw you released a video is just "extreme"
I'm 1:10 in, but holy crap! I'm so glad to have seen the progress for as long as i have! What a brilliant flight! oscillation was definitely it saying it's happy as Nicholas has!!
Joe, great job. I have some questions and suggestions:
1) Your rocket is unstable by design. During ascent phase it uses TVC to stabilize it and you lose performance (max altitude). Every take-off is affected by that and it is an additional variable which is not covered by your simulations. Why don't you make the rocket stable at ascent? Just add fins, move center of gravity and center of pressure, keep TVC switched off for take-off and turn it on for landing only. Maybe this will make your flights more predictable and repeatable. You have already proved that you can stabilize unstable rocket at ascent. You do not have to prove it every time. What you struggle with is the landing (as I understand from all you movies on YT, I spent a lot of time watching and enjoying them ;-) ). Remove the uncertainty that affects landing phase.
2) You use reaction wheel to reduce tendency of the rocket to rotate along its axis. It is heavy. Have you compared the weight of the reaction wheel system and for example actuators to fins that would rotate all of them in one direction (clockwise or counter-clockwise)? Would it be lighter even if you have to include fins (see point (1) above)? Just a trade-off study.
3) The landing legs are deployed just before landing. As I understand each leg has 2 bars. Is the upper bar attached to the rocket tube below or above the center of gravity (CG) of the landing rocket (all fuel of the landing motor used)? If it is below then maybe moving it (much) above CG would help to improve landing?
4) I would propose the modification of the landing procedure and hardware. Assume that the rocket is approaching the ground and the motor is still working. If one of the legs touches the ground (or the rocket is really close to the ground) then the direction of thrust should be reversed as in thrust reverser of jet engine on an aircraft. At this moment the thrust would push the rocket to the ground and keep it there as long as the motor works (from your movies it might be 1-2 sec). If the motor stops working before that then nothing happens. Thus it would require modification of the hardware: attachment of contact sensors to the legs, adding clamp shells (four) that will close completely (no leaks) and that would move with TVC. The sensors would trigger closing of the clamp shells. The landing procedure and the software controlling TVC would have to be modified as well.
5) I am not sure if you noticed how quality of your movies improved over the time. You are doing really good work here!
Maybe one more thing ... the landing legs ... they are very elastic and make the rocket bounce at touch-down. You either need:
a) a damper added to the legs or
b) a part that will deform permanently at landing and does not cause return to the original shape (=plastic deformation) - this approach was used during Apollo program in LM legs
Fins only work at high speed. If Q is low the rocket is still inherently unstable. That’s why model rockets and military fin stabilized rockets are launched on rails or in tubes that stabilize until its moving fast enough.
I always love seeing one of your videos show up on my subscribtions feed. You WILL nail this, of that, I''m confident. Cheers!
My god that's a beautiful bit of engineering from beginning to end, even if there it's not a perfectly outcome. This is the scientific method in practice and how to find solutions to problems via rigorous data collection and honest analysis of the system and decisions made to get it there. Our governments could learn from this (in no small way!). Brilliant stuff, Joe.
The work you do, really impresses me and for me you are doing what i can only dream of.
If you have two or more motors that rotate into opposition and then finally upside down~ish to be a near instant down force. Some leg wiskers can start the engine flip. The legs can have a progressively stiffer "crush" function.
This is probably my favorite project going on on YT by far. Scammer Paybacks or Mark Robers big videos are cool and all, but this is something different. Don't lose hope, I think the hardware is pretty much done. With a very good worked out brain this thing will go places, high places! Take your time to give the problems the care they need and we'll see a beautiful touchdown with the rocket standing straight up! Cheers!
On landing, add another constraint to override the profile and cutoff as much thrust as possible if the landing legs hit the ground. One more sensor to detect the legs impacting ground or maybe acceleration sensor can detect the landing.
A few suggestions here:
1. Use a function which takes in the current velocity of the rocket, the vertical and horizontal distance from the landing zone and the burn time left to calculate the appropriate throttle value.
Amazing! You should consider a bang-bang baseline control with state matching blending into a PID. I do this for an ultra fast steering system that has lots of viscous and dry friction damping. I think you already know that your gimbal simulation needs full multi-body dynamics.
1) the wiggle cost you apogee, but it looks so cool!
2) There’s plenty brainy folks about, but your you are real good at presenting the engineering design thinking - I hope you make it to space, but I think you may have a reasonable chance for the next prize to be a position as a professor somewhere!
3) looking forward to the next one!!
Awesome dude! Every iteration brings new improvements and new learning. Great work Joe.
Excellent video. Great to see you back in good form 🙂
That gimble was working some major OT!! Very awesome
I just wana say I really dig what ya got going on with this rocket.
Basically a rocket scientist: "Think about Newton's third law: for every object... Wait... how did this work?"
had me weak
Just found this video, stick with it your onto great things. All the best for a great future.
On guidance control a frequency of 400 Hertz is used, that is the time from angular transducer sensing delta to control servo reacting in minute increments to stabilize trajectory path.
Awesome video, Joe!
I just wanted to share some ideas. You said your ceramic motor modulators can only bring down the force to 20%, which I don't think is an issue. It seems you have good control of getting the rocket close to the ground stably, but you need more precision in the last couple meters. I feel like adding a small distance sensor for this little portion would be very helpful for this. You can get a small, light one to get precise measurements for the last bit of the landing. I think it is also important to have your engine be able to exert the force around the weight of the rocket around landing. This will bring the rocket's velocity to zero. Then with your ceramic modulators and your distance sensors, you can close the distance to the ground with active control, instead of a more timing/guessing method.
In short, I feel like the key for the landing is getting distance measurements from the ground (via the distance sensor), and the engine having a profile where it can exert a force near the weight of the rocket, to bring the rocket to the ground with close to zero velocity. Once you're on the ground, that 20% shouldn't matter so much, so long as you are doing less force than the weight of the rocket, you won't be exerting much vertical force.
Hope this helps!
so i had an idea yesterday, inject some kind of extinguishing gas/liquid/powder into the combustion chamber to give solid rockets throttling capability. extinguishes the flame if you do too much but im sure the right balance and correct element youd be able to just choke the combustion and be able to raise/lower throttle via the amount of stuff you pump in/speed/temp
What an epic project. Incredible challenge. I can't imagine anyone else doing something similar. Great film. Mahalo for sharing! 🙂🐒👍
You always impress me with you persistence! Keep it up!
I feel like this is a sign for you to move to a liquid fueled rocket, massively increasing the complexity, while also increasing the scalability (for being able to land under various loads) and how high you can go.
Top fuel jet boats will use a neutral bucket to redirect water 90 degrees to each side that will negate any forward thrust while staging. You might be able to use that instead of outright trying to block the thrust.
This is the first time I've tripped over one of your videos, and I'm really impressed with what you have accomplished.
I assume you are familiar with the concept of PID loops, but if you aren't you definitely should look them up. PID = Proportional, Integral, Differential. It is a general control strategy applied to continuous industrial processes, and your rocket is a continuous process when it is operating. The general idea is to use a PID control algorithm in a feedback loop, such as your gimbal control. You tune the PID parameters for the general way the process is observed to operate, but there is generally enough wiggle room in the control algorithm to account for things going to the limits (or even beyond) and getting back in control. In this case there wasn't near enough damping in the motor control, resulting in it slamming to one side, the control noticing that the rocket is now leaning to the opposite side as at first, and then slamming back. A longer integration time would help with that.
On the landing burn, I think your right that your current control strategy isn't optimal. I've never done what you are doing, so I'm just thinking out loud here. I think that the viewpoint I'd take is that you have an unpowered object of some approximately known mass, descending at a measurable speed and acceleration (which is approximately g less some empirical wind resistance), and which needs to stop at some determinate point. If your altitude measurement is good enough you should know the distance to the landing altitude.
Then the goal is to apply some integral force F over some time T such that V=0 at the desired altitude. You should be able to calculate the ignition start time from those parameters, and be able to resulting change in vertical acceleration and speed based on the force. This algorithm should be independent of total time of flight and of peak altitude reached, assuming that the altitude is high enough that you can completely burn the descent stage by impact time. I guess your descent rocket force is approximately a constant value and is then reduced by your control pinchers. Since F=MA and the F is known for the descent rocket and M is known from initially weighing the rocket less the ascent tube, you can calculate a constant A to result in V=0. Then the question is to calculate the altitude to start the burn, which is done by (if I recall my long-ago math correctly) differentiating MA to get a known distance with a known F.
Well, I hope some of that made some sort of sense, and might be useful to you.
Always look forward to these videos.
Nice one Joe - great development so far
Good to see your still at it excellent work really liking your stuff things
Joe, I just hit subscribe and like. You have got a great idea for a learning video about space. Lovely how you modulate engine thrust by diverting the plume. Just wow. DIRECTIONAL control by gimbal. Fabulous.
if i had to guess, and i never worked in something like this(disclaimer), i would try to corelate thrust and mass flow rate with altitude. that would be my landing system. I think mass flow rate is the key here. It should also be taken in consideration when you are estimating your center of mass and how much it drifts when you gimbal the rocket. For this i would have separate algorithms because of the discontinuity in the mass curve, when you eject the firts engine. Again, i'm "thinking out loud" here. I'm actually graduating in eletrical engineering so...
Just by looking at this video I know this will be epic
Amazing progress so far!
The way I would approach it is to calculate the total change in velocity your landing impulse can obtain, and do a running calculation of how much thrust you need to land perfectly. When the two line up appropriately (With timing and tolerance of the engine specs, etc), you fire the landing impulse.
Start with this. Take a random set of drop altitudes and figure your curves as you mentioned, finding the ideal time to start the ignition in each case. Plot the drop altitude vs ideal time to start and see if you can find a formula, there should be a clear one. With that you can know when to start. The idea is to have a well generated curve that is based on the actual conditions, not the expected ones.
With this approach, the goal of the ascent is to go as straight up as possible, because it is very difficult to recover if the vehicle isn't stable. Still, I'm sure you'll get this! Keep it up!
To prevent bounce, consider adding a crush area to the landing legs, like on the lunar landing module.
I have loved watching this develope over the years. I can't to see your next flight
For the vectoring oscilation. You can create situations where the negative short term relation between control and observation (non minimum phase system) "causes" the instability. Your rocket should behave simular to a segway like system, but just with different parameters . A lot is writen about it so I recomend you look at ways they deal with possition control. Can't remember if there is much usefull to find about it regarding your situation though.
You can also change the system so you don't control the rocket but the rocket-motor system combined. But this means you have to reconstruct that systems state from the rocket measurements, and how moving the motor influences the system.
You could study the apogee perturbation problem by using an Extended Kalman Filter (dynamic model of descent portion of flight assuming apogee is known) by making a Monte Carlo simulation for the different initial conditions to quantify state covariance of that portion of the model. I'm thinking the EKF could even produce the PID set points once you know how much "noise" the EKF has to take into consideration.
I would even estimate apogee with an EKF.
To fix the bounce issue on landing; try using sharp pegs that are angled towards the centre instead of flat feet, these should dig / hook into the ground on landing with no need for a landing pad. Good luck!
You should look at the internal model principle if you want the height PID to track the set-point without any error. You could try to develop a linear model predictive controller for the altitude with the constraints that the final altitude and velocity in z direction are zero.
Some interesting physics on this: if you assume a constant deceleration over a known time (burn time of the second engine), that implies a ratio between the velocity and altitude at the beginning of the deceleration, regardless of the deceleration value.
I suspect that starting the engine at that sweet spot and choosing a flight profile such that the required deceleration is in the middle of the control range would minimize the required control effort
IMO, I'd prioritize stability in flight by moving the CG as far forward. Then there should be less lateral movement for the legs to deal with on landing.
Your rockets does not look like plastic anymore! Awesome!
I’ve been SOO hyped for your uploads I’m so excited
Good work man. You have come a long way.
Came from Marcus House, and am very impressed with your approach
My thought is to shift 'the "X" marks the spot' for landing to a "is the craft upright and not precessing" requirement. Unless you are tracking winds onboard the system, where you 'want to land' doesn't matter as much as will it still be upright when the smoke clears.
During the wiggle it also appears to be causing the fuselage to oscillate on ascent. Either fixing the wiggle or verifying that the fuselage oscillation potential is as low as possible should also help.
12:00 Not the only thing in this video that looks well built!
Landing rockets can be coded and simulated in simplerockets2, well I'm not having had hands on real rockets since about 5 years but I find it very helpfull
Many people may not see it to my extent but even tho scout failed its mission i find it a masterpiece like the way it stabelized itself using a not so diy but still diy system then cut its thruster and reactivate it along with the landing legs. Masterpiece.