New OpenRocket plugin to allow different wind speed/direction at different altitudes

[rocketsam2016]

Hi folks,

EDIT: The following link will always have the latest version:
https://github.com/rocketsam2016/MultiLevelWind/releases/tag/latest


I’ve written a new OpenRocket plugin that let’s you specify different wind speeds and directions at different altitudes for a simulation. My primary motivation for this is to more accurately predict drift on the way down and choose a good launch rod angle and direction by using multi-layer wind data used for aviation (available for example from the windyty app) . The idea is that at the launch site just before I’m doing a high flight, I can open up the windyty app, plug the numbers into open rocket, and have a better sense about how it will drift on the way down.


Things you should know:

• Let’s call this an ALPHA version. It’s quite possible there are bugs, so please let me know if you get results that don’t seem right!
• This is certainly an approximation! In particular, I doubt the data from any source is all that accurate near the ground. It should be much better though than the assumption that the winds at 5k feet are the same as at ground level.
• The wind data from many sources is given in terms of AboveSeaLevel, meaning you need to adjust appropriately if your launch site is far from sea level.
• This is only useful for predicting drift if your descent rates are correct, so double check that and update the parachute size/cd until it matches reality.
• You don't have to use all the wind layers - just use the number of layers that you want and set the rest to be a higher altitude than the rocket will fly.

How to use:

1) Download the MultiLevelWind.jar.zip file and uncompress it
2) Copy MultiLevelWind.jar to your open rocket plugins directory. On a Mac, you can find this directory by:​

a) Go the Finder
b) Hold down Option, click on the “Go” menu, and click on “Library”
c) Open “Application Support”
d) Open “OpenRocket”
e) Open “Plugins”​

f) Copy the MultiLevelWind.jar file to that folder​

3) Open OpenRocket
4) Create a Simulation, edit it, go to Simulation Options, and click “Add Extension”
5) Choose “Multi Level Wind” under the “Flight” category
6) Configure your winds! The default altitudes are the altitudes reported by “NAM 3km” model in the WindyTy app.
7) Plot your simulation with “ground track” to see the path of your rocket, and edit your launch rod angle and direction to find something that lands where you want.​

Technical Details:

• I use the same PinkNoise wind model that OpenRocket uses by default, but I use a dumb linear interpolation between the multi layer wind points to update the average wind speed and direction based on the altitude. I’ve considered applying a more complex interpolation, but I’m not sure it’s worth it - the data we are working with is approximate at best
• This linear interpolation is probably especially inaccurate near the ground. I’d be cautious about using this with any rockets that are borderline stable.
• I’ll publish the source code when I get a chance. I don’t have much free time though and it needs to be cleaned up.

Enjoy!
Sam

 

[GrouchoDuke]

That's awesome, Sam! I'll try it out.

 

[SpaceManMat]

Nice work Sam I'll have to give it a shot.

Potentially got an upcoming MD flight that I could use it on - only if my work cooperates.

 

[tim cubbedge]

Do you know where the plugin folder is on a WIN10 machine?

 

[isobig]

This sounds very interesting indeed.

 

[Q-Aero]

Do you know where the plugin folder is on a WIN10 machine?

in the Appdata folder, replace the XXX with your user name . It's a hiden folder, you have to unhide it in view option of the folder

C:\Users\XXX\AppData\Roaming\OpenRocket




Wow

 

[SpaceManMat]

Had a bit of a play...

So I put some numbers in for a flight that I will hopefully attempt.
End result says if I angle my launch rod 3 degrees away from the wind I'll get another 60 feet
Also I'm in for over a 1km walk

So a few things that I thought need attention.
1. On a simulation that the plugin has not been used for before, you get an error when adding the plugin. Just need to go in again and it works.
2. I don't like the window title, need to clean that up which I've not doubt your aware of.
3. For ease of data input the order of the fields needs to be changed to match the Windy web site otherwise its a pain to enter, see below. Should be Direction, Speed, Altitude. Or Altitude could be first as this is the control you set in Windy to get the desired wind details.
4. Definitely need more wind layers I used them all up going to 14000 feet.
5. Not sure about this, but I would have though other atmospheric values would/should be entered. Particularly pressure comes to mind.

