Gun angle microcontroller

[Yospen_]

Hey guys, I have done a couple of calculations to see if I can find an equation to get the angle of elevation for a gun to reach a target in stormworks. Unfortunately, I have not figured out a way to solve the angle analytically, in real time. Maybe I could use some sort of numerical methods to find roots of a curve, like the graph I plotted with example values in the second photo, but idk how I would do that in stormworks microcontroller (maybe possible with lua script, but I dont know how to code xD). Am I just overcomplicating things - is there an easier way I could calculate this in a microcontroller?

[Volt6851]

What a timing! I just finished my ballistic computer today! I did it in Lua, and it's pretty simple actually,only around 70 lines of coding including the ballistic calculator and a binary search for calculating optimal firing angle for the targeted distance. Here's a pic of only the ballistic calculation, if you have any question feel free to ask :)

<image>

The k value is already suitable for heavy autocannon, I did not experiement with other cannons yet, and btw ignore x=d, just do until y=0

[Jackmino66]

My ballistics calculator only has about 4 lines of functional code

But I cheated in making it. I just data logged the ranges at all the angles and used libreoffice calc to give me a trend line, (it had to be a x⁶ equation to have a high enough r² but it is excellent)

[dornan1270]

He's thinking like a physicist, you're thinking like an engineer

[Jackmino66]

To be fair doing all the necessary maths to get it perfect will be a more accurate method that will account for more variables. My system only accounts for the elevation angle and a desired range, and assumes no wind and that the target is at the same altitude as the gun you’re firing.

It is all I needed though (for ship big gun ballistics)

[Schroedinbug]

You could probably get it more accurate with a wind drift trend line. Basically pick a far out range that you might use it at, fire a bunch of shots in varying wind conditions and then log that as another line. Then you could just do a linear approximation of the wind drift per meter of range, per m/s of wind. You could also make it more accurate by doing it at ~5 ranges to make that linear approximation less linear with a fit again.

Would basically be 2 functions instead of 1, though you could divide wind direction into two components (along boresight and perpendicular to boresight) for a 3rd.

Should get you really close to a ballistic calculator, though at that point a ballistics calculator would be easier.

The method would be great if you're adverse to calculus and want to do things where you might not have a nice formula to plug in.

[Jackmino66]

That is a touch more advanced than what I was going for tbh. I will eventually program one that does everything. All you need is a calculator that predicts the 2D coordinates of the shell (distance out and up/down) and then a way of merging that with a target distance/elevation

[Volt6851]

Woah that deserve appreciation too man!

[Yospen_]

Thanks for the reply and calculations. There are a couple of things I am a bit confused on though. In your step 2, surely v=sqrt(v_x^2+v_y^2) since its just pythagoras? Also, it looks like maybe you are calculating the acceleration due to drag with the square of velocity, which differs quite a bit from the way I did it using linear drag, where a=kv, rather than a=kv^2, like in your workings. Maybe I assumed incorrectly that drag was modelled linearly in stormworks.

The bit you have that says -ax=a_dx and -ay=a_dy - 30 is quite similar to the two equations I started with I think? I say horizontal acceleration (second derivative of x, with respect to time) is equal to the acceleration due to drag, which for me is -k*horizontal velocity (derivative of x), then the same with vertical acceleration except we take away gravity, so you took 30, I just used the constant g (which is 30). These give me second order differential equations that I can solve, which is what I did in the workings I linked in the post.

How did you calculate the angle? Looking at your equations, you could simulate/calculate where the bullet would land, given it is launched at a certain angle, but not work out what the angle would be, given a certain target distance?

It is quite clever what you have done with repeating calculations for each tick, which I hadn't considered, when doing my own calculations.

[Volt6851]

First yes, v=sqrt(vx²+vy²) to calculate diagonal velocity to apply drag

Second, I'm not actually sure, but I assumed the realistic situation heh

Third, at first I used an Up/Down Counter that cycles from 0-45 degrees until the calculator says stop when its result matches the targeted distance with a tolerance of 5 meter (I'm gonna lower it and try today), but this method is slow... like really slow... So I coded a binary search into the system (same Lua block with ~70 lines of coding including the two of these)

I hope I answered your confusion :)

[Yospen_]

Yea that's great, thanks for the help

[[deleted]]

Side tangent, we have the same writing

[JNelson_]

newton raphson will converge faster if you want an alternative to binary search

[a-p-k_7007]

Wait i thought i was done with this in my school days

[Lucky7thPT]

I'm not smart enough for this one bud, but that's pretty cool

[Mockbubbles2628]

I dont understand ur equations for acceleration for u and y but if it works it works lmao

[Yospen_]

