Flight document system for amateur balloons

[TheSkorm]

Need a way to having prediction parameters

[TheSkorm]

https://github.com/projecthorus/sondehub-infra/issues/64#issuecomment-1093701562

[darksidelemm]

Copying this in from the other issue:

For amateur flight predictions I would suggest using the following as the 'default' parameters:

• Ascent Rate: 5m/s
• Burst Altitude: 30000m
• Descent Rate: 5m/s

... however, these will not always suffice. We need an API where a user can submit 'real' parameters for a particular callsign. I suggest this is tied to a callsign, not a 'flight' (which is something covered in another issue), so that the prediction system can work in a similar away to the current sondehub predictions.

The API should accept the following parameters:

• payload_callsign - The payload callsign these prediction parameters apply to.
• float_expected - A true/false flag, which defines if this launch is expected to float. If this is set to true and the payload is on ascent, the Tawhiri 'float_profile' is used when running predictions instead of the regular profile.
• peak_altitude - The expected burst, or float altitude, in metres.
• descent_rate - The expected sea-level descent rate of the payload, in m/s.
• suggester_callsign - The 'callsign' or name of the person suggesting the change. Make this a mandatory field.

We may also want to add as an optional field:

• ascent_rate - The expected ascent rate of the payload, in m/s. ... however, this would only really be useful when the payload is on-ground before launch. I'm not sure if adding in reliable 'on ground before launch' detection is that simple. I would suggest having it in the API, but we may never use it.

I would suggest that when a new submission is entered, it replaces any old parameters for the particular payload_callsign.

Further prediction behaviour (pseudocode):

if abs(current_altitude - ruaumoko(current_position)) < GROUND_LEVEL_THRESHOLD:
  continue # Don't run a prediction.

# Get parameters for particular payload_callsign
ascent_rate
descent_rate
peak_altitude
float_expected

# define the altitude used for burst / float
if (current_ascent_rate > 0):
    if (current_altitude > peak_altitude):
        predict_burst_altitude = current_altitude + 10
    else:
        predict_burst_altitude = peak_altitude
else:
    # Descending. Set burst alt just above current alt.
    predict_burst_altitude = current_altitude+0.05

if (current_ascent_rate < -1.0*ASCENT_RATE_THRESHOLD):
    # Balloon on descent. Use standard descent prediction.
    descent_rate = sea_level_descent_rate(current_ascent_rate)
    standard_prediction(launch_altitude=current_altitude, ascent_rate=5, burst_altitude=current_altitude+0.05, descent_rate=descent_rate)

if float_expected:
    if abs(current_ascent_rate) < ASCENT_RATE_THRESHOLD:
        # Balloon in float. Use float predictor with current altitude.
        float_prediction(launch_altitude=current_altitude, ascent_rate=1, float_altitude=current_altitude+0.05, stop_time=current_time+1day)
    else:
        # Expected float balloon still in ascent. Use float predictor.
        if current_ascent_rate > ASCENT_RATE_THRESHOLD:
            float_prediction(launch_altitude=current_altitude, ascent_rate=current_ascent_rate, float_altitude=predict_burst_altitude,, stop_time=current_time+1day)
else:
    # Standard balloon profile on ascent.
    standard_prediction(launch_altitude=current_altitude, ascent_rate=current_ascent_rate, burst_altitude=peak_altitude, descent_rate=descent_rate)

Suggest:

• GROUND_LEVEL_THRESHOLD = 100
• ASCENT_RATE_THRESHOLD = 0.5

[darksidelemm]

I would also suggest that if custom (per-payload_callsign) prediction parameters have been used, then they should be included with the prediction data, so they can be displayed on the map.

[TheSkorm]

{
"datetime": ""
"payload_callsign": "",
"float_expected": true/false,
"peak_altitude": 28000,
"descent_rate": 2.8,
"ascent_rate": 2.8
}

Going to build an index in ES to store this for the time being. suggester_callsign left off for the time being since we'll manually poke things into ES

[TheSkorm]

![Uploading image.png…]() index made

[TheSkorm]

predictions using flight docs successfully.

I'm thinking for updating the fligthdocs of incorporating aws cognito into the frontend so we can have uses authenicate via that. Initially we wouldn't have authorization but it would allow us to add it in easily later. We also have cognito setup for ES should it shouldn't be too hard to incorporate, and AWS API gateway already supports. Probably the hardest part would be adding it into the frontend.