In all not too bad, does what the packet says it should.

 

[tim cubbedge]

Found it! Thanks Q !

 

[rocketsam2016]

1. On a simulation that the plugin has not been used for before, you get an error when adding the plugin. Just need to go in again and it works.
2. I don't like the window title, need to clean that up which I've not doubt your aware of.
3. For ease of data input the order of the fields needs to be changed to match the Windy web site otherwise its a pain to enter, see below. Should be Direction, Speed, Altitude. Or Altitude could be first as this is the control you set in Windy to get the desired wind details.
4. Definitely need more wind layers I used them all up going to 14000 feet.
5. Not sure about this, but I would have though other atmospheric values would/should be entered. Particularly pressure comes to mind.

In all not too bad, does what the packet says it should.

Thanks for the feedback I really appreciate it! Thoughts inline. Two meta points though: 1) I don't have much free time so bigger changes may take a while 2) This is already a pretty big wall of controls, so I want to be cautious about adding more, since I suspect that many people will feel compelled to accurately fill out every input on the panel, and that gets to be a lot of work

1. I'll take a look at this. May not be something I can easily fix though, and I haven't observed it myself. What's the error and and how exactly do you reproduce it?
2. Hmm so it renders differently on a mac. That long string is gross, but it's also the only way that I know of to summarize the state of the plugin on the active plugins list and that seems useful. Believe or not I played with a bunch of different ways of writing that string out, trying to find something that was as short as possible while still being at least kindof readable. Are you saying you'd rather the title not have the information about the current winds? Or do you have a different idea about how to render all the information as a compact string? I'd love to hear clever ideas about how else to write this all out as a summary in as little space as possible.
3. Good point, I'll play with this. The reason for the current ordering is that in many cases folks may just want to keep it simple and play with only the speeds, so I made speed the first column. As i'm thinking about it, altitude is a kind of "label" for the row, so it should probably be first. Open question as to whether it's then better to have speed next (since that's the variable that people care about more) or direction (since that's the order from windyty).
4. Adding more layers is easy, how many do you want? I added enough to get to my local ceiling . I thought about adding more, but decided that it might not be obvious you don't need to set them all (or that you can change all the subsequent wind layers to some dummy high altitude by making one layer a very high altitude), so I worried it would make the UI more confusing for users. It also means that the summary/title is going to get even grosser!
5. I'm not sure how useful pressure will be, do you mean you want to be able to say that pressure at a given altitude is different than expected? After all, OpenRocket already does (if I understand correctly) model the pressure decreasing as the rocket rises. I'm not sure whether that adjustment is fed into descent rates, but if it isn't now then it is unlikely to be used if I'm updating the pressure on the fly, and the more controls I add the more confusing it gets to use.

 

[rocketsam2016]

Another thing I'd love to get feedback on: are there compelling arguments for why I should stick with linear interpolation or should use some more complex interpolation? As I mentioned before, my sense is that the data we are working with is approximate anyway, so it is a fool's errand to try and add more complicated interpolation since it isn't likely to actually make the result match the reality more closely and adds the very real risk of introducing bugs. However, as you can see by plotting wind speed as a function of altitude (or lateral velocity as a function of altitude), the lack of a continuous derivative looks pretty weird. Further, this results in some odd ground tracks when the wind angle shifts dramatically across a few layers. I'm not just sure that a more complicated interpolation would actually be more accurate even though it would look prettier. For the record, here is the current algorithm:

1. I interpolate speed and direction independently. I am not sure this is right! However, I did it this way because of the following intuition: If the wind speed is 10mph to the north at one altitude, and 10mph to the east at the next altitude, when calculating the wind at the midpoint of the two the two possibilities are:
   1. if I averaged the wind vectors I'd end up with wind pointing to the northeast at 7mph
   2. If I average the speed and direction independently then I get wind to the northeast at 10mph. This seems more realistic to me.
2. I do a simple linear interpolation of wind speed for a given altitude between the wind layer below and the wind layer above. If the altitude is beneath the first layer or above the last layer then I just use the speed from that layer.
3. I do a not-quite linear interpolation for angles since it makes the code much much simpler (to see why, consider the fact that the average of 350degrees and 20degrees should be 5degrees, but a naive average/interpolation would give 185 degrees at the midpoint). I originally had a mess of conditions to try and make this work before realizing it could be expressed much more simply with very similar results for angles that are relatively close to each other. The approach I use is to turn the angles of the adjacent layers into unit vectors, interpolate between the vectors, and then take the angle of the result. In particular, if the directions are d1 and d2 and the interpolation weight between the layers above and below at the current altitude is a, this can be expressed very simply as:

output_direction = atan2(k * sin(d1) + (1 -k) * sin(d2), k * cos(d1) + k * cos(d2))​

As you can see, if k = 0 then this is simply d2, and if k = 1 then this is simply d1. You can see here how close this is to linear between 0 and 90. Neat huh! It gets much less linear if the angles are near 180 degrees apart, but that isn't likely in the input data and it might actually not be a terrible approximation of what is happening if the winds are oriented so differently at adjacent layers.
​

So the question remains - is there any real value to be gained by using cubic interpolation for example and does that gain outweigh the real risk of adding bugs or subtle broken cases?

 

[mccordmw]

I just tried it out. Very nice! As someone who is quite anal about data, this pleases me.

Changed my approximate lateral distance traveled from 125 m to 175 m. Those upper level winds are quite a bit stronger.

 

[SpaceManMat]

Thanks for the feedback I really appreciate it! Thoughts inline. Two meta points though: 1) I don't have much free time so bigger changes may take a while 2) This is already a pretty big wall of controls, so I want to be cautious about adding more, since I suspect that many people will feel compelled to accurately fill out every input on the panel, and that gets to be a lot of work

