Scout E - Engineering Cut

howdy i'm joe barnard and this is the engineering cut for scout e the rocket that you're seeing on the screen right now what is an engineering cut that's a great question an engineering cut is a term that i made up right now and it basically stands for all of the footage that i don't know where to put and all of the knowledge that i don't know where to put about this project the goal of this rocket was to launch and land propulsively and while this one didn't work and we're working on a new version of it i need somewhere to put all of the knowledge and like footage that i got through this project so the engineering cut is how we're gonna do that because there's so much of it and because i have a finite amount of time we're gonna make this a lower quality video where i ramble quite a bit and hopefully it just serves as a repository if you're doing something similar or even a project that just uses one or two adjacent like concepts from this i hope you find this helpful and if nothing else maybe you'll be able to skip around and find some parts that you're interested in i'm not sure of the ideal order to do this so we'll start with the cad and then we'll just go from there so once again the goal isn't to create some huge well thought out video the goal is to dump all of this footage at once we're gonna separate it into categories and we're gonna start with cad cad stands for computer aided design and this is the cad model of the scout rocket so what we're doing here is trying to represent all of the things we need to build to put this together it's very simple so we'll just walk through it quickly at the base of the vehicle we modeled the launch clamps i don't know why one of them is sideways i can't be bothered to fix it at this point but we model the launch clamp so that we can know the size of the base that we want for the landing legs inside you'll be able to see the thrust vector control mount and we will talk a little bit about that later we've got the landing legs right here and actually this is look at this logo here this is a good opportunity to bring up something that i learned through the project which is that you can spend as long as you want in cad and it will still fly the same like there is some diminishing return point where it's just not worth modeling things more and more so you'll notice that we've got these nicely modeled carbon fiber struts we've got got the logo emphasized none of this stuff makes any difference it makes it look cool for sure but we probably spent too much time like making this look nice it doesn't need to look this fancy so we have the dual motor mount inside there again we'll talk about that later and right above we have ava let me see if i can get around front here so um you'll see that ava when the dual motor mount like when both motors are in here it was actually pretty close to these um we put ava as low as we possibly can in the airframe because we want to keep our center of mass as low as possible when the vehicle touches down we want that center of mass to be really low so that we don't tip over or we try to prevent it so ava is the flight computer and it's mounted right here one of the things that we could do is just turn off the airframe right here so we can see the internal components without the external ones um ava has a reaction wheel that is situated on top we've got a little dc motor with a gear so we drive the wheel this way we have a little motor controller that fits in there as well and we'll show some footage of that later in this video of the actual build itself above ava the next thing that we hit that is at least modeled in cad is the parachute ejection system we'll of course talk about that and of course this is in the airframe as well so that's this is around where it is in the second black stripe the one that's a little above the first so um the parachute ejection system never got used in flight that's the thing that we're removing on the next version of these vehicles the parachutes are helpful for if you are really not sure if the motor is going to light and we don't have that the igniters are very reliable and the other reason that you would want this is if you're not sure if you're going to reorient successfully to upright when it's time to light that second motor this was the thing that i was most concerned about with the first flight and both flights demonstrated that we can easily get back to upright with the size of the fins that we have on top of the vehicle even though the vehicle is moving relatively slow when we come down we can stabilize effectively so we don't need to use those abort chutes ava runs a bunch of checks right before it lights the motor on attitude and predicted attitude into the future to make sure that we are safe to light that motor so we never ended up needing this shoot deployment compartment and we'll talk about that a little bit later above here the next major thing is the fins that deploy on the vehicle this is a this is a really cool part i'm pretty proud of it so why don't we go ahead and turn off the airframe here so the fins are stowed away inside the rocket they're actually i think we have a little bit of an uh interference fit here so they're not modeled perfectly obviously and the way that these deploy if i remove the nose cone right here they deploy with a servo that is up in the nose cone i even this is another example of like over modeling in cad we didn't need to model the push rod this exactly um i don't know why i chose to do this but like this was wasted time i probably spent two hours on this when i could have just built it so we have a servo in here that pushes down a plate this is not modeled quite well enough right here but the servo pushes down the plate it pushes the fins out and that's how they get out and then it's all enclosed inside the nose cone if i can find it here there we go that's all enclosed inside the nose cone so that's a quick walkthrough of the cad of scout but of course cad is not exactly where you want to start cad is not where you start your design this is i think a common misconception among people who are getting started in engineering you don't start with cad you start on a whiteboard with like gross designs that don't make any sense you have to work your design out a little bit first before you start in the cad i mean i use the term have to you don't have to do anything but i recommend starting out with a much more rough design on a pen paper that's like easy to modify and then when you're ready to like start locking in things you could even create a cardboard model first then you can get into cad where your decisions are just a little bit more permanent so in that same vein the first thing that i actually did to design this vehicle wasn't designed the physical hardware at all it was to design the flight profile i want to know like what we need this vehicle to do and then we can design around that one of the first simulations i made was in matlab using simulink because it was a tool that i was familiar with we put two f-15 estes rocket motors into the simulation with an estimated mass we tried to track the mass through the flight and just model what would this look like if we fired two of these at just about the right time this is a great starting point we need to know that it just works in a theoretical sense even if we have to hit the timing really tight or we have to get exactly the right altitude but of course with scout e one of the goals was to get a little bit of throttle control and i didn't want to do any plume impingement or anything that interacted directly with the flame so i had this idea that we could pitch back and forth because you don't actually have to control the thrust you just have to control how much thrust is spent vertically in the downward direction so the idea behind scout e is that we would do a sort of sine wave shaped maneuver when the vehicle comes down like this we pitch to the right and then we pitch to the left to bleed off whatever velocity we've accumulated and by the time we pitch to the left we've bled off whatever we've had to bled bleed off and by that time we hit the ground the reason that i thought this would work and the reason that i still think it can work if you want to build something like this is that the main variable i have observed with the estes f15 rocket motor is not necessarily the thrust i'll toss some plots up on the screen but the thrust between thrust curves is very consistent i have fired a lot of these motors and they're pretty reliable the thing that is not reliable about them and it's not really their fault it's just inherently a dynamic thing it's the time between when you fire the igniter and when the motor reaches the peak thrust both of those events are extremely measurable and my idea in theory without a simulation was that we could measure that time between when we fired the rocket motor or when we commanded the fire and when the peak thrust occurred and by measuring that time and measuring you know how far off of the mean or how far off of the average we were we could determine the divert maneuver that was needed to get us down to the ground safely so after running these matlab and simulink simulations i decided to try and model what a controller would look like for this when i say controller what i'm talking about is a bit of math that looks at the state of the system and then tries to give the system input to stabilize it these are like you know high level terms so let's just talk about it in the real practical terms when i say controller i mean a piece of math that is going to look at our altitude velocity the peak thrust time and then determine how hard we need to pitch over one way or another to bleed off our velocity or bleed off our altitude on the way down i did this in the arduino ide and i started running simulations literally using an arduino uno you can run a pretty decent fidelity flight simulation on an arduino uno i know sometimes i use like fancy tools and fancy software on this channel but you can do anything if you just like model the physics yourself and even if you want super high fidelity stuff it's just going to take a few more clock cycles the arduino uno doesn't have to real run this stuff in real time so that's the way that i started to figure out that this controller could work is i modeled the physics of what i wanted to happen in an again an arduino uno the most basic microcontroller you can get and i had it run like a monte carlo simulation to see could we close this problem so this is one of the final simulations we ended up with and we'll just walk through a little bit of it here to see how it works and i'm walking through this for the first time in almost like 10 months so i'm probably going to miss some stuff here we have a bunch of stuff up at the top of the simulation that lets us tune what we want for starting criteria so simulation altitude velocity acceleration force thrust all of those are going to start at zero we then have different coefficients to represent the drag and i think the way that we're doing this is very rough i think we're just multiplying like our velocity by the drag coefficient and then creating some drag off of that but you have to model the drag it is moving pretty slow but it is a very non-negligible part of this so we model our drag coefficients and the way that i did this is i looked at past echo data i can put some of it on the screen but we looked at all of the past flights of echo which has a comparable cross-section to scout in terms of just the bottom of the vehicle so we look at how that vehicle slows down as it falls from the drone and then we basically use you know real-life cfd real-life data to determine what our estimated drag coefficients were on the way down and then for drag coefficients on the way up i don't know i just kind of guessed uh no that's not true never mind i just found the uh footage and data from that we used this flight shown on screen for uh one of the scout d vehicles i think all these have a similar cross section this one's a little bit wider but we used this flight in particular with the f15 to get a sense through the acceleration data of what drag would look like on the way up then we have our simulation time step it looks like we're running this at 50 hertz time step we have a simulation length which can i think be cut short if we go below like negative 2 meters or something simulation mass which is the starting mass of the vehicle and then that gets changed that's a dynamic variable we've got a bunch of other things in here we define gravity and pi um you know a couple more things here we have oh man i had a lot of trouble doing this so i modeled the f15 as a an array of um values like a 35 we can look at it here i modeled the f-15 thrust curve as a 36 element array so one sample every 100 milliseconds and i actually had to do this a few different times i ended up modeling the f-15 thrust curve as a polynomial or like two or three discrete polynomials that switched at different time steps and i did this by going into google sheets loading in a bunch of thrust curves taking the average finding a line of best fit for different sections of the motor and that way we didn't have to have some discrete array we could have a much more smooth signal that we could inject some noise into and it was a little bit closer to like representative of what we needed from the thrust curve this is like we're already way overkill i mean none of this project makes sense retro burns start time i do not know what this is i think this was an old variable before we did altitude detection so this is probably just depreciated we have a bunch of startup stuff or we write out like what startup happens oh and i totally forgot about this um all of the simulation happens in the setup function we never like use the loop function of this so let's see we do some initialization stuff here while sim done is zero so this is basically our whole simulation loop we advance the time step of the simulation we have a polynomial that represents what our burn altitude should be this is kind of interesting so the way that i have for a long time determines the ideal altitude to light the landing motor is i've run a monte carlo simulation usually in matlab simulink but it can be in whatever you want i run a monty color monte carlo simulation i evaluate the apogee and then the apogee determines what the ideal burn altitude is because the apogee is just a representation of like our potential energy in the system so i i use the apogee i put that into what looks like a first or second i think it's just a first order polynomial and then we can get a decent for like you know a small range of apgs because we're only going to about 30 meters we can get a decent estimate of like what our burn altitude should be okay so that's what's going on here so when we say float burn out equals sim melts out times 0.649 plus 3 that's our first order polynomial so when we simulate if the you know ascent is a little bit more powerful or less powerful the simulation is trying to anticipate that based on the simulation results here it looks like we've got some stuff about uh burning the landing motor honestly this is kind of messy here i don't actually know like what what does the term error boy represent i think that's just like random noise injected into the motor we also have two if statements about if sim velocity is less than zero if some altitude is less than burn altitude if retro init arrow error burn start time you send i man this is this is wild um some of this stuff is just like haphazardly put together uh sim thrust this one's easy f15 thrust curve is a function that if i look it up here f15 if we look it up here um this is basically the function that i did okay so it looks like what's going on here is within the simulation i'm trying to randomly select a thrust curve for the motor oh this is weird i guess it works but this is weird okay so we actually have three different functions that represent different thrusters we have f15 tcl tcm and then we probably have a tch somewhere which is like low medium high so here is where we use these polynomials these are the thrust curves and how they get represented here so tcm is like a medium thrust curve we have the input of time within the thrust curve and then we represent it with like you know between this time and this time return zero zero newtons between this time and this time the polynomial that represents that area of the curve best is this we then you know have other polynomials this is like a second order or third order or whatever and so we have different polynomials that represent different thrust curves and then this is this is the old way that i tried to do it which which is the 36 element array and this returned like weirder results like they just weren't quite as smooth and weren't quite as accurate okay so that's the thrust curve if simulation altitude is greater than 20 meters thrust is zero sim mass okay so this is us representing the ejection of the ascent motor if a retro init one this is when we start the thrust curve on the way down which is we run another f-15 which is going to again randomize which f-15 we're running so we're like trying to live inject different f-15 thrust curves in here and this is why it's great to run monte carlo it looks like we also log our burnout altitude and burnout velocity so this is if we don't touch the ground how fast and how high are we burning out on that landing burn sim bleed percent oh okay so this is a function that protects us because we're doing an a cost function which is like gonna freak out if we feed it a zero um so then this is all the math that calculates our simulation bleed percent i i'm like probably not going to be able to explain this i'll scroll through it but i don't know that i can even explain my odin code at this point which is the side effect of waiting this long doing something like this so um we have our target angle when we set a bleed percent oh gosh i think when we say the bleed is let's say like 11 what we're trying to do is get the cosine throttle at the peak of the divert does any like is anyone following along with this like in a sine way you have two sine wave you have two peaks and at the peak there is some like maximum cosine throttle that you have and i think when we calculate some percent that we want to bleed off i think that's how we're targeting it so like we're not actually looking at the area under the curve of the sine wave in terms of like in terms of like total impulse reduction we're just looking at the peak percent which is it's fine i don't know man they're model rockets okay and then we limit the angle to 35 degrees which was sort of a gut check of like if we have to pitch more than 35 degrees something is already probably wrong and i do think this was driven a little bit by one of the early matlab simulations where i assumed that i could get a maximum actuation range of like 8 degrees in the thrust vector control mount at 8 degrees translated into us being able to safely hit a 35 degree peak sine wave but after a certain point you just don't have the angular acceleration you need so i think that is how we arrived at the 35 degree limit the sim angle the sim divert angle degrees divert mult sim time retroburn start time simply to i can't even understand this anymore i think if i spend a little bit more time i could but we have lots of video to cover here so i'll just keep scrolling through um oh this is us calculating our thrust downward which is basically this is the line where we cosine throttle find true downward force so this is not perfect because we are only finding the downward force um for a little bit of the sine wave and then i think we stop it at some point but basically the simulation gets us close enough that it's like will this work it's basically like are we within 10 of where we want to be that's what the point of the simulation is so you whip up something quick and dirty and it's like you know is my gut check telling me that this is going to work if sim velocity is greater than zero then the sim drag force is the ascent drag coefficient if the sim velocity is less than zero we have the descent drag coefficient this is just you know converting force acceleration velocity altitude if we're less than zero then we force to zero on velocity on altitude if we're less than zero altitude then we force this is basically simulating hitting the ground it literally has it in the comment i should just read my own comments um record maximum value so this is apogee stuff like that there's a delay zero which should ideally do just nothing here but if you wanted to run this a little bit slower and then like live print out your values to watch them happen in real time i think that's what the delay was for and then finally at the end of each simulation um we print out our statistics which is like the maximum altitude the burnout um the degrees we print out i don't know why i call it that we print out the error boy um and then we reset the simulation i think we may do this a few times and it looks like we're probably trying to average out statistics for like a monte carlo thing too resetting the sim resets all of our coefficients and all of our initial starting points and then i am not sure exactly what happens here average burnout oh okay yeah so when we hit the loop after running this let's say 10 times or something like that it looks like we just forever print out our averages so that is like the second step before we even hit the cad was me running this through again just an arduino uno you can do this on any device you could do it on a raspberry pi you could do it on the freaking super computer it doesn't matter these are basics basic physics simulations that will help you dial in um to know if what you're trying to build is gonna work i'm realizing i should probably show this working so on your screen is the serial monitor for arduino these are a couple examples of it working early on sometime in september 2020. you can tell that we're using the 36 element array for the thrust curve instead of the polynomial and then the only thing that we are varying here is the actual ignition time by about 1 or two hundred milliseconds in these first few examples you can see what happens when we vary those ignition times um you can see altitude velocity thrust curve and then a very small value of drag force landings are varying anywhere from a five to seven meter drop when the burnout happens all the way to hitting the ground and then hopping back up with these same parameters once we enable the throttle divert we get much better results much cleaner results you can see that the velocity nears zero once we touch down to the ground or it's a lot closer at least you can clearly see the sine wave this is just represented in degrees um you cannot see the effects that it has on the thrust curve but you can of course see that effect in the velocity which is the yellow line also worth noting we're not representing different thrust curves on the way up too so this is all normalized around what looks like a little bit more than a 30 meter apogee but this is just to show that the simulation does work um and this is how i verified that we could pursue this flight profile in the early development process for scout e so after this step one of the next things that i did is try and estimate vehicle values i've flown a lot of rockets that are roughly this size before so i have an estimate of like where our center of mass should be what our mass moment of inertia should be and i populated a spreadsheet with estimated values on that okay this is not exactly what i was talking about but i just found it and it'll do so this is basically us estimating all of the physical characteristics of the rocket you can see most of these things happened on october 17th i think maybe a few of them were before then but i believe these are all guesses on the vehicle because by october 17th we may have had some vehicle like put together and ready-ish to go but i don't think i really had the like the flight ready vehicle so in this spreadsheet we have the wet mass we have the dry mass and of course we have the moist mass the moist mass is the mass when the ascent motor has burned out actually what is this the moist mass must be when we eject the ascent motor so like we're still wet with the landing motor but we're dry of the ascent motor this is disgusting um this is how we named it so wet mass moist mass dry mass and then we also gave a certainty in terms of like are we going to be plus or minus this number this is way overkill again like this is great if you're building something that's going to space or like something that has really big i don't know something that's very high risk and incredibly complex and high risk whatever um this is overkill for what i'm building uh i mentioned it before in the vein of cad where it's like you should think about how much you're building in cad because some of it like some of the stuff you can just build right for this this is way overkill it's honestly more valuable with something that's this scale to just fly it more often and so last fall i was dealing with a lot of imposter syndrome about being a real engineer and figured i know how i'll combat that i will engineer the crap out of this thing and by engineer i mean open a spreadsheet and go to town so we have the average propellant mass between ascent and landing all of these are the same like we're populating the spreadsheet with a lot of like regular stuff these moment arms are useful um i believe these were guests they they look pretty specific for guesses so maybe they weren't maybe we measured with something we have our drag multipliers which are sort of like drag coefficients ascent motor landing motor we also have measurements so this must have been um with some like mock-up vehicle that we measured these these these values and then we have our flight profile so apogee 40 meters this is a lot higher than we ended up going um so these values can't possibly be right because i think we launched at 1.1 kilograms i don't know you can check like the flight one video if you want um number five okay yeah so this is plus or minus five meters so we do all of our math based on this apogee um which doesn't even seem to have happened here but then we uh these are our landing burn and divert equations so landing burn equation uh based on the apogee of the flight this is basically like if we have an average apogee of 41 meters how do we determine the ideal burn altitude you shouldn't trust these values like at face value because this is a i don't even know what the fidelity of the simulation is but this is basically the thing that i set up so that i could reference each flight profile and the values associated with it then we have a divert equation which means that like given all of the things with our apogee etc this can't even be right either right because i don't think we rely on apogee anymore for the divert but we have a multiplier where we multiply something i wish i understood this a little bit better but a lot of this stuff is like i found values in my little arduino sim that seemed to work and seemed to close the simulation none of this is close to like mathematically optimal it just is like well the controller seems to handle it so send it down here is a good example of coming up with values for the landing burn equation so we have an aperture of 30 33 35 37 meters then we have a burn altitude this is when we run things in matlab or simulink a higher fidelity simulation where we determine that if the apogee is 30 the ideal time to burn is 22.37 if we have all of these other values right so um 22.37 actually i think just ignore this for now 22.37 meters is when we should light ideally and this value is going to change with our apogee so we plot these out on a two-axis plot right here and then we come up with a line of best fit which is 0.649 plus 2.93 you'll notice that is very close to what we ended up putting in our little arduino simulation so this is sort of a polynomial that represents like if we have some apogee this is when we light um one of the things i haven't mentioned yet is that this is not actually the ideal time to light the motor the way that this was specced out was that we tried to light the motor so that in the latest possible ignition case we touch down perfectly and then every other case if we are lighting on the mean ignition come up time we we do still have to bleed off some of that so like this will give you a a a descent where you still have to bleed off some of the thrust and now that i'm scrolling down it looks like i did several of these again i wouldn't trust these values here are the values for the actual scout flight um we had 0.649 plus 3 which does look like that's consistent with what the arduino simulation says for the divert out oh right um so the divert altitude is the divert altitude is how we calculate gosh are we even doing this based on time i think we might be trying to oh i know what's happening okay so the way that we're calculating the divert gosh i'm like relearning this the way that we're calculating the the divert is that we measure when the peak thrust is and when that peak thrust happens we look at our altitude which as i'm saying it sounds like the wrong way to do it we should be looking at our velocity but when we look at our altitude we use that and then like way magnify that error that's what the divert multiplier is doing and when we way magnify that error we switch back here when we way magnify that error that gives our divert altitude target i think it doesn't matter we come up with some way of representing the error between where we want to be altitude wise and where we sh are altitude wise and then we turn that into a number in degrees or a bleed percentage and then we plot a sine wave out that we have to follow in in real time it is a crazy problem okay so most of these things that we've talked about happened before we even did the cad obviously some of the actual pre-flight measurements happened after we did the cad but a lot of these things to sort of reiterate a point that i was trying to make earlier happened before we opened fusion 360. before we opened the cad program started making sketches what i wanted to prove out is that this approach of trying to do some type of divert maneuver would work for throttling for propulsive landing and the answer that i got in the end was yes in theory it does work i would really like to see someone try and make this work i just like i now that i have another year of experience under my belt i want to try it in different ways but if someone is watching this video has like some knowledge or just drive to learn things you should try doing it i really think that the sine wave divert could work and it seemed to be reliable in the simulations the problem is of course with real life where you have to build things that don't break in the air what happened on flight two you can watch the video i'll probably link it down below but what happened on flight two we didn't quite eject the motor mid air and so the vehicle basically failed because of a mechanical problem and you know those things don't get represented very well in the simulations so in theory it works and be cool to see someone prove it out the standard for quality in this video is low and getting lower but it's now time to talk about the thrust vector control mount the tvc mount was designed back in july and august of 2020 and it took a ton of development so we spent from basically july to november perfecting this thing and when i say perfecting i mean making it good enough to work once out of two times uh in flight so you know grain of salt a lot of the footage that you were about to see was released for bps patrons almost a year ago so if you are into this kind of thing if you're into behind the scenes looks please feel free to support the project on patreon it certainly helps out quite a bit and without further ado let's start looking at the tvc mount actually no some further ado i do want to cover some basic functionality things we talked a little bit about how the limit on one axis was going to be eight degrees and we arrived at that eight degree value by looking at our maximum angular acceleration that we needed um and eight degrees was also just like the clearance that we could get with a bt-80 tube the 66 millimeter tube that we were using but we don't actually need that on both axis axes you know what this is going to be better if we show the footage alright so this is the thrust vector control mount for scout e designed specifically for this variant of scout fits in a 66 millimeter airframe with a few cutouts ultimately i tried to make it without cutouts but i i had to cut a few relief holes in the airframe you've got two motors uh one on the top and then one down on the bottom the bottom is the ascent motor the top motor lands the bottom motor gets pushed out and then it also pushes up against this little locking pin right here so that when the bottom motor fires it can't push against the spring that is spring loading the landing motor which is on top the landing motor has a little bit of a hat on top of it the hat basically has two springs one on either side and then the hat like plunges the landing motor down into the place of the ascent motor the other thing we had to add here is a little spacer um the spacer exists because we need to let that locking pin seat on the ascent motor and if we don't have the spacer there the locking pin can't like slide into place this is a roller pin right here which is kind of interesting basically the goal we'll talk about this a little bit later but the goal is to reduce the static friction to eject the ascent motor you can also see that we basically covered just one side of the ascent motor and this is because we need it to pop out here's the little window right here where we knock the motor against a screw in the airframe to actually knock the motor out this will all become more clear with a little bit more footage just a few more views of the mount here we're using bluebird a10h servos they are i think they run at 333 hertz in terms of like the pwm signal so they're pretty fast and then they also have like 4 000 something steps they're very accurate they're very fast they run on lipo power so you know 7.4 volts which means they are snappy and they're powerful and they're they're what you want for something like this oh i also put these little um relief segments in the outside of the mount these were originally intended to sort of guide the igniter wire so that it didn't get tangled and we could like have a predictable routing path for the igniter wire on the landing motor i have never used these in flight um they looked cool in cad and i thought it was a good idea and then it just wasn't needed alright so this is some of the early development footage from july and august of 2020 this is like just barely testing out the concept of slamming one of these motors out and then slotting the other one in place so originally we used rubber bands as you can see here but we still have that same locking pin i'm using a i think it's like a c clamp or a vise clamp to eject the ascent motor and we're also firing it upside down which is good because it means that like if we can fire upside down we can absolutely fire in a free fall as well it's a little bit harder for that ascent motor to get ejected when the mount is upside down you can clearly see the actuation um of that servo just some more clips here some of these are more successful than others one of the things that was very difficult to dial in here was basically like when we hit that pin how long do we hold on the pin so that we can eject the ascent motor but not get in the way of the landing motor as it slams into place this is a second series of tests that i did once i got the mount stuck into the airframe and so basically the goal here is like can we notice any big moments that are imparted on the vehicle when the motor ejects so as we you know throw this thing into the air is it going to kick the rocket around a whole lot this was one of the things i was concerned about because the motor ejects before apogee so we before apogee so we still have like a solid amount of time to coast here's more of those tests in slow motion you can actually see a little piece of aluminum that is falling away when we eject that ascent motor this is intentional um one of the things that i had to contend with over and over and over again was the static friction um overcoming that static friction of the landing motor sorry of the ascent motor and so this piece of aluminum served as a little plate that helped reduce some of that static friction it's it's going to be hard to explain the video but that's what's falling out there and it is intentional again more clips here it's a little bit easier to see if we speed the footage up here's some other clips where you can really see the slop in the mount we are just at the limits of these uh these servo linkages um you can see as soon as that landing motor slots into place there's a ton of sag in the mount it's like not at all confidence inspiring um this is probably around august of 2020 maybe september of 2020 you know obviously this isn't a problem because we're in free fall at that point but you know just something to consider this right here is when we started testing with an igniter wire in we tested with a flight representative mass motor that didn't actually have an igniter in there but the goal was to see like can we manage can we do cable management of an igniter wire in that motor so you'll see that there's there's not actually an igniter head on there we just want to make sure that we can route those cables that's a failed ejection right there ran into a lot of those you'll notice that i'm playing with a lot of different materials here scotch tape was involved a lot aluminum aircraft tape like aircraft aluminum tape eventually i did settle on the roller but it was not a easy path to get there here's a test where we are comparing the different um like ejection intensities um across you know different ejections i don't know how to explain this succinctly but essentially what's happening is we're we're looking to see like is this repeatable and the answer is yes well i suppose the answer is yes in theory so long as you like build it correctly each time here's more testing where we took a little bit of a nick out of the ascent motor this was a short-lived idea where the idea was to basically chamfer the edge of the ascent motor that was really hard because that's a piece of cardboard that's going to degrade on each ejection so like each objection you actually like worsen the quality of the ejection it's not good it's it's very like a it's like a single use kind of thing it doesn't feel good back to the scotch tape at this point sometimes we get these interesting like little roll moments where the motor is twisting as it comes out which is cool here's a shot of the locking pin slotting into place through the airframe so this is when the the motor mount is within the airframe this right here is another failed ejection test there are so many of these honestly it was very frustrating to try and get this to work and it seems pretty easy but the thing is that like you're dealing with these 3d printed parts that do have decent tolerances but also have like weird boundary layer stuff and like like inter print layer uh like ridges that you have to contend with and so if you're trying to run a flat surface or like a malleable surface like a piece of cardboard over a surface that is not actually flat but has these 3d print ridges you're going to dig in there over time and like your ability to eject the motor is going to change as a function of the time that you have like left the motor in there it's freaking insane um i'm glad we ended up on the roller approach we'll get there in a second here's more shots we're still using a rubber band at this point the rubber band is not a good idea i use a lot of rubber bands on my rocket but one thing to be aware of is that they are not very repeatable they are not um i just don't recommend it they change with temperature like their their elasticity changes wildly with temperature in the cold they just have none of the potential that they do in you know the summer heat so i don't recommend working with them we eventually switched this to springs all right and so here's where we start static firing so this is october of 2020. we do a couple of things in these tests so we are measuring the thrust uh the axial thrust of the motor but you'll also see a little bit of a gimbal movement and with that gimbal movement you'll you'll be able to see that there's a side load cell on the the static test stand um it depends which angle you're looking at of course this first test was a total failure for a few reasons we didn't seat the hat on the landing motor correctly and so when we fired we didn't actually lock into place on the landing motor and then the the motor like went back up into the airframe this is actually it's probably not that far off of what we would have seen on the onboard camera for scout flight 2 where the landing motor didn't seat into place here's another angle of that test where you can see a little bit more clearly we have a grip on the rocket and then this side load cell where we're basically measuring when we have a tvc deflection this is overkill at this point because it's simple math that like should tell us whether this is going to work or not but when we have a tvc deflection are we actually seeing the moment or like the side force that we expect that we should see and the answer is yes i have those side forces they correlated well with like what we were expecting and of course you can see the landing motor firing and then melting the the very end of the mount there we can also see a little bit of a khrushnik effect here which is really interesting um so we have october 5th burn 1 and october 5th recessed the deal here is basically that the recessed burn starts out as an okay burn and then it shoves itself back into the rocket as it burns and you can totally see the throttling effect we followed the curve very well until we slide back into the rocket and then we get that khrushnik effect and i'm just realizing now that we i put this note in adobe premiere that says you can also see how close the curves match until the second motor slides down into the tube could be a fun future throttling approach so like i knew a year ago that like i might have to contend with krushnik throttling some more shots of the static fire here uh it does look pretty cool love filming things at sunset i always recommend that you do this all right this is the most fascinating part to me of the thrust vector control mount conundrum specifically the motor ejection stuff so in any system there are like natural frequencies where the system will like you know naturally want to oscillate about i don't know what the actual natural frequency of this is i didn't come up with a number for it but i know that it has one because there's a lot of play in this thrust vector control mount what i mean by that is that when the mount actuates really hard it doesn't just go like this it goes like this right it has a little wiggle when it moves um and so what i decided to do um i can't remember what prompted me to do this but it was a great idea i turned on the high speed camera and then i started watching as we would wind up to do that ejection movement right so like the mount winds up in the opposite direction we go all the way to one side and then we try and slam it against the ejection pin inside the airframe so intuitively if i were to ask you which is going to be better if we started the ejection movement from the center where there's like less time to build up speed or if we started it from all the way on one side of the like actuation range and then drove it all the way into the ejection pin your answer would probably be that we had a like a larger actuation range so that we could pick up speed um i hope you're following along with what i mean but like your answer is probably going to be that you basically spend more time moving so that you can pick up some momentum you can like use your inertia right and that's not correct in this scenario so what happens with this high speed footage is i watch it back in like october or something like that of 2020 and i realize that the mount's natural frequency means that if we wind it all the way up to one side of the airframe and then we actuate it back the natural frequency of the mount gives us a node like a a a point or if we actuate the full range we hit a node of the natural frequency of the mount which is to say that we pick up all of this velocity as we're swinging back to like eject the motor and as we're picking up this velocity you know we're working with the natural frequency and then the natural frequency like starts to come back towards a node and we slow down again because of all of the play in the mount all of the slop in those linkages we slow down again so it's actually more powerful if you with this specific mount if you start the ejection motion from the center position rather than starting it from all the way on the other side it's like fascinating to me anyway this is a bunch of footage of that phenomenon so you can you can totally see it in this shot here look really close at like the speed you know you can see like it it changes a little bit through the actuation motion so here's another shot where we wind up first this one does end up working but i don't know just more shots to put in the video i guess and this is where the breakthrough really happened um we were contending with all of these problems of static friction within the mount and at some point it was like hmm how do you move a heavy load across a flat surface you roll it you freaking roll it you use a roller so i bought a bunch of like little stainless steel rods i dremeled the crap out of them and made a lot of little rollers and then i would seat them in between the motor and a little lip at the bottom of the motor mount so that when we hit the ejection pin it was really easy for that motor to start moving away from the side of the motor mount and eject of course one of the side effects is that we still get rid of this like roller pin at some point and eventually i had to figure out that we had to tape the pin in a little bit because otherwise the pin could fall out on ascent there's still a little bit of play when the ascent motor fires we do push up into the airframe so we had to fix that at some point but the roller turned out to be like the the key technology the key breakthrough that made this thing work a lot more reliably than it was so we went from something like you know 65 reliability to i would say like 85 which is not perfect but yeah and it's pretty easy to load here here's some clips of me loading it basically you slot the ascent motor into place you depress it you push the roller pin in there and you're like good to go so here's another clip of a static fire um this one's great because like right before i initiated the countdown which is like you know on the order of a few seconds uh it started pouring because this was when i was still in nashville tennessee and the weather there is insane so uh it started pouring and i was like screw it we should still test right we're here all of my boards are conformal coated my cameras are mostly waterproof like it'll be fine so here's some beautiful footage of that rocket motor firing in the rain we actuate the mount a few degrees if you look close you can definitely see those movements this test was interesting because we didn't end up firing the ascent motor during it we tried to fire both motors we tried to fire the ascent motor and then the landing motor but we only ended up firing the landing motor and the reason is that we had had these motors pointed up towards the sky for long enough with the rain because like you know it did start pouring pretty immediately but it was sprinkling it was like sprinkling a little bit and you know we were kind of on the edge so um what ended up happening is a little a little bit of water pooled up in the nozzle pulled up you know pulled up in where the igniter was and shorted the igniter out so we couldn't fire that ascent motor and we only fired the landing motor on this test but something really interesting happened when we fired the landing motor and i don't yet know like how to explain this phenomenon but if we take a look at the thrust curve um these are not khrushneq effect things these are like regular motor burns that are happening within the plane that they should within the exit plane that they should so there's there's there's little to no krushnik effect however when we fired the motor in the rain the thrust was like noticeably less enough so that like it would make a difference as to whether we could land or not um or it would make a difference like that was noticeable so this yellow line here is the fire um in the rain little james taylor a little fire and rain i don't know how to explain this if you have an idea of like what is going on here i would be very curious to hear your your thoughts but i find it fascinating um like the motor itself wasn't wet because it was protected by the ascent motor so it had to do something with like the atmosphere i guess i don't know or maybe there's something on the test stand that was broken but this was the only time that we observed a thrust curve that was like this all of the other thrust curves that we you know recorded were pretty normal um and this was the only time that we fired in the rain so who knows here's a few more shots of firing that rocket motor in the rain very pretty i love seeing like the droplets come down and i don't know those estus f-15 motors if you fire them at dusk or just like when it's slightly dark they make the prettiest exhaust in some of these clips you might be able to see that we have a usb cable that is connected to the thrust factor control mount that's actually connected to one of the spark boards that i built last year because the small board thing has been happening for so long that video came out like a month and a half ago or something like that but that small board thing has been going on for so long i stuck one of them on on the tvc mount to try and measure the angle of the mount as we fired and on every single test you know the board doesn't have data logging so i'm i'm printing out the values on a serial monitor every single test data logging failed i don't know what to tell you it's it's it blows my mind but on every single test with these stupid little spark boards something went wrong either the usb cable came loose or like the serial monitor wasn't working or i set it up wrong or we like ran out of cash in the serial monitor um like monitor i don't i don't know but i could never get data during a firing to like generate a transfer function of like what the mount's response is during firing anyway it's fine um but i'm frustrated this shot right here is a a great shot to show the side load cell and the bottom load cell so you can see the two points that we're basically measuring the side load cell is hooked up to ava which is inside of the rocket the bottom load cell is hooked up to the sprite computer which is basically it's a computer that lives on the test stand of course with all of these tests we're shooting slow motion as well and so you can see the actuation motions in slow motion too which is really cool you can see the little bit of wiggle in the tvc mount there's a lot of wiggle in this and we represent it in the simulations it is pretty much fine here's one of the internal cameras from one of the firings this is an interesting test where we fire the motor and if you look really closely you can see the uh roller pin actually gets sucked into the low pressure zone near the nozzle and then gets you know sent away you can see it in this shot when it pops out right there this is around the point where i realized that i needed to tape the roller pin in just a little bit you can also see it coming out in this shot burning a little bit as it goes so as i said before the roller pin can get yeted out if you don't hold it in just a little bit so we put a little bit of like aircraft aluminum tape around the roller pin and that seems to do the trick in this test here you can see the motor slams up against that lockout pin but it's still within the mount and the roller pin does not exit at this point and we've got a nice slow motion shot here of the uh the motor igniting even though we have a big piece of aluminum tape this is starting to try and represent um you know what it's going to be like for the actual landing motor at this point we are testing the crap out of the system but we light with a piece of tape over that motor mount there's the motor slotting in back into the mount we're just watching i mean we're watching like the same five static fires over and over again at this point you'll notice that uh these motors each time that you can see the casing of the motor it's usually labeled with a year and some other type of marker this is super intentional every batch of motors that i get because i'm really concerned about consistency across these little rocket motors and that's a big concern it's a valid concern that people have which is like you know do they all burn the same and so we keep pretty detailed track of like which motors come from where which manufacturing batches are which and i try to label them all here's another internal camera shot from one of the static fires again at this point it's getting boring and then this is a burnout from one of the static fires which is a fitting way to end this segment about the thrust vector control mount very pretty filmed in about 100 frames per second or so i use a sony rx100 for a lot of these slow motion shots it is like for what it can do it is very cheap and also has zero battery life most of this footage is from the fall of 2020 there were very few if any changes um made to the mount before going for flight 2 in fall of 2021 which is again insane that i i let that much time pass between flight one and flight two but pretty much no changes so that's like the state of the thrust vector control mount for scout e if i were gonna do it differently if i were going to design it again i would use stronger servos i guess i would create a very rigorous procedure of how to set the mount up and then i might create like rules about how many times a mount can be actuated as much as this is like cool because it's spring loaded spring should work the same every time i think over time like the springs became fatigued or we were pushing them past their like plastic deformation limit and if i had to guess there's probably some contribution of that to the failure on scout flight 2 um so we would just like make these mounts easier to manufacture so that we could fly a new one every single time i don't know it's a very complicated piece of hardware um maybe complicated is not the right word but it's it's delicate um it's very cool when it works and it is not catastrophic when it doesn't but it's not good okay when talking about the tvc mount we have one more thing to discuss and that's modeling the actuator dynamics which is basically modeling the performance of the servos slash mount as one system when we run our simulation to determine what our attitude control gains are what our rate control gains are even our position and velocity gains all of those things are going to be coupled with the actuator dynamics so we need to represent those dynamics in a simulation somehow there's a video previously on this channel where i represented with i think a delay there are a lot of ways to do this depending on the fidelity that you want so what i did is i hooked up that spark board onto the mount i plugged it in and i started printing out imu data from the spark board then i would actuate the mount to one degree to two degrees to four degrees i also ran these tests with two motors inserted with one motor inserted with two motors but one of them wasn't full so like near the end of the burn and basically what's happening is we're trying to characterize all of the different actuator dynamics that like heavily change depending on how many motors are in the mount and what that wiggle is going to look like the most important thing here is logging the times and the angle of the mount as well as the set point which is where we're trying to drive it to so if we're trying to drive it from 0 degrees to 4 degrees we need to know exactly when we send that four degree signal to the mount and then when the mount actually arrives at four degrees i think i spent like two full days running these tests which is overkill and not surprising that's a common theme for this project at this point then i took that data i cleaned it up and i made a huge google sheets document with all of the different like frequencies and step responses for the mount there are actually a lot of ways to do this you don't have to do a step response to characterize your actuator dynamics you can use a sine wave there's this video on the spacex channel where you can see them doing actuator testing using a sine wave with increasing frequency but the same amplitude and they're absolutely using that to test out like what are the what's like a good transfer function to represent the dynamics of this mount either way a step response was close enough to me so then i cleaned up that data i brought it into matlab and i used the system identification toolbox to generate a transfer function that would fit to the response of the mount or fit close enough this stuff doesn't have to be totally perfect it's model rockets right but a transfer function was the way i wanted to do it you can also represent this stuff as like a state space model you can represent it in all sorts of ways but a transfer function is a nice way to do things and is easy to represent in a simulation the sys id toolbox comes up with that transfer function and fits it to curves so then i named those transfer functions and saved them for different parts of the flight and then in the actual flight simulation we use different transfer functions to represent the actuator dynamics depending on if there are two motors inserted if there's one motor inserted if we're in the landing or ascent phase we also have different constraints um maybe we'll talk about this later but we have different constraints in the software about like how far we're allowed to actuate um in terms of whether we're in the ascent portion or the descent portion um the more i talk about this project the more insane um i realize it is it's it's really easy to like forget about that um and then i put all of the documentation and stuff together and it's like wow this is crazy anyway that's how we modeled the tbc mount to represent it in the simulation and that should just about cover all of the stuff that has to do with the tvc mount ejection system all right gamers now it is time to talk about landing legs this is a much harder problem than i anticipated it would be and it continues to be a difficult problem to solve but we're going to talk about what they look like on scout e when i initially envisioned these landing legs i wanted them to be incredibly rigid so that they just absorbed any shock that they felt and didn't have a springiness to them one of the problems with the echolander was that the legs were 3d printed fully and the way that they worked essentially let us have like a lot of springiness in the legs so the vehicle could bounce back up before we look at the design ultimately what i've learned here is that legs are a problem of interaction between two items one is the ground that you're landing on and one is the legs this seems obvious in hindsight but basically like you can solve all of the problems you want in the legs you still have to understand what type of surface you're landing on which is why in the next version of scout we're going to prepare a landing pad where we can like have a very known surface to land on with that said let's take a look at these legs so we're back in the cad here and we've got our landing legs folded down here i don't remember if we put this in the earlier part of the video but we model the legs both both as down and as up so we actually have two sets of legs in the uh the cad file here we'll start with them down these legs were designed or rather so i came up with the concept of how i wanted these legs to work and to look and i think i am the person who decided we wanted carbon fiber rods but um last summer parker wah interned at bps um the summer of 2020 and he actually did all of the actual cad work on the legs so thank you very much to parker so moving into the legs here we have a piece of four millimeter solid carbon fiber rod that's what the strut is right here um so that's taking most of the load when we touch down then we have two two millimeter solid carbon fiber rods uh as the actual like folding down part the two millimeter carbon fiber rods are terminated with the foot of the leg and there are a couple of features that are of note here so on the bottom we have the the bps logo which does look quite nice um then we we have the slot that the four millimeter carbon fiber strut rests in this ended up getting modified i'll show some video of it in a little bit but this ended up getting modified to have a little bit of a pin across there to help lock the leg in place i don't remember if we ever had any problems with the strut popping back out but i ended up adding a small piece of steel rod across the edge here and that gave me a little bit more confidence that the leg would stay locked in place once we deployed the two top parts on the leg here are to help guide the strut into place into this little slot as the leg folds out we want to make sure that the strut is going to lock in one of the things that was difficult to dial in with the landing legs was keeping the strut like mounted in the right direction i'm going to have a hard time explaining this but this is where the strut mounts and we actually go through the wall into the tvc mount if i remove the airframe here the screw that takes most of the load when we touch down on landing is the same screw that is holding the tvc mount in place so we intentionally mount these at the same exact part so that all of that load goes through one place and we can i mean just sort of normalize that we also used to have a part of the tvc mount that would come down and interact with this screw to help line things up i ended up ditching that i can't remember why it seemed like it wasn't a very important part and this screw is really just here for alignment purposes and the alignment is to make sure um if we you know if we look at the leg from this view right here we don't want it to rotate left or right we want it to slot right in the center and so that bottom screw is what helps us dial in basically like the pitch of the leg or the yaw of the of the strut we didn't model the rubber bands that actually fold out the leg but that is how that works so we have this little fork device here and a rubber band goes around that and then interacts with um or or basically attaches on the other end to the base of the landing leg structure right here so the rubber band goes in between these two this little piece with the fork can actually slide up and down the strut it's not really necessary it's going to always be pushed up against the the top end here but it can slide i don't know it's a thing parker also went uh super overkill but i kind of love it so he modeled these little slots for the rubber band to sit in i'll put some footage of it here he modeled these little slots in the landing legs so that we could seat a rubber band in it when they were folded up very elegant very nice it looks great the main constraint of designing the legs was the size of the two millimeter carbon fiber rod you can actually see how deep it goes into these parts here that's the main constraint of designing how long the legs were these come in i believe 10 millimeter sorry 10 centimeter lengths and that's what we're working with here so we didn't we wanted to model um these legs or we wanted to design them around an existing part so that we didn't have to make tons of cuts the only carbon fiber rod you actually have to cut is the four millimeter rod here which you cut down to some specified length one of the other things that you might end up noticing here is that at the base of the landing legs so we've got this big base part which interacts with the launch pad it and it actually interacts with the thrust factor control mount too because right here we have these two screws uh whereas every other quadrant on the on the part we only have one screw up top and that second screw on the bottom is the ejection pin for the uh landing motor so when we actuate that gimbal um we hit the the tvc motor out of sorry the we hit the lit oh my gosh we hit the ascent motor out of its place with the ejection pin there are so such a complicated rocket all right so here are the landing legs in the stowed away configuration we can turn on the airframe again for a second they slot they fit right up against the airframe here and then the way that they are stored is that there's a rubber band um just below this part right here just below um like that section the rubber band holds the legs in place now the deal is that because so we are actually like over extended we are past 90 degrees on that strut see how this this this leg strut actually goes a little bit in to the airframe so because the rubber band gets um pulled outside of like the hinge point a little bit we still are able to pull that landing leg out so once we burn the rubber band that's how we actually deploy the legs we use a piece of nichrome wire to heat up the rubber band that retains the legs in the stowed position and when that nichrome wire cuts the rubber band that retains the legs we deploy them because of the force that is provided by the the rubber band that goes on um the little fork all the way down to the leg base the way this works in practice two is that we actually rely on the over extension of those two millimeter um carbon fiber rods they're pretty bendy and obviously like their diameter isn't large they're not very beefy parts and so we actually want the legs to over extend a little bit and you can see in this high speed footage that's the way that we lock out the strut we rely on like the force of deployment to lock the legs in place so that's the cad portion that's how they work in theory and now we can take a look at some of the development footage so i ended up doing like two rounds of testing on these landing legs the first was without that little steel retainer pin um that you'll see later and you'll sort of get why i add it so let's just start looking at the footage there's a bunch of high speed shots here and in most of them you'll notice that there's like a decent bounce once we fold the leg out most of it seems to come from the strut when the strut like bounces against the um like seat termination i'm making up all of these terms i hope this makes sense but it's clear why i wanted to add some system to like make the strut deployment a little bit more reliable would the legs work in flight this way probably probably fine does it look really sketchy in the high speed as if like boy that strut could pop out on just a whim uh yeah no it does look like that here's just some more shots to show the deployment process you can also tell in some of these that the little like spots on the side of the leg foot are helping guide that strut into place those were definitely necessary i don't think we had them on there in the initial design and then parker quickly realized like nope we need those in there you can also see that in some of these shots i'm using the little rubber band holes and in a lot of them i'm not there's the little little pathways little guide points for the rubber band to stay in again it looks so nice when they're in there but ultimately i don't think it ended up being necessary here's some slightly less high speed footage but a little bit higher quality these legs do fold out very very fast so the high speed was really helpful in troubleshooting all right so this is now footage from after we we added those little steel retainer pins you can sort of see them in this shot but you'll see them more clearly in future shots so what you'll notice is that the uh although we do have a significant bounce once we deploy um the legs we don't have all of that chaotic motion and bouncing from the end of the strut where it looks like it could pop out at any point you can sort of see a little bit more clearly that steel rod basically what i did is i just took a drill and i went right through the side of those two little side retainer things on the foot of the leg and i just like ran a steel push rod through there and it seems to work pretty good it was a thing that i never ended up modeling in cad because it just seemed to work this way and it didn't seem to have tight tolerances um and i mean that's that's that these overhead shots are also really nice when it like comes in and out of focus these were kind of difficult shots to get but i'm glad i went for it i probably filmed way more of this process than i needed to but this is the engineering cut so we're putting all of the footage in here here's a nice shot of the rubber band doing what rubber bands do this is one area where i did feel comfortable keeping the rubber band instead of trying to switch to some metal spring as i mentioned before i prefer to try and avoid rubber bands if i can but a leg is an easy thing that we can test out at the launch site to know like are these rubber bands going to be springing enough even if today is like very cold or something like that so i i felt comfortable keeping it and it was a lot less bulky than the spring would have been all right so these are a series of shots where i tried deploying the legs all at once these are really cool because you can sort of see the vehicle move up as the legs push down it looks like i'm holding the body tube in these first few tests but we do end up doing some some drop tests a little bit later on um and this is just looking at like does anything crazy happen when we deploy all the legs at once here's a nice shot of when the rubber band was seated in those little rubber band guides you know it just looks a little bit cleaner it helps manage where this thing is and then here's a shot where we drop a body tube section onto the floor now there are a couple of things to note here because this doesn't bounce very much when it hits the floor so the things to note are that this is not mass representative of scout this is probably 300 grams maximum so that already like throws off the dynamics of what touchdown would actually look like with scout secondly we're dropping this on a hardwood floor which is going to have a much different you know response than if we were dropping it on grass and thirdly the cg of this is going to be a lot lower than it would actually be on scout so we're not even getting like the right tipping dynamics too but it's a cool test to show in high speed and it does look really good it looks like those legs have got all of the bounce stuff figured out so this is essentially the design without many changes that flew on scout flight 1 in november of 2020. i was pretty happy with the design i do think it was good and i honestly think like most of the bounce is coming from the grass at this point these legs don't seem to contribute a lot to the springiness of the whole system and so one of the ways that we could combat the um like springiness of the grass in my head was we could use a gas damper something that's going to take energy out of that impact and then put it back in more slowly over time and gas dampers are pretty good at that so uh i mentioned this in the scout e video but we did try a bunch of different techniques to mitigate this and in the interest of just you know this being the engineering cut we should talk about all of them one of the first things i tried was a crush core this is the same type of tech that falcon 9 uses in its legs it uses them inside of the strut of the leg but it doesn't really matter where you put it i mean maybe that's a lie i don't know it probably matters where you put it but it probably doesn't for this scale so what i did is i rolled up a little bit of aluminum foil i wrapped it around a pencil to try and get the diameter consistent i also tried to keep the length of the like the full unrolled aluminum foil consistent then i taped it to the bottom of the foot on the leg and this was a really easy way to try and avoid modifications that i would otherwise need it was like let's start out with a solution that requires almost no extra effort and we'll see if we can make this work i ended up dropping this on a hardwood floor several times and found the results to be awesome crash cores are great at dissipating energy really fast um one thing that i did not have characterized well though was basically like the same problem that we had with um some 3d printed sheaths down the road after this the thing is it's kind of important if you want to characterize a crush core to know how straight that plate of aluminum is going to be and it's just aluminum foil like i'm not going to be able to get crazy high tolerances on this this would be something that you could characterize um there are always like more tests that you can run i can think of 30 ways that we could make this more complicated than it needs to be but um you know in trying to solve this problem one of the big issues is that we don't actually know how high we're touching down um or how high we're dropping when the motor burns out even with the throttle divert thing i could never get the drop altitude to be more consistent than like plus or minus a half a meter and the energy that needs to be dissipated the difference in that energy between you know burning out at 20 centimeters and burning out at 100 centimeters that difference in energy is is significant so designing a crush core that like will will compress along that whole region to reduce balance is pretty difficult so the next thing i tried was these sheaths around the carbon fiber strut so what i did is i chopped off a bit of the carbon fiber strut and then put these like really tight fitting 3d printed parts around it so this is essentially the same thing as the crush core but it's it's reusable we have this pretty high static friction that we have to overcome and in overcoming that the energy is dissipated as heat and a little bit of sound the problem with these was that it varies the length of the strut and the strut doesn't have a lot of travel before or the strut isn't able to have a lot of travel before we get in trouble with that strut falling out of the legs here's a great clip of the like all of the legs basically falling apart when we use up that crush zone is this a fixable issue totally did i want to fix it not really did i think there were other ways we could fix it without using up that much room yes so those other ways to fix it looked like the gas damper that i talked about in the scout e flight 2 video and when i say gas damper i'm talking about a hypodermic needle or a syringe basically um one thing that i didn't address in that video is that we did cut the needle off on all of those things the needle is gone those are dangerous they can like impale you it's not you don't want to fly with needles on your rocket um so before i epoxied that basically sheath onto the top of the needle i chopped the sharp part of it off and then sealed that whole thing off with epoxy that turned the needle essentially into a pressure vessel i ended up finding that like over time if you used the needle syringe thing a lot um it would the air would start to find pathways through the epoxy and like de-bond it a little bit so it became less of a gas damper and more of a gas-like like a burst disc um like we would get to some pressure within the needle or within the syringe and then it would burst through like some way through the epoxy either way it did seem to dissipate the energy pretty well i was like decently pleased with how these worked i just don't think i did a great job of manufacturing them i think gas stampers are perhaps the right way to go for something like this because um like the oh boy i am really out of my depth so just forgive me if any of this is wrong but it seems to me that like gas dampers put energy back into the system a lot slower than some other methods than like springs or or things like that so like when the vehicle touches down that bounce that that return of energy back into the legs seemed to be a lot slower um than you know the carbon fiber struts which immediately are gonna spring right back and i think it's easy to tell on this but the way that i built this is i basically took the the head of the plunger for the syringe i took that rubber part that like little rubber gasket thing i took it off of the plunger for the syringe and then i epoxied it onto the end of a strut i had to measure out a couple of lengths to make sure that this was like the right size but i epoxied it onto the end of each strut so basically the struts got shortened a little bit and then became a part of that syringe as i talked about in that flight 2 video we drilled a hole in the side of the syringe at about the one centimeter mark so we had one centimeter of compressible and like uncompressible zone but the rest of the syringe you could use the plunger and then not actually compress that air now that didn't matter too much that's more of like an integration thing because you don't want to pressurize the whole volume of that piston it's just not necessary and you're also not going to get great like rigidity the piston or gas damper would end up buckling and like folding outward so you want to have like most of the tube of the syringe there to prevent buckling so the hole basically bleeds out the air and then when we pass the hole when we when we pass that gasket past the hole that's when the air starts compressing and we start like using the gas stamper i don't know if i'm using the right terms here maybe it should be called a shock absorber i feel like i just like throw a lot of technical terms with the wall sometimes and i see what sticks but you all know what i'm talking about because you can see the footage that's just about that for the landing legs for scout i also tested spikes i mentioned this earlier i tested a bunch of different lengths of spikes i tested different sharpnesses um i tested nails i tested just like one millimeter push rod um and it turned out that it was just like not predictable enough this you run into the same issue that you have with the aluminum crush core um because you don't know if you're dropping from a quarter meter or a full meter and the energies that need to be dissipated there that is a very wide range to work within and so if you spec out the spikes to work at a half a meter they're going to be really small they're going to be really thin and they're going to work really well at a half a meter and then they're going to be completely ineffective from a 1 meter drop and if you spec out the spikes to work at 1 meter this is the worst case i think when you spec them out to work at one meter if you drop much closer to the ground those like little one millimeter rods that would stick into the ground otherwise from one meter at a quarter meter they're gonna bounce they're gonna like contribute to the bouncing problem of the leg because they're not going to have the energy to like go into the dirt and stick you there legs are a fascinating problem and i have a lot more respect for people who work on like landing leg systems for landers uh for who knows what i assume the same is true for like aircraft landing gear it is a fascinating problem and it is definitely not solved here but this is basically where i'm at with the landing legs for scout for scout f i'm not sure what i'll do yet we'll see all right homies now it's time to talk about airframe assembly or construction scout was built using bt-80 tubes which are about 66 millimeters in diameter and they're about one millimeter in thickness they're really lightweight tubes which means that they're great for things that have a very constrained mass budget and they're terrible for withstanding impacts i was really hoping to build this thing so that it would work right out the gate but it's clear that after flight 2 like we probably should be building this thing to withstand a few hard impacts for comparison echo had several hard impacts on the ground and was still able to use the same airframe that it did it uses a three inch airframe which is like 74 millimeters or so and that's like a two millimeter diameter cardboard wall so it's a little thicker i painted roll stripes on scout which are just black marks on a white body tube i really like doing this with most of my rockets um it's the same type of aesthetic choice that happened with the early saturn vehicles i think the early titan vehicles too had it the a4 rocket had it a lot of these early launch vehicles from the us at least had roll stripes because it was easier to track the role with a camera and see if like everything was working that way at least from like an early guess point before you got data back i used blue painters tape to make these stripes if you're careful with it you can get really good lines the next thing i did was label my axes i talked about this in the building lumineer series but it's pretty important to label your axes if you're building a vehicle that is also modeled in cad labeling which directions are x y and z is going to help you down the road when you need to drill or cut holes that are modeled out in cad the next thing i did was start attaching the leg base and drilling holes for it what we're doing here is sometimes called match drilling so we have a part with existing holes and then we use those holes to drill through a separate part so that those holes can line up perfectly sorry for the beings this makes things a little bit easier we don't have to drill holes beforehand into the airframe we can just use the actual part to align where the holes need to go around this time i also started making cutouts from the airframe i mentioned this in the tvc section the mount was designed to have no cutouts if possible but ultimately it wasn't totally possible to get that full actuation of eight degrees on one axis we ended up having to cut out a few parts of the tvc mount or rather a few parts of the airframe to accommodate the full servo actuation range i also cut out some holes so that i could access the lockout pin for the tvc ejection system or for the ascent motor ejection system you have to manually pry open the lockout pin in order to load the ascent motor so we need a basically an access hatch to do that and that's what i'm cutting out here around this time i also started attaching legs and i ended up using ca glue to attach the legs as well as those screws that took the load the ca glue helped us lock in the yaw of the strut we talked about this a little bit earlier being a problem essentially as the strut comes down we're sort of wiggling one way or another if we don't lock it in place so the load is still going through those screws that also go through the tvc mount but the ca glue helps us hold that orientation um that second screw that was below you know what man is this stuff even worth it like i don't i don't know if this stuff is like worth going through but i promised i would tell you everything so um yeah the ca glue is holding that that strut in its like yaw orientation so that it can easily lock into the foot of the leg then here we're just screwing in uh those strut mounting points to the airframe along the way i made a lot of pencil marks on the airframe in order to mark up you know like where axis lines were and i ended up having to wipe those off too having is a strong word but i ended up wiping them off i wanted this thing to look real nice okay and at this point i was ready to attach the fin deployment assembly up top this thing is kind of a pain to build into a rocket but it is still a design that i'm really proud of to recap there's a servo which drives a little plate in an assembly that fits inside of the nose cone that plate pushes down on the fins which are hinged so that in an upright scenario it will push the fins out and then when the plate retracts the fins don't have anything else to push them back in other than the force of gravity and if you go fast enough the fins actually lock in place because of a little bit of velcro that you'll see in a bit so the plus side of these fans is that they look really cool and i'm proud of the design and the downside is that it's a pain to make those cutouts in the airframe and it makes the airframe very delicate at the top of the vehicle you can see in the footage from scout flight 2 once we hit the ground we just fold right over at that section because there's no like circumferential strength because we're cutting out all of these sections i used a piece of cap ton tape as a reference and then cut out straight lines that were i think like three millimeters in width um i tried to get it as close as possible and then i think i had to refine it a little bit as i went but basically just enough space that we could fit those pla fins back into the airframe but not making it too small so that we create a bunch of friction there and here's a nice clip of me realizing we've dialed it in pretty well so the fins can rotate freely after cutting out the holes i mounted the nose cone onto the top of the airframe and the nose cone actually provides a lot of the support that we lose by making those cutouts so the rocket is stronger for having the nose cone on i also added small screws at the very tip of the fin the goal here was to just provide a little bit more inertia so that when the fin is coming back in it fully seats inside the airframe with that velcro here's me applying the red velcro strips which were ultimately just a little bit too thick and large so i ended up replacing them with black velcro strips down the road some more interesting clips here we actually had very little room inside the airframe to attach the nose cone on so you'll notice i'm using a nut on the screw to actually like effectively reduce the screw length it would have worked to buy shorter screws or we could just work with the existing hardware we have and add a nut to shorten the effective length here's me removing some more pencil marks and then moving on with airframe construction here are some shots of me preparing the coupler tube to join the top and bottom body section we start out by marking the center point on the coupler and then we match drill holes uh in both airframe sections so once again like the initial clocking of the coupler doesn't matter because we're drilling the hole through both parts then we lock in the holes with the screw on one part of the airframe attach the other part of the airframe align them and then make a second set of drills after this i made the avionics cutouts and drill holes these were done sort of by the cad and then sort of just on what looked right to me i made cutouts on either side of the flight computer which is ava so that we could access all of the different usb ports and sd card slots here's some more miscellaneous shots of me cutting out other parts of the airframe you can see the tvc servo poking through a hole that i cut here as well as some more fin actuation tests this wasn't strictly necessary but in a lot of these tests what i was going for was to see if we could get all of the fins to retract perfectly so that they they all like you know had equal alignment when they retracted into the airframe which is basically just a game of like seeing how thick we need the velcro to be like entirely unnecessary for this after loading in the tvc mount in the flight computer i attached the landing legs so that we could start testing motor ejections those legs as a reminder that leg base specifically holds the ejection pin that allows us to eject the motor all of these systems on this rocket ultimately work together and some are like co-dependent on each other to work and once i got those legs attached i got super extra and i colored in the bps logo on the foot of each landing leg this is like you know like everything with this project it's entirely overkill but it's good to have pride in your work too i suppose that's the flip side of going way too hard with how this thing looks it's good to have pride in your work and so this is let's let's call it that that's what's going on here okay pals it is time to talk about parachutes although the goal of scout e was to land propulsively for the first few flights i did want to have parachutes on board as a safety measure the main reason for the shoots was that if something went wrong during the flight we could pop them cancel the propulsive landing and still get to the ground safely ultimately i'm not sure that the shoots would have recovered the rocket safely just because of the fragility of the airframe itself like our touchdown speed would have been fast enough that i think it probably may still have crunched regardless it would have been safer than coming down totally ballistic without any way to slow it down so the shoots were a good idea initially and the main scenario that i envisioned where they would be needed is if those fins up top if the fins to reorient the vehicle during its free fall if those didn't have enough effect to get the vehicle back to upright when it was time to light the time to light the motor um the shoots would be popped and actually that like code did run on the flight so we were able to either abort on ascent with the shoots or we could abort at the point of landing motor ignition we're either gonna light the landing motor or we're gonna pop the shoots and we never passed the criteria where we needed to pop the shoots but i figure we should probably discuss them since this is this is the engineering cut so we talk about everything here i had parker design these parts as well just like the legs this part is pretty simple the basic idea is that since we can't use the top of the airframe which is occupied by the fins we pop the chutes out the side this works a lot better for smaller rockets this doesn't scale very well with speed so we print the entire shoot bay there are probably more efficient ways to do this but i don't care this is how i did it this allows us to not need to use the airframe as a pressure vessel which is a lot better because we have sensitive electronics above and below the parachute bay inside the bay we also have a small piston slash it's more of a plate really and the plate allows us to separate the black powder charge from the parachutes just enough so that we don't burn them it also helps to push the parachutes out as opposed to just like fill the entire volume with black powder because really the desired effect isn't to have an explosion it's just to get the shoots outside of the airframe so the piston is a great way to do that the shoot bay will end up going inside the airframe but before we show that i want to show some testing of the system early on so here's a series of tests where we're dialing in the amount of black powder the placement of different pieces of tape on the side we're dialing in every part about the shoot system to make sure that if we need to use them they do work three two one okay this is ejection test two still 0.4 grams of black powder this time we have non-perforated tape blue tape on either side uh with no relief cuts in it um and i think we're all set to go here three two one nice this test is using pyrodex rather than the older black powder mixture the assembly is now inside a small test airframe we're attached with four pieces of tape approximately one centimeter across on each side four three two one okay looks like we lost just a little bit of grip here i could widen this in the design otherwise it looks like a pretty good test we lost the door which is good a couple of small burn marks there and it seems like that's probably an appropriate amount of pyrogen we want it to be on the side of too much rather than not enough okay this is ejection test four we have a slightly different setup now just changing little bits every time after i review footage the big deal here is that we are now flush against the airframe when we look from the side it's a really clean cut and it's a really clean side profile once again we've just got the cardboard as the only barrier between parachute and the uh outside world this is about a half gram of pyrodex triple fg and then my thought is that we'll do just one more of these tests today again with the two pieces of tape and when we're ready to fly this will be white masking tape so it blends in a lot better with the vehicle and it's easy to replace if i ever have to replace the charge or do maintenance on the chute firing in five four three two one okay this is the final test of the day we have the same setup as last time one of the pieces of tape is more strongly attached which is on this side the other piece of tape is more weakly attached with less surface area on the door that folds out we're once again pretty much flush against the airframe and we've got the chute packed just a little differently this time which should allow it to expand outwards a little further from the body of the vehicle without getting caught like it did last time firing in five four three two one very nice some of these tests were more successful than others it was difficult to dial in how we packed the parachute and again this sort of contributes to my sense that ultimately i think if these shoots had to be used it's possible that they wouldn't have worked that well whether it was because they couldn't get unfolded correctly or it was because um you know we weren't moving fast enough to inflate the parachutes and so that pretty much concludes the testing for the emergency shoot ejection whatever you want to call it system and so with that here's a little bit of footage of us integrating the um whole assembly into the airframe so i epoxied the uh shock cord onto the back of the chute ejection system i also put a knot in there so even if the epoxy fails it should be fine i marked up the airframe for the different screw holes and then i'm pretty sure i just sort of guessed for the size of the door that we needed i can't remember exactly how i sized that but it wasn't on cad it was probably just like a decent enough guess i packed the shoots inside the airframe and then i secured the door with capped on tape but i ended up replacing this cap ton tape with something closer to like white duct tape for the actual flight and that's still what's on the vehicle now the chutes never needed to be fired which is probably a good thing um and at some point i'll have to remove the the charge and use that on a different flight now we're going to talk about avionics scout uses the ava flight computer and specifically we're using ava r2 on the scout e rocket there's a whole video that's dedicated to details about the ava flight computer i will link it in the description below but we'll do a super quick recap in terms of the microcontrollers there are three on board in the center we have the mpu which is the main processing unit that controls all of like the hardware on the flight it integrates all of the other sub computers and it records data that is a mark 20 dx256 blh7 is that right mk20dx256vlh7 90 sure that's what it is it's the teensy 3.2 processor on the sides we have the navigation and telemetry sub controllers those are the atmel at sam d21g microprocessor pretty sure that's what it is in terms of sensors the imu is the bosch bno-055 the gps is the u-blox zoe m8q the barometer is the tems 5611 i guess those are really our main inertial sensors that's what tells us where we are we log data to a flash chip on the back of the board during flight we then put that data over to an sd card for easy access after the flight telemetry is beamed out using an external xb pro s3b radio and then for the servos in this specific rocket we run them on the raw lipo power which in this case is 7.4 volts i conformal coated all of the electronics that went into scout this is necessary because i used to fly out in nashville tennessee it gets wildly humid there and that can actually cause some problems on the boards um conformal coating is a great idea anyway if there are any like you know metal shavings that end up floating through your rocket they will uh you know conformal coating will help you prevent shorts from those as part of specking out an appropriately sized lipo for this flight i hooked ava up to my power supply and then monitored current draw for a little while and that's how we arrived at like the appropriate milliamp hours for the lipo which speaking of which i'm pretty sure is 500. let me double check that uh yes here it is it's a 500 milliamp hour 2s 20c lipo the lipo got glued onto the back of ava to save a little weight and sandwiched in between the lipo and ava is a high speed camera it's a run cam split hybrid 4k i think that's what it's called i don't i might be getting the name wrong either way on the back of ava we hot glued this camera in and this is the camera that ends up looking down at the thrust vector control mount during flight we power this camera off of the raw 7.4 volt lipo so as soon as we turn the rocket on that camera begins recording that's not the only camera on board though as we have two outboard cameras one that looks at the horizon and one that looks down at the ground both of those cameras are also run cam split 4k hybrid whatever the name is but we run those off of the 7.4 volt lipo as well so when we turn the rocket on everything starts recording except for one camera which is a run cam 2 that's pointed down at the reaction wheel that actually brings us to the reaction wheel part of the avionics section the reaction wheel is driven by a little 12 volt dc motor and i use an adafruit dc motor driver to drive it i don't remember what type it is i can probably look it up motor driver here it is it's an adafruit drv8871 dc motor driver the reaction wheel is super underpowered and is maybe one of the least analyzed systems on this rocket i used the exact same pid gains that i used on sprint to actually drive the wheel the rockets have a similar enough mass moment of inertia and i was just like well you know controlling roll isn't entirely required for this we just have to not be spinning at a crazy rate so like the reaction wheel even if it doesn't hold our attitude very well is still doing its job like well enough in terms of wiring on scout e i wanted to prevent any chance of like super dumb failures in my mind a dumb failure is if a cable disconnects because you like accidentally pulled on it when you were integrating the rocket or something like that so at every joint between a cable we had a zip tie or some type of way to secure it down so that you had to either pull very very hard to disconnect the cable or you had to break the cable this mostly applied to servo connections but it also meant that at some points we just soldered cables we ended up shortening down servo cables as well to reduce slack between the tvc mount servos and the ava flight computer i also did cable lacing on the servo cables for the tvc mount this was entirely unnecessary again common theme here but it looks really cool cable lacing is like a very cool look so i used a dental floss and i just kind of went for it integrating the computer into the vehicle is kind of a nightmare of a process there are so many different cables that come in and out of ava and some of them have to go through the access hatches some of them just go straight through the vehicle so it's like a i don't know it's like a solid hour process to get the flight computer fully integrated and wired up into the rocket we also had to strategically designate space for cables to pass which means i took a dremel to the 3d printed mount because there wasn't enough room for cables to run by sort of back on the airframe side any cable that ran up the rocket so that would be the servo cable for the fins the gps antenna we had some power cables for cameras the pyro um stuff for like firing parachutes that all had to run up the outside of the rocket because on the inside the reaction wheel sits on top of ava so that's why we have those cables on the outside if it was a longer run i would probably use a raceway for this but basically we cut a hole in the airframe section and the coupler it's a pretty inconspicuous little hole there and then as long as you route all the cables together it looks alright for mounting the outboard cameras i attached two of those run cam split four hybrid whatever cameras together and then i cut a hole that looks like roughly the right shape in the black section of the airframe and this means that like those cameras are a lot harder to see if you're not looking for them and like any good engineer i used a tremendous amount of hot glue to secure them there one of the last things to cover for wiring and avionics here is arming so whenever you have a computer that is in charge of firing either an explosive charge or a landing mode or something like that you need a physical arming switch which is like even if your code totally falls even if something goes terribly wrong there's no electrical path there's no like possible way that you could fire something accidentally until you're really ready to do that so ava has an arming channel at the bottom right if you connect two leads that are on a terminal block you basically arm all of the pyros so with scout that arms the landing motor that arms the chutes that arms the landing legs this can be and is on scout something as simple as two wires that when you're ready to fly you just twist them together and then look for continuity on the ground station with telemetry but i wanted to make sure we covered that just in the name of safety coming up is some cool footage of something called software in the loop uh sometimes you'll hear about sitl software in the loop or hitl which is hardware in the loop what we're doing here with software in the loop is we're simulating a flight we're simulating the inertial measurements that we would see and we're using those to see if ava will step through all of the state changes that need to happen now the tricky part here is that we actually do have some hardware involved there's like some hardware in the loop right but the it's not actually in the loop in order for this to be hardware in the loop we would have to connect up sensors and posit like position sensors to actuators and then feed those positions back into a physics engine which then like affects all of our other part of the loop but the hardware is out of the loop it's just responding to the software in the loop test what you're seeing here is the telemetry ground station that is reading out the state of ava and then i'm basically just turning the rocket on and after about 10 seconds it starts the software in the loop sequence there are a lot of ways to go about doing sitl what i have is basically a function that directly replaces the navigation update function which is where we ask the navigation computer for data and it returns all of our inertial measurements and so instead of that we have an sitl update function which replaces it and feeds us those inertial measurements just as if we were actually flying so then on your screen you can see that ava steps through those parts of flights you'll also see that it responds it actually you know tries to gamble the rocket motor it opens up those fins these tests were absolutely crucial in working out some of the bugs before we flew scout e and i super recommend you do it if you're doing some type of similar project you can even keep it pretty simple we're just injecting a lot of fake noise into some of the sensors and then we really only care about like altitude and position and those are easy enough to simulate i mean we literally simulate them in the beginning of this video in like the little arduino landing simulation it's like fairly easy code to run you can just set it up in your flight computer software so as far as hardware goes that pretty much completes this section of the video you know i didn't film every part of building the hardware but i filmed a lot i hope that helps if you're building something physical like this and before we end this whole massive engineering cut i thought it would be fun if we could poke around at some parts of the code to see how that worked so we have the hardware portion of the video out of the way we've seen how i built scout in the physical form and now i'd like to talk a little bit about flight software you could call it software you call it firmware you could call it i guess those are really the two things but we'll call it flight software that is what runs on ava and it's what makes all of this stuff work it's what brings it all together that's really where i consider like the secret sauce to be or like the magic of trying to land one of these rockets it's all in software so i figured we could take a look at a couple of specific things first starting with the state machine just some housekeeping here we're editing in visual studio code or vs code and this is all using platform io which basically lets vs code work with an arduino environment and compile for arduino ava essentially operates as three arduino computers working together so you can call it c plus you can call it arduino both of those are technically correct that's what language we're working in here the loop function is what's going to execute all of our code as we fly the rocket there's a setup function where we take care of some like startup stuff but the loop function is where it really happens at the top of the loop function we have our functions that are going to run no matter what these are the things that we need to just continuously do all of the time so we have time keeper which tracks like how much time has passed since startup how much time has passed in flight we have state indication those are our leds and buzzers so we need to know what the computer is doing even if we can't see the telemetry screen we have read battery oops read battery which is pretty self-explanatory we're just looking at the voltage of the battery there update pyrostates is a thing that looks it does analog reads on the voltage dividers on each pyro channel so we're looking at each one to detect is there continuity on that channel is there basically some type of charge or device connected up to it and then we log those and also beam them over telemetry which speaking of which is the tlm update function here so this is sending data to the telemetry computer which then sent it to the xp which then sent it to the other xp which then sends it to the ground station so that we can see it finally or actually not finally we've got two different functions here sitl nav update and nav update if i uncomment this you can you can see that that is a legitimate function so only one of these can operate at a time you'll see it actually throws an error when we do that too but only one of these can operate at a time so this is the software in the loop navigation computer which is not real but it's simula it's like a physics engine that injects fake data into ava's control code and then the actual nav update function is the thing that pulls the navigation computer for position velocity attitude rates all of that stuff so when i want to turn on software in the loop i do two things i set sitl enable in the settings i set that to true instead of false and then i enable this function right here and comment out navigation update or nav update but we're not going to do that now this is just explaining what's going on finally we read the backup imu this function doesn't do a whole lot and i don't even think we're logging the backup imu because we prioritize other things for the landing rockets so this is like an entirely useless function by the way this is all the flight code that uh was compiled and run for flight 2 but this is virtually identical to the code that ran with flight 1. so for the state machine this is the code that's going to run conditionally at different parts of flight so this is pretty obvious this one's ground startup system state if it equals zero we're going to only run these things we're going to exit the if condition there is no else if here but the system state like this won't return true for anything else so we'll basically head back up to the top of the loop so in the ground startup we calibrate our gyros we set all pyros to low we detach the fins up top we log a little bit of data and then we try to detect if the navigation computer is converging so the other thing that each state has is an exit condition at least one some states have multiple but it's a way to get out of the state and so the exit condition for this is detect nav converging if we have been looking at the navigation data and it looks like it's converging so that might look like non-zero latitude and longitude that might look like looking at our covariances for the common filter if those start going down or if those start basically becoming more accurate that means we are converging the filter is getting better over time and so that's going to push us into the ins converging state which is not that much different really the point of doing this is just to get better state indication i don't know if this is like i don't know if this is this stuff is interesting to people um but it's interesting to me so we have detect nav ready which is going to be similar to detect and have converging but it's basically like a more refined version so um does position and velocity are those pretty close to zero does it look like we're pointed upright our acceleration is pretty smooth do we have good sensor data these are like more refined checks and we basically can never enter the waiting for launch like ready to launch state until we have cleared all of those checks and detect navreti and then we do the same things as the state before which is auto calibrate pyrus low etc in waiting for launch we have basically one state exit condition which is predictable it's detect launch and we're just looking at the accelerometers like are we actually you know are we flying actually the funniest thing about detect launch is that's not even how we're doing it here if we go into navcom which is the file that actually lets us communicate with the navigation computer um detect launch is literally just like if digital read of nab sub ss is high um then system state advanced and we've detected launch we literally we read a pin and if the pin is high then we're good to go and the reason we do this is it actually is a little bit faster than any communication protocol it's just a one or a zero from the navigation computer there is a dedicated pin that the navigation computer is the thing that's actually pulling all of these sensors to determine if we have launched so the navigation computer is going to be the first thing that gets a measurement on whether we've launched or not and as soon as that happens it's it's almost like an interrupt we write high on a pin that's totally dedicated that dedicated to that on ava and so that's that's what's happening here um we look for that pin to be high and then we're launched once we launch we do all of the things that you would expect which is tbc update so that is like actually guiding the rocket reaction wheel update that is trying to control the roll axis computing the pid for that flight termination handler is going to be the the function that looks at attitude constraints um versus set points so you know we track our set point we track where we actually are and then we look at the difference between those two things it's almost like the missile knows where it is but if the difference is too great we will abort the flight um we can actually check what those values are here too so this is just in settings these are the fts settings here right so you can see that fts is enabled that's enabling the flight termination system so we we can abort if we need to abort armed time sec is how long fts can happen for after launch this does not include the possibility of fts um that is manually commanded from the ground or fts that is automatically detected um or automatically called at um the point at which we should like the landing motor but this is on ascent we have 1.5 seconds on a cent where we can determine are things working um the abort angle is 40 degrees if we pass that in a second and a half we know we're in trouble if you've you know wired something backwards if you've got really bad gains like you'll you'll probably know by that point the abort distance is also a thing that we check we have a both a box in terms of attitude and a box in terms of position that we have to stay within in order to not violate our abort constraints i was way too generous with this 30 meters is not something that we will ever be hitting with scout in terms of abort distance we will absolutely hit the ground before we violate that so that was probably a little too generous pyro on time sec is just how long we fire any of the pyros for which excludes the landing legs because those fire for about a second um and then like deployed time millis is that's actually that's just what i was talking about uh one second idk lol that's a great comment there and then none of these things are triggered by altitude alone but you can see what everything is connected to so pyro channels 1 and 2 are connected to shoots channel 3 is empty channel 4 is what we use to fire the retro motor channel 5 fires the landing legs and channel 6 does nothing back to the state machine here we've got our flight termination handler detect max out and val that does exactly what you would think detects our max altitude and velocity we also tracked the vehicle mass this is our function that tracks mass and the way this works is that we know the amount of propellant that is in the motor to you know within a few grams we know what the burn time of that motor is we can sort of linearize around like you know it's not going to be the same throughout the whole burn but we can guess we can like just assume it is a a straight curve for those three and a half seconds of burn and so we track the mass during the burn and really what we're doing is we're just subtracting a little bit from the known vehicle mass at each increment we also know our mass at different points of the flight so we can sort of reset the counter if we're tracking mass and things are a little bit off um none of this is entirely needed as far as i can remember i went pretty hard with the mass tracking stuff because it originally we were going to do live simulation as we were coming down and like plot things forward but it ended up not being that important to do so i have a bunch of functions in here that like track vehicle masks and characteristics that aren't really needed oh you know what no this is kind of needed because i think we do some math about it in the tbc update function is that correct i don't even know at this point um my code has advanced beyond me uh also in the launch state we have the pitch over timer which does what you would expect i got to stop saying that phrase i keep saying does what you would expect the pitch over timer um at about a second and a half into flight i think uh just changes our set point to uh negative five degrees in the z axis so we can take a look at that here's our pitch over timer um it is literally this simple we run timekeeper at the beginning of most of the functions that reference either flight time or on time seconds or on time millis flight time millis that kind of thing but if flight time is greater than or equal to pitch over time which i wonder will it show me if i hover over it no it doesn't sometimes vs code does cool things but um if we're greater than our pitch over time we advance the state 1 and it looks like we don't even change the set point so that must happen somewhere else and then we log data fast once we start flying once we're in the downrange pitch state we do tbc update same stuff as before reaction wheel flight termination max out track vehicle mass now we have z-ori pitchover in there we can take a look at what's going on here so we have our pitchover angle in degrees and so this is set in the settings file um i know that it's set to negative five because that's just just what it is uh so we set that to our z ori inertial degrees set point sp then we convert that to radians we try to do everything like duplicated in both degrees and radians so we can log them both we have a couple of internal functions here that deal with the transformation of coordinates through different reference frames which basically means we've got our roll attitude here we create a quaternion that represents that and then we can rotate vectors here so we have our um our set point for y ori z ori and we don't have a roll set point which is fine because these are just pitch and yaw right here we create those as coordinates we rotate those coordinates through the roll quaternion and then out come the body set points the body access set points and that's what we're going to use to actually guide the vehicle so if this thing is rolling out of control while we're going up because we're tracking and guiding because we are um how do i say this our set point is in the inertial frame which doesn't care about the roll so when we are going up we can be rolling and still tracking that set point this is perhaps a good time to say that some of this stuff is pretty hacky there are better ways to to do transformations like this um this works it's fine they're model rockets okay then same stuff as before we've got a data log and then detect burnout is our state exit um that's going to send us to state five we feed it the state that we want to go to so we detect burnout and we go to state five at state five we have burned out so we're gonna do a couple of things differently here we're not going to update the tvc stuff anymore because we don't have a motor to thrust with we're going to lock the tvc but we're only going to lock it once this is a one-time run function which means that as soon as you run it there's like an initialization and then it won't run again so this function will only execute once not continually as the comment states we're going to keep updating our reaction wheel so we're going to keep trying to maintain rule control same thing max out and vel we're gonna zero all of our set points so those set points that we like came up with in the previous state those are all back to zero now and then we eject the ascent motor which is a small little routine that runs whenever you call it as soon as you call it um it's another one that requires like an initial initialization variable um the eject descent motor basically slams i mean you know what it does at this point if you're this far into the video you can you can put it together as the comment states here the ejection also shifts a few um like states of the vehicle that are used as reference so like our moment arm and inertia are going to change when we eject that ascent motor we've lost mass and then we've changed our cg so we track that because we use it to help guide the vehicle in the tvc update function so when we eject the ascent motor that's actually part of the function is we we set our our um i think we actually change our vehicle mass too like we change a bunch of different physical characteristics during this function we also detect apogee which is as simple as saying is our inertial vertical velocity negative and then you'll start to see that we have these detect landing functions here so detect landing can happen in a couple of different ways we can look at very very very tame gyroscopic rates which aren't going to happen in a free fall or powered flight we can look for us being under let's say 10 meters for 30 seconds that would put us into the landing state but at this point once we've launched into the air there are so many things that could happen i start putting the detect landing functions in there just so that we have a way to get out of the state in case something goes really wrong but detect apogee is going to send us into the apogee descent state so that's what we have here we are still updating the reaction wheel still detecting max altitude and velocity which like at this point we're really looking for just velocity on the way down um jack descent motor this is a looks like the comment says just in case we haven't finished this that's unlikely but good to have it there um attach fins it's not going to run twice too because it has that initialization variable so that function will only run once during flight even if you call it multiple times attach fins is where we what are we doing here oh that's right um the servo that drives the fins that deploy at the top is actually it's being driven at 7.4 volts and it really wants five so we keep that thing detached we don't write anything on the pwm lines until it's really time to actually go for it and that's why we're attaching the fins and then deploying the fins so that's easy and then landing burn commitment is quite the function here we can take a look at that in a sec and then we have detect landing and fast fast data log okay so landing burn commitment is a lot um we're just gonna kind of bool through this code and and see what we can find here there's gonna be a lot of comments that probably don't make sense anymore that we're just left in from testing um we have our y and z ori body dag predict which is our predicted oh my gosh how does this work we are constantly predicting our future orientation uh by the gyrocarry4 okay so the gyrocarry forward is a is a variable that represents the number of seconds between when right now is and when the motor could possibly come up to thrust which is about 0.6 seconds so we take our gyroscopic rate we multiply it by 0.6 and the gyroscopic rate is in degrees per second so if we multiply it by 0.6 seconds that measurement is now going to become you know how many degrees we will theoretically travel in the next 0.6 seconds and then we add it to our current attitude in body access and that is like what we predict to be the future attitude of the vehicle so the reason this is important i've talked about it in videos before is that when we're coming down um when we light that landing motor it is it does not instantly come up to thrust so we don't instantly have control when we light it um and if we were for instance like just swinging wildly coming down we want to know that at the point at which we have control we are decently near upright which is gonna be a decent predictor of like do we have a good shot at landing so then we look at the absolute value of both of those things and um if either one of them is violated we call a landing abort otherwise we do not the landing burn altitude as we talked about earlier that's in meters and that is calculated using that little that little polynomial right there then we have a bunch of code that like i might be able to understand um let's find out if the altitude so that's x position inertial that's our vertical altitude if we are less than or equal to our landing burn altitude and if we are greater than but not equal to if we are greater than the landing burn altitude minus 1.5 so we're just looking to be in a range like a very close range to the landing burn altitude this should never be tripped but i guess it's like a small safety thing if we're in 1.5 meters either we're gonna fire the pyro or we just move states maybe we move states oh this is me like writing out theories um if landing abort is zero um then we have landing is go this is a redundant variable um this code i get to i get to hide behind the excuse of this code was written a year ago so i'm better now who wrote this uh so if the landing abort is not zero landing abort called out of abort limits um and we advance to state 42 state 42 is our abort state um and then otherwise we are go for landing and so we advance the system state so that's just how a landing happens and then otherwise if we don't um pass this criteria um then the other thing we do is we're too far below the burn altitude we were never going to make it anyway and we also go to state 42 which is the abort okay so that's quite the function but basically that is our state exit condition apart from all of the other aborts we can either go to the next state or we can go to state 42. so let's say we go to the next state we have landing burn startup so we're turning on the tvc update again we're starting to do a little thrust factor control we keep the fins deployed deploy fins actually works on velocity at this point now so when we deploy fins initially it has it keeps them out regardless of state and at this point the deploy fin function is looking to see if we are greater than absolute four meters per second air speed so um once we drop below that the fins are automatically going to go back in the vehicle that's handled within the fins function we have a reaction wheel update sorry i keep having things in my throat ah minor derailment there fire pyro4 landing burn this is what fires the landing burn pyro so this is a simple function we just we hit the gas find peak excel this is a function that's going to run after we fire that motor that function is going to look for the absolute peak of acceleration that you've seen in all of these f-15 thrust curves now so when we hit that peak that's our reference for where we are you know how long that ignition delay was um and then we can use those two things to decide like how much do we need to throttle how much do we need to divert so that's what the peak excel does we also are starting to track vehicle mass again because right we're burning that motor we need to track the mass as we're burning i don't think these comments are true anymore find peak excel within that we run a landing sim no we don't we use that to calculate divert sort of when we shift to the next state right before we switch gains we do switch gains there's a lot of gain switching that happens basically we're turning on and off like position control velocity control we'll get into that a little bit more later once that's done we begin the divert and move to the next state so i think the next state is where we actually execute that divert maneuver so in the next state this is when we've actually begun the divert maneuver we have tvc update reaction wheel update deploy fins all of our favorite little functions right there and we have execute divert track vehicle mass and then fire pyro5 landing legs which looks like if we are below 6 meters we just hard-coded this in here i think at this point i was pretty much done with like proper software dev and i was like screw it if we're below 6 meters fire those legs but let's take a look at the execute divert function so this one's also a bit of a doozy uh so we have our time keeper our favorite little function right there divert time elapsed flight time sec minus divert start time so this is uh gosh i'm not even going to explain all of this you can you can figure it out for yourself i'll try to explain it at a high level if divert time elapsed is greater than zero oh we run the same code in the um arduino code that i showed earlier so this is just creating a sine wave um and i think we create a sine wave with an amplitude of one we don't even create anything is that true um then i think we maybe multiply that sine wave by something gosh i shouldn't be talking like i am as unfamiliar with this code as you are okay i am pretty sure this is just giving us a sine wave with an amplitude of one and then we use that sine wave down the line we use that as a multiplier um it's also possible that like this stuff is covered in the comments and i'm just too lazy to read it if retro bleed percent is greater than zero so we do have to do this because sometimes there are some like weird edge cases where the bleed percent is less than zero and we're going to hit the ground but if it's greater than zero then the target angle is oh this is this is the stupid thing where um the bleed percent is not actually representative of the actual percent we're bleeding off it's just representative of the percent at the peak of the sine wave so that's what's happening here we do a little a cheeky little a cost function little a cosine and uh that's what's happening all right then we have the bleed limit at 35 degrees that's a hard-coded value we convert to radians if the bleed target angle radians is greater than the limit then you cap it same thing if it's less than the negative limit then you cap it time keeper again probably unnecessary all right if t now millis minus sign sign timer preview is greater than oh this was awful um i ran into all of these problems where if we updated the function fast enough we weren't able to interpolate this is going to be hard to explain basically in here we set both attitude and angular rate set points so we're not just tracking the attitude of a sine wave we're tracking the angular rate through the sine wave and the way that i did this is i like generated the attitude set point first and then i tried to interpolate between the previous and current attitude set point to get the desired angular rate and i couldn't make that work um if it was happening like almost instantaneously because you start running into all of these errors with like floating point numbers that aren't represented with more than seven total digits i think um and so basically i only allowed this function to run once every 20 milliseconds um two milliseconds is not correct that comment is wrong this is a 20 that is absolutely a 20. and so the the signal became smooth enough once i like made it run slow enough um that's a that's that's a hack uh there's a bunch of stuff where i try to work with like micros instead of millis to make it work and i don't remember i don't think it did because we're clearly using milliseconds here uh here's where we multiply the target angle uh dag which is the total target angle so like if we had a bleed where we wanted a 21 degree divert that 21 degrees that bleed target angled egg is going to stay at 21 but then we're gonna multiply it by that sine wave between zero and one and that sine wave multiplied by the total amplitude is going to give us the sine wave of the correct amplitude for our set point so it's a z-axis inertial degree set point um okay then we turn it into radians because guidance um [Music] gosh this is the craziest thing then we we have these huge variables that represent the delta which is our angular rate um i'm not even gonna i'm not even gonna touch this uh so then we generate our z gyro inertial degrees per second set point and we probably turn it into radians per second at some point we clearly don't do it there which is a little concerning uh and then a lot of the same stuff we've seen before which is that we take those values we rotate them into the correct frame we're doing a lot of the like actual hard guide and stuff in the body frame because if we roll we still want to have a successful flight we don't want that to be dependent on the reaction wheel so we have to rotate into the body frame before we actually do guidance things uh there's a bunch of comments let's see what they say switch gains here need to generate sine wave need to scale oh these are just like notes for as i was building the function need to scale that sine wave to the bleed off percentage need to turn that into set points yep i do that sine wave time 1.8 how long we run the divert function this is weird at first but let's walk through the math in the matlab sim divert lasts 1.8 seconds but it started at 2.5 oh this is a mess we subtract 0.6 which is the fixed peak time and get 1.9 never mind this is a idea we're gonna go off a peak time this is great i'm glad i keep these in here because i i totally i mean i have no remembering like i don't have any memory of this um and then it looks like here at a certain point in the sine wave we zero all of the set points oh yeah because at the final point of the burn we don't care about executing executing the sine wave perfectly what we care about is nulling out our horizontal velocity and our angular rates and if all goes to plan that's actually going to give us a pretty close approximation of the rest of the sine wave but we cut the sine wave off a little bit before it finishes the full period of the wave so when that happens we update our k matrix which is basically the set of gains that we use for guidance so ori gain 4 gyro gain 4 position gain 4 velocity gain 4 and then we change our gain set to 4 so that we log like which set we're actually working with let's see these gains that brings velocity gains brings back velocity games along with the y-axis uh it's here to null out that extra velocity and get us ready for touchdown still no y position we don't care about it this is two seconds after yeah that makes sense we advance the system state we zero the set points and we're good that's quite the function so that's the execute divert function and that's going to send us to the next state which is terminal guidance settling maneuver we've got tvc update we've got reaction wheel update retract fins at this point we're forcing the fins back into the vehicle the settle maneuver is basically changing our gains to like do one of two things it's either going to high prioritize our horizontal velocity which we do try to null at the end and then finally within like the last 0.2 seconds of the burn which again we can do because the burns are very consistent within the last 0.2 seconds of the burn we go to gain set number five and gain set number 5 is like fully prioritized on just angular rate control so knowing those angular rates because we're probably going to have a little bit of a drop so we want to hold our attitude and have no angular rate we don't even try to correct our attitude in that last gain set um it's just angular rate we're also still tracking vehicle mass at this point which is kind of funny to me but like yeah go off uh we've got fire pyro 5 landing legs you know for firing and at this point we're probably in trouble but good to have it there and then finally we land um it looks like i think the settle maneuver is what kicks us into state 10 here we land we lock the tvc mount look for shoot inflation oh this is this is uh this is definitely from some other type of flight um but yeah no we've got detached fins shut the reaction wheel down and then we move into our landing detected state which is just gonna like that stuff is boring it's just data logging stuff um but yeah that is the state machine for the scout flights um i hope this is interesting to see obviously there's a lot of code within all of these functions and although i did do a lot of this project last fall most of this code like most of the architecture for doing this i am comfortable with because i have been doing it for like five six i i don't know i've been doing it for several years now and i've come up with a way of doing that feels very comfortable to me um and so like this looks like a whole lot to build for one project and for one project yep it is um but a lot of the stuff is ported from sprint um you know a lot of this stuff is is exactly the same as it was for sprint and then we just add a couple of extra functions so this pretty much brings us to the end of our engineering cut for scout e i hope you enjoyed it um i can't think of anything else that i would want to cover at this point and honestly if if i can think of anything else i'm probably not even going to include it because i am i am done editing this video let me tell you as you may be aware we are doing another version of this rocket it is not going to do the sine wave divert like scout e did we're going to try to actually throttle the solid motor and i haven't landed on a way to do that yet but just so you know this isn't like a this project is over kind of video this is just like the point here is that i spent a bunch of time coming up with this really interesting way to try and like throttle with the solid motor and i'm still convinced that it can work you can look at those simulations at the beginning of the video again i'm convinced it can work someone just needs to like grab the torch and carry it over the finish line so i hope this video helps if you're trying to do that if you're not trying to do that you're doing something similar i hope it helps if you're not doing anything similar at all maybe it just helps you pass the time i don't know uh but thank you very much for watching this is certainly a long one and i hope to see you guys soon so my name is joe barnard may your skies be blue and your winds below [Music] [Music] [Music] you

Channel: BPS.space

Views: 183,949

Keywords: BPS

Id: QM6tvAVNLnk

Length: 137min 52sec (8272 seconds)

Published: Thu Oct 21 2021