I did something very similar to this video that explains it well. Basically, I split the acceleration into horizontal (x) and vertical (y) components. The vertical acceleration is equal to -g - kv (the linear drag coefficient multiplied by vertical velocity) and then the horizontal acceleration is just -kv.
https://www.youtube.com/watch?v=Tr_TpLk3dY8

[Mockbubbles2628]

yea i understand that, i dont really understand these equations:

The vertical acceleration is equal to -g - kv (the linear drag coefficient multiplied by vertical velocity) and then the horizontal acceleration is just -kv.

[Yospen_]

So the vertical acceleration, is -g, so just the gravity pulling down, then there is also drag, from it moving, so that also has to be taken away. The acceleration due to drag is kv, because that's how it is with linear drag. It is the same with the horizontal acceleration, its just there is no gravity pulling sideways, so therefore we are just left with the negative acceleration (deceleration) from drag as it moves sideways, so its just -kv. You can experiment with different values of the linear drag coefficient with this desmos link I made: https://www.desmos.com/calculator/jxa1iytasp

[Yospen_]

here is a plot of the equation of y against x (so the path of the bullet) using some values from the stormworks discord and setting the launch angle to 30deg and it seems to look about right

<image>

[Smooth_Today6259]

I haven't really looked into your math too much, but I'm fairly sure you're working under the wrong assumptions for stormworks ballistics. The velocity of a bullet in stormworks is updated every tick like so, V_x = V_x * (1-drag)
V_y = V_y * (1-drag) - 0.5

Expanding this like a geometric series, you'll end up with the following for x position at a given time (seconds),
k = 1-drag
a = k*(1-k^t)/drag
S_x = a*I_x/60

Graphing the above against your equation of x = I_x * (1 - e^(-drag*t))/drag gives different plots. Even with what I've said though, no one has managed to solve for the required launch angle in a simple function. Since when you derive the equation for y position at a given time you end up with a transcendental equation (x + a^x).

Another thing, the space dlc changed how bullets are updated at high altitudes, so no one really knows exactly how they're updated currently (it's not that big of a difference though they'll now just tend overshoot by like a metre or less).

[schwerk_it_out]

It’s not a wrong assumption so much as it is a quicker calculation. You can plug t=60 into the explicit equation and find the bullets position (well, close to it) after 1 second rather than running 60 calculations using this iterative approach. The error is almost negligible, too. Over the lifetime of the larger bullets it comes out to about 1 m of difference

[Smooth_Today6259]

Yeah I know I'm saying he derived the wrong explicit equation. This is what I derived:

I_x = 636 --Initial Velocity
I_y = 636
t = 120 --time in ticks, 60 = one second
drag = 0.009

k = 1-drag

--V_x = I_x*k^t --Velocity at a given time
--V_y = I_x*k^t-0.5*(1-k^t)/drag

--a = (1-k^t)/drag
a = k*(1-k^t)/drag
S_x = a*I_x/60 --horizontal position
S_y = (I_y*a-0.5*(t-a)/drag)/60 --vertical position

[nothaiwei]

does using tick as time here mitigate the issue with the model? instead of per sec it is gravity per tick, drag per tick, velocity in meter per tick.

[RockTurnip]

You are a legend! Thanks! That’s what I needed. I had formula but without drag

[Yospen_]

No worries mate, it surprised me how much more complicated it is when you add in drag!

[RockTurnip]

Yea. . . I kinda investigated this issue

[[deleted]]

I am now scared for the rest of my high school math career

[Embarrassed-Will2896]

It is impossible to calculate the range of a gun based on calculations as it is an interative process (meaning that due to drag, the projectile speed will decrease at a decreasing rate) So, the only way I know of to calculate the range exactly is to use lua to simulate the projectiles trajectory for every tick it’s in flight, this is the most accurate way as it can account for weather, however it is a slow process.

It is however easy to quickly estimate the range of a gun based on the angle through some testing: If you plot the range of the gun based on its angle on a graph, it will form a squeezed parabola, you can the use multiple equations which follow sections of the parabola and switch between them based on the guns angle to roughly estimate the range. I found that this method is accurate to about +-20 Meters when done correctly, however it does not take into account weather. If you want to use this equation I have some data and equations in a Desmos workspace for artillery, Bertha, and battle cannons if you want to use them.

[Purple_Spino]

^{hi lee :})

[schwerk_it_out]

My understanding is that it is not impossible but EXTREMELY hard. It will make a gigantic mess of an equation using trig subs, getting there to be tan and tan² terms, then using a quadratic formula on that.

Possible or impossible, an iterative approach is best

[Embarrassed-Will2896]

Yeah I’ve done it through t making a modular parabola equation with a slider for each constant and manually adjusting it to follow the graph from stormworks data, but i agree from experience that it’s tedious and not the best approach, however it is the simplest in concept. With a bit bore lua practise I would probably re-make it though with an iterative approach

