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.
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*
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.
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. ua-cam.com/video/Oj1E7o7J3qc/v-deo.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.
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!
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
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 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!
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.
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.
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
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
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.
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.
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.
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.
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.
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..!!!
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
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.
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!
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.
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.
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.
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.
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.
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.
To tame that shimmy, simply counterbalance it. When the actuator pulls the motor one way, have it move something else the other way. That way this unwanted behavior is counteracted in its own section, instead of leaking its effect to the rest of the structure. An example of a machine that uses this every day is a piston engine crankshaft, with the counterweights built into it. Where possible, they try to get the pistons to counterbalance eachother, but some cylinder counts and arrangements require more brute force. You may see some benefit in response time and weight if you design a motor pivot gimbal frame that tilts the motor from its middle, and counter tilts part of the mechanism that performs this movement.
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.
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.
On some jet engines they reverse the thrust by swinging cups, for want of a better word, but you could use your pincer arms to swing in to half cups to redirect the force upward in effect planting your rocket down in the last second or so. Just a thought 👍🇬🇧
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.
Servo-actuated tabs may actually increase thrust cause they increase chamber pressure which in turn leads to higher burn rate of the fuel (see Arrhenius equation) and thus to increase in mass flow rate and thrust.
Think in a camera diaphragm as a way to control the engine, as it clises it dissipates the energy to the sides and not downwards . As so, you can have your engine burning longer and still land, and not worry to it to finish while in the air, maibe it will end the need of tilting the rocket to burn excess fuel
an idea for a lightweight shockabsorber: thin aluminium tubes that slide over one another, with heavy grease on the sliding surfaces. If you get a spring assortment, you can find a light spring that fits in the large tube, to keep the whole thing extended until the rocket settles down. I built landing gear for small model aircraft that way. Has quite a nice damping effect, eliminates bouncing and can be integrated into your carbon rod construction for the landing legs. Might even work with carbon tubes sliding in one another.
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
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.
Quadcopters tend to do this bounce when they hit the ground because of the I term in the PID controller, but this seems like you can't shut the thruster off. I've found either way the best thing to do is just kill the motors right before first touchdown, or the exact moment of, after really slowing it down towards the ground. That way the "bounce" is negated by there being no way to make thrust
How about putting the gyro and accelerometer on a separate little pc board, put it in a little foam and move it up and away from the gimble mount. It would communicate back to AVA via I2C or SPI. That might smooth out the noise and vibration. You might also want to slow down the PID response time that controls the gimble.
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!!
A servo actuated 'flap' is activated at 1st contact with ground a 'flap' slides out and completely inhibits the remaining thrust of the still burning engine, allowing it to settle.
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.
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.
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...
Because you have a fixed burn time / thrust decent engine, use a Hamilton jet type vectoring, to throttle and then reverse thrust on ground contact of one of the legs that way you are using the remaining thrust time to stabilize the landed rocket. Also your 2 throttle arms will induce thrust perpendicular to there axis if you are using a gimble on the decent engine, as well dump it and go with a 3 leg thrust vectoring/reversing. I would suggest graphite it is cheap light, heat, conductive resistant , strong, easy to machine although messy. This reduce the reliance on rocket motor burn out timing.
Have you considered thrust augmentation/Venturi/Dyson fan or whatever you want to call the effect. A solid rocket firing into a tube gives more thrust than one in open air. Sooooo, Theoretically opening and closing the intake sleeve between the rocket and the thrust tube gives you throttleable solid fuel motor.
If you go above the expected height you should be able to correct as the rocket will only fall so fast, this means that you should be able to simply generate the landing lines for a lower then actually expected height and use the computer to either compensate for the speed differences or attempt to force the rocket back onto the line with the space thrust you should have you should be able to land just fine from anything higher then your expected height, as long as you have the thrust to get back on that line if you are falling at terminal velocity.
so far everything i thought of, you also have. but, a complicated fix full of failure points, your landing motor throttle shut off clamp. add a couple of blades to it so it can close completely. then, add a second set that can snap shut lock those first ones in place while adding more direction to the flow, up. or at least at an angle towards the up direction. and time it so when the rocket touches the ground, the first clamp closes, then triggers the second set to close and lock it in place, directing the flow in an upward direction, essentially holding the rock to the ground until the motor dies. it will work, but, complex engineering is needed.
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!
A long range ultrasonic sensor, if such a lightweight version exists, can take your altitude and adjust your landing algorithm in real time. Then it won't matter what your eventual altitude. Think dynamically instead of linearly in terms of your landing algorithm.
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!!
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
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.
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?
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.
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
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.
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. ua-cam.com/video/Oj1E7o7J3qc/v-deo.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.
The fact that youre doing things this advanced this young is astonishing. You seem like you will be successful
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
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.
Have used Onshape for years at work and it's great. 👍👍
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!
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!!!
Onshape is awesome, cool to see you getting more sponsers
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
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.
Your Passion for this Project is inspiring!
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
Never thought i would understand the physics of rocket dynamics but you did an excellent job explaining everything
I've followed you for years now, you are amazing and so inspiring. keep the awesome work and education coming !
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!
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.
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!
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.
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
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
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.
We had the same thought. I scanned the comments to try to spot any duplicates, but there’s a lot here to sift through!
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.
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.
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.
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.
This dude actually does what people think Elon does.
Thanks for being open with your process. Love what ya do.
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..!!!
You are so close! This is super impressive. Love your videos. Keep it up!
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 🙂
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
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!!
So close!! I am incredibly impressed by how much work you've put into this and how good of results you're getting.
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'm always amazed whenever I look at your rockets,
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!
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.
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.
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.
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 absolutely epic. You’ve come a long way
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
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.
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!
The absolutely incredible things you can do with a music degree:
You are inspiring. Thank you for the way you engineer and think through these issues. I really appreciate this.
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.
To tame that shimmy, simply counterbalance it. When the actuator pulls the motor one way, have it move something else the other way. That way this unwanted behavior is counteracted in its own section, instead of leaking its effect to the rest of the structure. An example of a machine that uses this every day is a piston engine crankshaft, with the counterweights built into it. Where possible, they try to get the pistons to counterbalance eachother, but some cylinder counts and arrangements require more brute force.
You may see some benefit in response time and weight if you design a motor pivot gimbal frame that tilts the motor from its middle, and counter tilts part of the mechanism that performs this movement.
To prevent bounce, consider adding a crush area to the landing legs, like on the lunar landing module.
just before I watch, the celebration and excitement I had when I saw you released a video is just "extreme"
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.
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.
On some jet engines they reverse the thrust by swinging cups, for want of a better word, but you could use your pincer arms to swing in to half cups to redirect the force upward in effect planting your rocket down in the last second or so. Just a thought 👍🇬🇧
Landing solid rocket in 2022. Awesome. Good job.
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.
Servo-actuated tabs may actually increase thrust cause they increase chamber pressure which in turn leads to higher burn rate of the fuel (see Arrhenius equation) and thus to increase in mass flow rate and thrust.
The work you do, really impresses me and for me you are doing what i can only dream of.
Think in a camera diaphragm as a way to control the engine, as it clises it dissipates the energy to the sides and not downwards . As so, you can have your engine burning longer and still land, and not worry to it to finish while in the air, maibe it will end the need of tilting the rocket to burn excess fuel
an idea for a lightweight shockabsorber:
thin aluminium tubes that slide over one another, with heavy grease on the sliding surfaces. If you get a spring assortment, you can find a light spring that fits in the large tube, to keep the whole thing extended until the rocket settles down.
I built landing gear for small model aircraft that way. Has quite a nice damping effect, eliminates bouncing and can be integrated into your carbon rod construction for the landing legs. Might even work with carbon tubes sliding in one another.
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
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.
Your rockets does not look like plastic anymore! Awesome!
Try a welding blanket on your landing pad. Slippery, soft fiberglass, that won't burn and will be reusable.
I honestly feel this is the year. I think we might get a landing which then tips over then Joe will nail it
Quadcopters tend to do this bounce when they hit the ground because of the I term in the PID controller, but this seems like you can't shut the thruster off. I've found either way the best thing to do is just kill the motors right before first touchdown, or the exact moment of, after really slowing it down towards the ground. That way the "bounce" is negated by there being no way to make thrust
I just wana say I really dig what ya got going on with this rocket.
How about putting the gyro and accelerometer on a separate little pc board, put it in a little foam and move it up and away from the gimble mount. It would communicate back to AVA via I2C or SPI. That might smooth out the noise and vibration. You might also want to slow down the PID response time that controls the gimble.
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!!
Just by looking at this video I know this will be epic
A servo actuated 'flap' is activated at 1st contact with ground a 'flap' slides out and completely inhibits the remaining thrust of the still burning engine, allowing it to settle.
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
Just found this video, stick with it your onto great things. All the best for a great future.
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.
Always look forward to these videos.
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.
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...
What an epic project. Incredible challenge. I can't imagine anyone else doing something similar. Great film. Mahalo for sharing! 🙂🐒👍
Because you have a fixed burn time / thrust decent engine, use a Hamilton jet type vectoring, to throttle and then reverse thrust on ground contact of one of the legs that way you are using the remaining thrust time to stabilize the landed rocket. Also your 2 throttle arms will induce thrust perpendicular to there axis if you are using a gimble on the decent engine, as well dump it and go with a 3 leg thrust vectoring/reversing. I would suggest graphite it is cheap light, heat, conductive resistant , strong, easy to machine although messy. This reduce the reliance on rocket motor burn out timing.
Include a distance sensor measuring distance to ground to adjust throttling curve for breaking on way down.
You are f*cking genius dude. Amazing work
That gimble was working some major OT!! Very awesome
Have you considered thrust augmentation/Venturi/Dyson fan or whatever you want to call the effect.
A solid rocket firing into a tube gives more thrust than one in open air.
Sooooo,
Theoretically opening and closing the intake sleeve between the rocket and the thrust tube gives you throttleable solid fuel motor.
Excellent video. Great to see you back in good form 🙂
If you go above the expected height you should be able to correct as the rocket will only fall so fast, this means that you should be able to simply generate the landing lines for a lower then actually expected height and use the computer to either compensate for the speed differences or attempt to force the rocket back onto the line with the space thrust you should have you should be able to land just fine from anything higher then your expected height, as long as you have the thrust to get back on that line if you are falling at terminal velocity.
so far everything i thought of, you also have. but, a complicated fix full of failure points, your landing motor throttle shut off clamp. add a couple of blades to it so it can close completely. then, add a second set that can snap shut lock those first ones in place while adding more direction to the flow, up. or at least at an angle towards the up direction. and time it so when the rocket touches the ground, the first clamp closes, then triggers the second set to close and lock it in place, directing the flow in an upward direction, essentially holding the rock to the ground until the motor dies.
it will work, but, complex engineering is needed.
Nice one Joe - great development so far
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!
A long range ultrasonic sensor, if such a lightweight version exists, can take your altitude and adjust your landing algorithm in real time. Then it won't matter what your eventual altitude. Think dynamically instead of linearly in terms of your landing algorithm.
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!!