Feedback wanted: "Flight Log" feature for OpenRocket

[neil_w]

I've been developing this idea (i.e. "beating it to death") on Discord for a while, but still only a handful of people have chimed in. Looking for some wider feedback here: this would be some work to implement, so I'm seeking evidence that it would be *compelling* and worth the effort. Or, conversely, that it's not so useful and I should move on.

My central thesis is that OpenRocket does not currently give feedback to the user in the most useful and easy-to-understand fashion. The "Flight Log" is but one attempt to improve this situation, specifically as a better way to present detailed sim results. I have seen many occasions over the years where inexperienced users are getting unexpected results from their sim and don't understand why. I am hoping this would fix it, most of the time, and also provide a better at-a-glance summary of a flight sim to more experienced users.

This would be the first thing you see when you attempt to get more detail on the results of a sim. Exactly how it would be worked into the UI is still TBD (I have ideas but it's not the focus of this poll.)

Here are some examples of what it would look like. All details are still not nailed down, but this is pretty close to my vision. *All* feedback is welcome. If you don't like it, or think it's not useful, please explain below if possible.

1) A simple rocket with no parachute



2) Single-stage rocket with Chute Release



3) Three-stage rocket

 

[K'Tesh]

I like it!!! It might be hard for me to use (currently), but I'm sure that soon I'll be able to find a use for it.

 

[NTP2]

I like the idea, for someone new (or not new) to openrocket that would be super helpful!

edit all the people on the discord are experts on openrocket so that’s why you didn’t get much enthusiasm.

 

[boatgeek]

I feel like I want a poll answer option between the first two. I might or might not use it often, but I would 100% recommend it to relatively new users or people doing L1 certification flights.

 

[neil_w]

I feel like I want a poll answer option between the first two. I might or might not use it often, but I would 100% recommend it to relatively new users or people doing L1 certification flights.

Fair. As always, poll options can't be modified after the fact. Your comment serves fine for my data-collection purposes.

 

[0011001100]

I feel like I want a poll answer option between the first two. I might or might not use it often, but I would 100% recommend it to relatively new users or people doing L1 certification flights.

I'm in this boat. I chose the second option as I lean a little more towards the not as useful. BUT my initial thought when I read the title was different. I was thinking this would be about inputting flight data to compare between the sim and an actual flight. Maybe this could be used to more easily dial in the CD of the rocket or of the parachutes.

 

[John Kemker]

What I'd like to see, in addition to what you're already planning, is a standardized format for importing logs created by other programs, whether they be altimeter logs, or otherwise. Then, someone else can can write conversion programs to convert from whatever format into OR log format. You avoid having to write a conversion/import for every altimeter or other program and let others handle that chore. I'd probably lean towards a JSON-based format.

 

[neil_w]

What should we do with those logs once we import them?

 

[neil_w]

Thanks for the votes and replies so far. I supposed it might have been a good idea for me to explain the very specific motivation for the design of the flight log.

In a nutshell, it is a way to show all the events, warnings, and major statistics of a flight sim at a glance, without a whole bunch of extraneous data to distract. At present there is no other way to get this. You have to go poking around a bunch of places, and trawl through a bunch of data. For trying to understand why sim results don't match expectations, the answer is generally going to be pretty obvious in the log. I am hoping this will help newbies, but also it seems useful for experienced fliers as well. Want to know exactly when your rocket is going to exceed Mach? It'll be right there (not shown in any of the examples, but crossing Mach will be a starred event). Want to double-check whether you're deployment(s) are happening when you expect? Again, it should be right there to see, because the trigger will be given for each event.

To me, all this seems very useful. I'm encouraged by the voting results so far, but do wish that some of the "Don't like it" voters have come in here to explain why (or maybe they have, but if so I can't tell from the responses).

Anyway, that's about all I have to say about the philosophy of the thing. And this post will serve to bump the thread so maybe I can squeeze out a few more votes.

 

[Charles_McG]

<language_lawyer\>
I associate 'log' with a journal or database. Could you call is a Flight (or Sim) 'Report' instead?
<\language_lawyer>
I'm not sure I'd use a feature like this personally - but I can see it's utility.
I do really like the idea of calling out warnings by the time * stage that threw them. I often see warnings in the Sim Summary table that I can't easily place - because it turns out they were happening to a lower stage, not the sustainer.
Placing a warning '!' on the graphs would be a nice option, too. Like the event (deployment, landing, etc) icons that are there now.

 

[neil_w]

<language_lawyer\>
I associate 'log' with a journal or database. Could you call is a Flight (or Sim) 'Report' instead?
<\language_lawyer>

I don't really care what it's called, but to me "log" is exactly the correct word.

I'm not sure I'd use a feature like this personally - but I can see it's utility.
I do really like the idea of calling out warnings by the time * stage that threw them. I often see warnings in the Sim Summary table that I can't easily place - because it turns out they were happening to a lower stage, not the sustainer.

Yes, exactly.

Placing a warning '!' on the graphs would be a nice option, too. Like the event (deployment, landing, etc) icons that are there now.

Could also be good, although to me it is tedious and time-consuming to zoom and pan and generally navigate around a plot, particularly one with a lot of datasets (many Y-axis values and/or multistage rockets).

 

[Charles_McG]

I don't really care what it's called, but to me "log" is exactly the correct word.

OK, I see how the definition fits. I'm a bit stuck on a log being for recording actual flights - inputs and results - instead of sims - but I could easily be a minority.

I haven't looked lately - are the warnings @ the appropriate time included in the sim data export if you have events turned on?

Also, have you considered allowing some ability to select the columns to be included in the numeric columns? Your example shows Time, Alt, V, and a. One I routinely dig for is stability at launch rod clearance. There are tons of plottable metrics available.

 

[neil_w]

OK, I see how the definition fits. I'm a bit stuck on a log being for recording actual flights - inputs and results - instead of sims - but I could easily be a minority.

I haven't looked lately - are the warnings @ the appropriate time included in the sim data export if you have events turned on?

Not sure... if they're not, they should be. But the existing warnings there do not come with any explanatory info, and also are scattered among a very long list of data points.

Also, have you considered allowing some ability to select the columns to be included in the numeric columns? Your example shows Time, Alt, V, and a. One I routinely dig for is stability at launch rod clearance. There are tons of plottable metrics available.

Additional data columns could be configured perhaps.... what is shown in the mockups is what I would propose is the default, which should be most useful at least 90% of the time.

Stability at launch rod clearance is already shown in the mockups.


Someone also suggested that "minimum stability" would be a good additional starred event to add, but I haven't had a chance to add it to the mockups. The event description philosophy is to include relevant stats that go with the event. This IMHO is more useful than having every possible piece of data in a column at left, which just dilutes the useful information and makes it harder to scan.

(argh, just noticed that the second mockup is out of date, *sigh*)

 

[John Kemker]

What should we do with those logs once we import them?

Initially, store them somehow associated with, or in, the .ORK file. Eventually, I'd like to be able to compare actual flights with simulations to see how close I came to the sim. I'd also like to be able to input additional info concerning the flight, such as actual mass/weight, altitude ASL for the launch site, etc.

 

[boatgeek]

Initially, store them somehow associated with, or in, the .ORK file. Eventually, I'd like to be able to compare actual flights with simulations to see how close I came to the sim. I'd also like to be able to input additional info concerning the flight, such as actual mass/weight, altitude ASL for the launch site, etc.

I'm not sure if this is exactly what you're thinking, but the ability to enter a .csv with time and altitude from an altimeter would make it a lot easier to dial in the sim to match actual performance. You'd want to be able to plot that along with the simulation output, I think.

 

[neil_w]

Good thoughts, but no longer really connected to the subject of this thread. Can I suggest filing a feature request over at Github?

 

[Buckeye]

I would call these the "milestones" of the flight, especially since you put the flight time on each.

What are the arrows on velocity? A representation of the velocity direction?

The warnings and resolutions would have to be crystal clear so that they don't generate additional newbie questions like "What is 'discontinuity in body diameter?'"

 

[lakeroadster]

I voted "Don't Like It" because I use the "Export Data" tab in the "Plot/ Export" feature. This gives me all the data in Excel that I can format. I then transfer that to my Fleet Sheet.

 

[NTP2]

I voted "Don't Like It" because I use the "Export Data" tab in the "Plot/ Export" feature. This gives me all the data in Excel that I can format. I then transfer that to my Fleet Sheet.

View attachment 606386View attachment 606389

That is a good idea I might try that for myself.

 

[Starfire73]

I like it!

You're on the right track Neil. Can you make it an exhaustive list and let the events displayed be user selectable (with a default group pre-selected of course)?

I like how you linked everything to the first column, the time axis. Then the three slave columns are next: Altitude, Velocity, and Acceleration - excellent. Then plugging in the description of the events - excellent. Love the WARNING and CRITICAL alerts to!

I would love to see range at landing displayed (as well as descent rate - which you already have) with the ground impact description. Mach number (and alert), all that kind of stuff.

 

[neil_w]

You're on the right track Neil. Can you make it an exhaustive list and let the events displayed be user selectable (with a default group pre-selected of course)?

I'm not sure if there's a reason not to just always include *all* events. There aren't that many, and they're all interesting (I think?). Can you think of specific examples of events that would not normally be displayed?

A separate question is whether to allow for additional columns of numbers on the left... too many and it loses the simplicity and clarity that is its reason for being. But I dunno.

I like how you linked everything to the first column, the time axis. Then the three slave columns are next: Altitude, Velocity, and Acceleration - excellent. Then plugging in the description of the events - excellent. Love the WARNING and CRITICAL alerts to!

I would love to see range at landing displayed (as well as descent rate - which you already have) with the ground impact description. Mach number (and alert), all that kind of stuff.

Range at landing is a good one to add. Before finalizing I would probably want to let folks review the complete set of events, and what data are reported for each one, so we get it all covered.

Thanks for the feedback!

 

[Charles_McG]

Range at landing is a good one to add. Before finalizing I would probably want to let folks review the complete set of events, and what data are reported for each one, so we get it all covered.

Range and bearing. I use the plot with distance N and Distance E. And the multilevel wind add on. Bong teaches you to respect the wind.

 

[Tobor]

I'm late to the party but I like it!

 

[manixFan]

I like it! For mentors working with a lot of new flyers, I think this is an excellent way of getting them used to looking at all parts of the flight. Too often newcomers only focus on altitude and ejection delays. As an RSO, I like seeing the launch rod clearance velocity and stability so readily displayed. The easier it is for new flyers to see important milestones, the easier it will be for them to make better design and motor selection decisions. Even being able to quickly see the effect of a longer launch rod or more nose weight at liftoff is worth the effort, IMHO.


Tony

PS: I agree that this would be most useful for new flyers and users to OR. But with all the STEM activity involving rocketry, that’s a lot of users who will really benefit!

 

[John Kemker]

I kinda like the idea of OR becoming a framework that can support all sorts of data analysis/collection. Anything that supports the design/build/test/record/analyze loop is a Good Thing to me.

 

[neil_w]

I kinda like the idea of OR becoming a framework that can support all sorts of data analysis/collection. Anything that supports the design/build/test/record/analyze loop is a Good Thing to me.

What frustrates me about the current state of OR, and which drives most of my effort right now, is that the program does not do a good job of communicating the vast amount of information and knowledge it has about the rocket design and performance. It'll show plenty of raw data, but largely leaves it up to the user to figure out which data to look at and how to draw meaningful inferences from it. Experienced users generally have it figured out, and know how to navigate through it all, but it's needlessly challenging for new and/or less knowledgeable users.

This proposal is one way of addressing the presentation. There are also significant issues with program organization that make it hard to keep track of things, and with the amount of explanation that is provided with warnings and such. All of these need work. They're not easy to solve, either on paper or in terms of the actual implementation, and the fact that we're running with a very small team working in their spare time makes even more difficult to get "big" solutions into the app. This one feels a little more tractable to me than some others which is why I'm focusing on it first.

And always, suggestions and feedback are greatly valuable to us. And anyone who wants to jump in and help with the code would be welcome.

 

[Charles_McG]

While I’m all about closing the loop from sim data to flight data, I think Neil’s spot on about making OR data easier to access and better presented. At least before tackling data import and sim-flight difference analysis.

Part of this is that I (and I suspect other rocketeers) vary parts of of a rocket over its flight career that can’t be held in one sim. It takes multiple files. So you can’t plot those changes together without merging the data elsewhere.

I use JMP - but Power BI, or Tableau would likely work just as well.

Memo to me: give some feedback on the structure of the export file.

 

[manixFan]

What frustrates me about the current state of OR, and which drives most of my effort right now, is that the program does not do a good job of communicating the vast amount of information and knowledge it has about the rocket design and performance. It'll show plenty of raw data, but largely leaves it up to the user to figure out which data to look at and how to draw meaningful inferences from it. Experienced users generally have it figured out, and know how to navigate through it all, but it's needlessly challenging for new and/or less knowledgeable users.

This proposal is one way of addressing the presentation. There are also significant issues with program organization that make it hard to keep track of things, and with the amount of explanation that is provided with warnings and such. All of these need work. They're not easy to solve, either on paper or in terms of the actual implementation, and the fact that we're running with a very small team working in their spare time makes even more difficult to get "big" solutions into the app. This one feels a little more tractable to me than some others which is why I'm focusing on it first.

And always, suggestions and feedback are greatly valuable to us. And anyone who wants to jump in and help with the code would be welcome.

This is why I think adding features that will be most useful to newcomers to both the hobby and the program will potentially have the biggest impact. Experienced users can figure out how to get the data they need, but newcomers are often intimidated by the interface. The colored warnings are very useful to help new flyers identify issues that they might not otherwise understand.

Another very useful (and hopefully simple) interface improvement would be to auto scale the graphs to certain events. For example, the vast majority of flight simulation plots (like stability vs. time) should automatically end at apogee deployment. Not having to manually scale the graph to exclude the descent portion of the flight would be a big time saver, and more importantly, highlight to new users the part of the graph that is most useful to them.

I'm helping out a local flyer who is working with a school that has over 100 club members that want to do an L1 certification flight. Making OR more accessible to those types of flyers would have big dividends for their success, IMHO.


Tony

 

[BEC]

I like the idea, though I was initially confused about what was being proposed exactly as @Charles_McG was. I, too, think of a log as the stuff I keep in notebooks about each flight of a model (airplane or rocket) rather than a summary of important data in the simulation.

Semantics aside, the idea is growing on me. I know I only really get a small portion of what OR can tell me about a design and its potential performance now just because I'm not in the habit of looking in all the places the information is stashed.

 

[tsmith1315]

Part of this is that I (and I suspect other rocketeers) vary parts of of a rocket over its flight career that can’t be held in one sim. It takes multiple files. So you can’t plot those changes together without merging the data elsewhere.

Yes, some rockets are constantly changing from one flight to another. Often just payload length or nose weight, etc. I haven't found a good way to keep those variations in OR beyond an additional sim, which prevents much of a flight log from accruing.