1. I'll take a look at this. May not be something I can easily fix though, and I haven't observed it myself. What's the error and and how exactly do you reproduce it?
2. Hmm so it renders differently on a mac. That long string is gross, but it's also the only way that I know of to summarize the state of the plugin on the active plugins list and that seems useful. Believe or not I played with a bunch of different ways of writing that string out, trying to find something that was as short as possible while still being at least kindof readable. Are you saying you'd rather the title not have the information about the current winds? Or do you have a different idea about how to render all the information as a compact string? I'd love to hear clever ideas about how else to write this all out as a summary in as little space as possible.
3. Good point, I'll play with this. The reason for the current ordering is that in many cases folks may just want to keep it simple and play with only the speeds, so I made speed the first column. As i'm thinking about it, altitude is a kind of "label" for the row, so it should probably be first. Open question as to whether it's then better to have speed next (since that's the variable that people care about more) or direction (since that's the order from windyty).
4. Adding more layers is easy, how many do you want? I added enough to get to my local ceiling . I thought about adding more, but decided that it might not be obvious you don't need to set them all (or that you can change all the subsequent wind layers to some dummy high altitude by making one layer a very high altitude), so I worried it would make the UI more confusing for users. It also means that the summary/title is going to get even grosser!
5. I'm not sure how useful pressure will be, do you mean you want to be able to say that pressure at a given altitude is different than expected? After all, OpenRocket already does (if I understand correctly) model the pressure decreasing as the rocket rises. I'm not sure whether that adjustment is fed into descent rates, but if it isn't now then it is unlikely to be used if I'm updating the pressure on the fly, and the more controls I add the more confusing it gets to use.

1. It happens every time I take a simulation that doesn't have the plugin and add the plug in to the simulation.
2. Personally I consider the data too complicated to be worth displaying. Also it's not in the same units. If you wanted to keep it say I'd limit it to the first layer. The other thing it does is on the simulation edit screen it makes you scroll across the plugin box to get to the edit screen.
4. I don't think this is an issue as the screen copies down the data from the line before. People will simply add data till they reach their max altitude.
5. Ok thinking about it, pressures effects speed of sound, effects force due to drag. Not sure if there are others but I believe pressure will be the most important.

 

[Voyager1]

Well done Sam. This is a much-needed improvement to an already great piece of software.
John

 

[Voyager1]

There is a sign change when the lateral direction passes through +180 degrees. It appears that lateral direction is output as 0 to +/- 180 degrees, not 0 to 359 degrees. Is that the intention?

___________________________________________________________
TRA #14574
ARA #64, L2

 

[rocketsam2016]

There is a sign change when the lateral direction passes through +180 degrees. It appears that lateral direction is output as 0 to +/- 180 degrees, not 0 to 359 degrees. Is that the intention?

___________________________________________________________
TRA #14574
ARA #64, L2

Are you referring to what you see if you make a plot of lateral direction? The rest of my response assumes that is what you are talking about. I actually hadn't seen that plot option before (face palm). Now that I'm looking at it:

(a) I believe that seeing negative there should be fine (all the math should work with negative angles and positive angles but I'll double check that)

but (b) it looks to me like that plot may not be correctly implemented (in a way that has nothing to do with my plugin). Try the following: make a simulation without my plugin with the wind set to 90degrees and the launch angle set to vertical. That means a wind coming from the east. We expect a rocket in this wind to travel towards 90degrees (to the east) because of weathercocking on the way up, but then towards -90degreees (or 270 degrees, aka to the west) as it drifts down. You can see that it does this in the ground track plot:

However, if you plot the "lateral direction" vs time, it shows it moving towards 0degrees during boost and towards -180degrees during drift:

I don't have time now to find the implementation of this plotting function in the openrocket code though I'll look this weekend. I'm 99% sure though that this is a place where they failed to stick with the convention that 0degrees is north. It's an easy mistake to make - traditionally in mathematics 0 degrees corresponds to "east" (i.e. along the positive x axis), so presumably they area using the standard math implementation of converting vectors to angles rather than the compass versions. I'm pretty confident this is what is going on since I made the same mistake myself at first in my plugin

So in summary, this shouldn't have any bearing on the correctness of the plugin, and you can even use the "lateral direction" plot (with or without my plugin) as long as you convert from polar coordinate angles to compass directions in your head

 

[BlazingAngel665]

Hi Rocketsam,
I'm working on revitalizing the old monte-carlo dispersion analysis plugin for OpenRocket. I know you wrote yours in Java, but would you know anything about grabbing objects using guice and passing them to python? The old Jpype interface is totally trashed.

 

[mikec]

So the question remains - is there any real value to be gained by using cubic interpolation...

When I've done this I haven't done any interpolation at all (which makes the angle code really simple) but I use a lot of layers, up to the resolution of the number of layers of winds-aloft predictions.

Adding a more convenient way of inputting data than typing into the GUI would help add more layers, but even without that, I think better interpolation is unneeded.

 

[rocketsam2016]

Thanks for the feedback I really appreciate it! Thoughts inline. Two meta points though: 1) I don't have much free time so bigger changes may take a while 2) This is already a pretty big wall of controls, so I want to be cautious about adding more, since I suspect that many people will feel compelled to accurately fill out every input on the panel, and that gets to be a lot of work

• I'll take a look at this. May not be something I can easily fix though, and I haven't observed it myself. What's the error and and how exactly do you reproduce it?
• Hmm so it renders differently on a mac. That long string is gross, but it's also the only way that I know of to summarize the state of the plugin on the active plugins list and that seems useful. Believe or not I played with a bunch of different ways of writing that string out, trying to find something that was as short as possible while still being at least kindof readable. Are you saying you'd rather the title not have the information about the current winds? Or do you have a different idea about how to render all the information as a compact string? I'd love to hear clever ideas about how else to write this all out as a summary in as little space as possible.
• Good point, I'll play with this. The reason for the current ordering is that in many cases folks may just want to keep it simple and play with only the speeds, so I made speed the first column. As i'm thinking about it, altitude is a kind of "label" for the row, so it should probably be first. Open question as to whether it's then better to have speed next (since that's the variable that people care about more) or direction (since that's the order from windyty).
• Adding more layers is easy, how many do you want? I added enough to get to my local ceiling . I thought about adding more, but decided that it might not be obvious you don't need to set them all (or that you can change all the subsequent wind layers to some dummy high altitude by making one layer a very high altitude), so I worried it would make the UI more confusing for users. It also means that the summary/title is going to get even grosser!
• I'm not sure how useful pressure will be, do you mean you want to be able to say that pressure at a given altitude is different than expected? After all, OpenRocket already does (if I understand correctly) model the pressure decreasing as the rocket rises. I'm not sure whether that adjustment is fed into descent rates, but if it isn't now then it is unlikely to be used if I'm updating the pressure on the fly, and the more controls I add the more confusing it gets to use.

I’ve uploaded a new version of the plugin here:
https://github.com/rocketsam2016/MultiLevelWind/releases/tag/latest

Sorry for the radio silence, did I mention I'm busy?

(1) I think I've fixed the crashing problem. It only shows up for me if I disable "run out-dated simulations when you open the simulations tab". I also fixed a crash that happened if you copied a simulation.
(2) I've decided I find the title useful so I'm leaving it, but I truncate at 5 levels, and/or after the levels stop having different winds than those below.
(3) I changed the ordering to be altitude, speed, angle. Altitude clearly makes sense to be first. Having direction be second though was less useful, since it's pretty common that the direction doesn't change between levels. It also looked weird since direction has a slider.
(4) There are now 13 levels available, which takes you up to 10km in the NAM model. If anyone wants more let me know, but I suspect that folks going higher than that are using better software than this....
(5) I'm not adding pressure for now for the following reasons: (a) windyty doesn't provide pressure information broken down by altitude (b) openrocket already adjusts pressure based on altitude and the initial surface pressure given by the user.


I also added a bunch of tests that confirmed the math works correctly (phew ).


Finally, I’m switching over to a link for the download so that I can fix bugs and the same download link will see the fixed version.


I don’t have a lot of spare time, but I’m completely game for more feedback. Enjoy!

 

[Joel Tapper]

Hey Rocketsam,
Might be an old thread but thanks for the great plugin.
I want to see the effect of wind on the rocket as it ascends, so I'm trying to edit the plugin to allow it to work on the way up.
Any thoughts on how I could accomplish this? Looks like the wind only kicks in after apogee in stock OR so I might be outta luck.
Cheers, Joel.

 

[Voyager1]

Hey Rocketsam,
Might be an old thread but thanks for the great plugin.
I want to see the effect of wind on the rocket as it ascends, so I'm trying to edit the plugin to allow it to work on the way up.
Any thoughts on how I could accomplish this? Looks like the wind only kicks in after apogee in stock OR so I might be outta luck.
Cheers, Joel.

You could get some useful information from the Cambridge Rocketry simulation software and toolbox at https://cambridgerocket.sourceforge.net/index.html

 

[SpaceManMat]

I’m pretty sure that OR uses wind data on the way up and down.

 

[flxtrnw]

Hi Rocketsam,
First, thanks for the Plugin. Its really cool.
But i want to inform you that the MultiLevelWindModel.java is missing here(https://github.com/rocketsam2016/MultiLevelWind/tree/master/src/net/sf/openrocket/example).

 

[SiboVG]

This plugin is not compatible anymore with OR 22.02. However, @thzero created a pull request to update the plugin for OR 22.02 (big thanks!!). @rocketsam2016 would just need to code-check it to include in the official repo.

I compiled from his branch and here is the updated plugin that works in OR 22.02: .