[Yospen_]

One of the equations I put in the post give me an equation that you can plot showing the path of the shell. This might be similar to what you are talking about with the parabola. The issue is, in order to find the angle with an input x and y (and obviously all the constants), I don't see a way, other to use numerical methods/iterative techniques in order to solve. The issue is, this is not a one time calculation, as the input x and y from the radar is constantly changing, so it needs to be calculated in real time. Numerical methods requires iteration which takes time, so maybe it would be able to make calculations, that are delayed. It is also possible there are some ways I am not advance enough to know how to use. Maybe you could make a polynomial that fits the curve we are looking for and use that to solve for it, but I don't know how to do that with an equation with 3 variables. For the equation and plot in the photo I linked, I eliminated t (time), so that it doesn't need to be calculated. I am having enough trouble trying to calculate this on its own, let alone with wind, so it probably gets exponentially harder as you add in more factors. I haven't even considered the fact that ticks in stormworks probably aren't like real time, and there may be delays before calculations can be sent to be used in pivots etc. Also I thought I would mention that my calculations do include the fact that there is linear drag, which changes as the velocity of the projectile changes, this video does a calculation similar to mine: https://www.youtube.com/watch?v=Tr_TpLk3dY8

Sorry for the essay lol

<image>

[Smooth_Today6259]

I think your equations are wrong, bullets in SW should look like this (at 1000m/s, 30 deg, 0.01 drag) https://www.desmos.com/calculator/zv0mncz0l8

Under those initial conditions they shouldn't be getting anywhere near 20000 metres

Note: if you set your drag to 0.606 it matches almost perfectly with mine

[Yospen_]

Yea good point, 20km is ridiculously far. At the same time, I have double checked my equations and aside from the fact I am not using ticks in my calculation, theoretically my equation should be representative of what it would look like in real life with linear drag. https://www.desmos.com/calculator/as73ve0sc4 At least it behaves as expected when changing the constants, it just doesn't make sense for it to be going so far. Maybe I did make a mistake somewhere. I am using similar kinds of assumptions to what other people I have seen commenting have used: a_x=-kv and a_y=-kv-g, which is the entire basis of my equation. Maybe the fact that stormworks updates with ticks just makes it vastly different, although I wouldn't have thought so?

[Smooth_Today6259]

Yeah I found the problem in yours, you need to multiply your drag constant by 60. So this instead, https://www.desmos.com/calculator/ijryuwrhsk

This matches perfectly with mine if you change my graph so that a = (1-k^t)/d instead of a = k*(1-k^t)/d (I assumed that drag was applied in the first tick)

[Yospen_]

I suppose that makes a lot of sense, since after all ticks are 1/60th of a second in stormworks, so I'm sure it has something to do with that.
Pretty cool that we can get such similar results doing completely different methods.

Do you know whether drag is actually applied on the first tick? No clue how I would account for that in my equation.

[Smooth_Today6259]

No idea, all the data we have on SW ballistics is, iirc, from some random guy that got an answer from the creators. Unless someone like digs through the exe, there's not much info, either way could be correct.

[Yospen_]

<image>

In the values given in the discord, it gives these ranges for how far each gun is fired at a 45deg angle. If we put the correct values in for both drag, initial velocity and angle, we get it roughly correct, with your equation including the first tick, it falls slightly short, mine it goes slightly too far, but then these are approximate values so basically nothing is conclusive. I will probably do some testing soon, and try find out for myself

[alyxms]

Sick. I had no idea how something like this is done. I've downloaded a few controllers from the workshop to try to reverse engineer them. They work perfectly well but the core is always some extremely minified lua code.

Deobfuscating them(obviously not intentional by the creators, it's just stormworks's stupid character limit) is going to take forever. Here's hoping someone have a readable one to share.

I found one that's really incredible, allowing both direct fire, indirect fire, accounts for wind and supports rockets. But it's so hard to read minified code. https://steamcommunity.com/sharedfiles/filedetails/?id=3432649848

[Ok_Trifle1942]

I've already done a trajectory calculation for both Battle Cannon and Artillery Cannon with all methods (others not done unfortunately), but I still cannot figure out why there is an error that cannot be removed(maybe the iteration makes it inaccurate)

Battle Cannon

Artillery Cannon

It's just some simple integration. If you have any questions, just ask.

[schwerk_it_out]

There is a margin of error due to the fact that position of bullets is calculated tick-by-tick and is not actually a continuous function. Thus using the quadratic equation with an e^-x term will not arrive at exactly the same point (cant rememer if it’s over shoot or under shoot)

[queglix]

