WURocketry / Electrical_2023-2024

Electrical Repository for 2023-2024 Competition Year
3 stars 0 forks source link

In-depth analysis of velocity lookup table (VLT) #15

Closed breadnmkii closed 12 months ago

breadnmkii commented 1 year ago
pjkirby31 commented 1 year ago

Structure of the VLT (Velocity Lookup Table)

So I think that the structure of the table would most likely be a map of altitudes to velocities. (altitude --> velocity)

The reason for this is because during flight the airbrakes should be able to predict/measure the velocity of the rocket with a reasonable accuracy and precisions (that's a whole separate topic). At first, the rocket will hopefully be travelling too fast and our predicted apogee will be too high, so we need to slow down the rocket. This is where the VLT comes into play.

The VLT will contain an ideal flight plan that reaches our targeted apogee. In this flight plan, the altitude and velocity of the rocket will be known at some interval (maybe every 0.1 seconds). If we use the altitudes as the keys for the VLT, then the airbrakes can work to match the velocity of the ideal flight plan.

I don't think it really matters what the altitudes relative to, as long as we stay consistent in our measurements. However, we should have altitudes mapped from ground to apogee. We probably will not use altitudes that are super close to either ground or apogee, but I think it would still be helpful to have all of the values mapped. To answer your question about "over how much time?", I don't think the times will really matter for the VLT. We will need to take time into account when predicting velocity, but it shouldn't matter for the VLT.

How to create a VLT with simulations

I'll be honest, I haven't looked into this part a ton, I'll still provide my opinions though. I was thinking of two options for this:

  1. OpenRocket/RockSim
  2. Creating and solving a differential equation that models the flight

OpenRocket/RockSim I think using an actual simulation software would be ideal because it will be more accurate than anything we can model on our own. I'm not sure if either software has the capability to export detailed flight data of a simulation, this would be something to talk to William/Aero team about.

Differential Equation The idea for this approach is to use a differential equation to model the rocket's flight, and solve that differential equation numerically. It shouldn't be too difficult to numerically solve the equation with either Matlab or Python. I think the tricky part would be finding/deriving a differential equation that is accurate enough for our purposes. I remember seeing a section in the FRR that contained an apogee estimate from a diff eq, but I forget how well that worked.

General Simulation Ideas To create a ideal flight plan for the rocket, we have to modify an existing flight plan. An existing flight plan would have our rocket's apogee being way too high, so changes would have to be made. On our actual rocket, the only two things we would be able to change are the weight and drag (via airbrakes). I don't think we should be tampering with the rocket's weight though, which is the whole point of airbrakes.

Originally I was thinking about changing either the drag coefficient or the thrust curve for the rocket so simulate airbrakes. I don't know how I feel about these options though, I'll have to come back to this section later.

Designing the VLT

This would really depend on what hardware and software we are using, so I'll give a few options. The main idea will just be using a map, I don't think we need a super complex data structure for this. We just have to make sure the map allows for interpolation between keys. This is important because we won't have every altitude mapped out in the flight plan.

C++ on an Arduino MultiMap: It is designed for interpolation between a sensor value and a usable value. It should allow us to map a sensor altitude to one of our mapped altitudes, then we can find the velocity for that altitude.

Python on a Raspberry Pi SortedDict Here is a StackOverflow question that has lots of ideas

Rust on a Raspberry Pi I didn't find an explicit library that would help with this, but we could use an ordered map and like a binary search to find the closest altitude key

wurdahl commented 1 year ago

This is great. I think generating the velocity look-up table is the next step. I don't know if RockSim/openrocket are the best for this because as you noted you would have to change the drag on the rocket/change the thrust to get it right. I think deriving it from the differential equation might be best. The VLT should start with whatever the initial velocity of the rocket should be and it should be zero at the desired altitude. In between is the problem. The most basic option is just whatever parabola meets the boundary conditions. The more complicated one would be whatever solution to the drag equation meets those boundary equations. One of those is probably where we should start, and we can make improvements from there.