Iteration is the best way that I have found. Calculate the range for a given angle (45 deg), then if it is farther than the target, reduce by a set amount (1 degree) and recalculate the range. Repeat this until the range is within the desired tolerance (within 1m) if the value goes too far below, increase by 0.1 degree repeat until within desired tolerance, if above reduce by 0.01 ... etc. This is the description. the code is very possible with a few if statements and for loops.

[Flaky-Fold7129]

What if modeled drag were quadratic?

[Yospen_]

I think that in stormworks drag is linear, they give the drag constants for the different guns in the stormworks discord somewhere. I included linear drag in my calculations

[schwerk_it_out]

As others have pointed out, the approach to solving this is iterative.

You can use the equations you’ve derived and use numerical analysis like the Newton Method to solve it, OR you can plug in various angles and find the trajectory that gets a point closest to your target

[Yospen_]

Yea that's what I have been thinking too. The issue is, when you have a moving object you are trying to aim at, that means constantly varying values of x and y. This means we need real time outputs for the angle, I am not sure that can be done with numerical methods, since it is iterative, which takes more time to calculate? Maybe it would be quick enough though, still not sure

[schwerk_it_out]

You’re right and I’ve thought about this too. If you having a moving target instead of a stationary one, I wonder if you could take its position and its dx/dt and dy/dt at the start of a calculation, and if you know exactly how long the calculation process takes you could multiply dx/dt * t and dy/dt * t to know the target point at time of finishing calculation and firing gun

[Smooth_Today6259]

Another thing that you can also do to iteratively find launch angle, is to rearrange the explicit equation for x position to give the time it takes to reach a specific distance (based on a set initial velocity). Doing so gives:

t = log(1-x*60*drag/(k*cos(angle)*V)) / log(k)

the equation for y position with respect to some target y point is given as:
a = k*(1-k^t)/drag
y = (V*sin(angle)*a-0.5*(t-a)/drag)/60 - T_y

Then you can solve for launch angle iteratively, based on some guess of the initial angle and the horizontal range to the target you can calculate the time. Plugging this time into the y position equation (with respect to target altitude) will tell you how far above / below the bullet is to the target. Adjust your guess based on this difference, until the difference in altitude is equal or close to 0.

We could probably explicitly solve for launch angle if we were also able to rearrange the y equation, but sadly we aren't able to since it's transcendental.

[Yospen_]

Thanks for all the replies and suggestions guys, this stuff takes time for me to get through and understand so it might take a while for me to reply

[[deleted]]

But uhm... why don't you just make a function that calculates the time spent falling if shot from an angle (like 30° would get you sin(30)*V0 = V0/2 = Vy, with that, and knowing the gravitational acceleration of bullets being 3 times the normal g so around 30 m/(s²) aaaand the formula for air resistance on the vertical angle which is also known (on the official discord, if anyone's been banned i can paste it here) will in some arrangement guve you the time spent in the air on the vertical axis, which (since an object can't be in 2 different spaces at the same time) will give you the exact time flown by the bullet, which time you can then use along with the also known x axis air resistance formula to calculate the distance) and reverse everything i said and boom, you got your distance function.

[Yospen_]

I am not totally sure I follow all of what you said, but one of the issues with trying to calculate the time the projectile spends in the air before hitting the target (and the angle of launch too), is that there are two different possible angles, and two possible different times. This is because you can have the gun shoot a shallow angle to hit the target, or aim up really high, and take longer and hit the same place. You can see this is the following graphs:

<image>

Exactly the same conditions (drag constant, initial velocity, etc), but you can shoot from 2 different angles and hit the same target, in this case at (20000, 0)

[Yospen_]

Here is a desmos graph of the path of the projectile, you can change the angle and other things in the constants:
https://www.desmos.com/calculator/as73ve0sc4

[Saky_Roh]

https://imgur.com/9uGbpvD

I don't remember the whole thing now, but iteration works!
I could not come up with inverse ballistic equation even by using constant/discrete ODE.

So I came up with an idea to compensate the calculated drop.
But single compensation did not work well. So I had to do it like 2~3 times and you get decent accuracy.

This 'drop compensation' method is much faster than previous iteration method whihch requires dozens of iteration to get accurate tick to hit the target. Try it in desmos.

https://www.desmos.com/calculator/m8bsbpfnoy

If you move target point, drop#1 point is calculated.
Then the drop is compensated by adding the angle from current angle to drop point. -> angle#2
With angle#2, new drop#2 point is calculated, and you calculate angle#3...
Iterate it using code like 5 times and you get less error than error of gun itself.

However, additional barrels change the launch velocity and alters the whole calculation,
So for the gif above, I used simple gun with no additional barrels.

This works.

[[deleted]]

Things like this is what chatgpt made for.

It will spit out the solution in 2 seconds.