Glide Computer: Tactical Flight Planning

Library:

• glide_computer_lib/glide_computer_lib.h - Glider performance models and polar curves
• glide_computer_lib/glide_computer_lib.cpp - Implementation
• include/geographic.h - Geographic primitives: bounded coordinates (latitude, longitude, elevation) and orientation angles (azimuth, bearing, heading) with overflow policies and type-safe is_kind constraints

Example:

• glide_computer.cpp - Flight planning simulation

This advanced example implements a simplified tactical glide computer for sailplane (glider) flight planning. It demonstrates how mp-units can model a complex real-world aviation application with multiple interacting subsystems, geographic coordinates, and mixed unit systems.

What is a Glide Computer?

A glide computer is an avionic instrument used in soaring (glider) aviation to help pilots make tactical decisions about:

• Whether they can reach their destination from current altitude
• How long a flight will take given weather conditions
• When and where to climb in thermals (rising air columns)
• Optimal speeds to fly between waypoints

This example simulates these calculations for various glider types and weather conditions.

Domain Modeling

Custom Quantity Types

The example defines aviation-specific quantities:

QUANTITY_SPEC(rate_of_climb_speed, mp_units::isq::speed, mp_units::isq::height / mp_units::isq::duration);

This creates a distinct quantity type for vertical speed (rate of climb/sink), which is different from horizontal speed even though both have dimensions of length/time.

Type-Safe Aliases

The example uses type aliases for code clarity:

using distance = mp_units::quantity<mp_units::isq::distance[mp_units::si::kilo<mp_units::si::metre>]>;
// TODO change to isq::height in V3
using height = mp_units::quantity<mp_units::isq::altitude[mp_units::si::metre]>;

// time
using duration = mp_units::quantity<mp_units::isq::duration[mp_units::si::second]>;
using timestamp = mp_units::quantity_point<mp_units::isq::time[mp_units::si::second],
                                           mp_units::chrono_point_origin<std::chrono::system_clock>>;

// speed
using velocity = mp_units::quantity<mp_units::isq::speed[mp_units::si::kilo<mp_units::si::metre> / mp_units::si::hour]>;

These aliases:

• Make code more readable (height vs generic length)
• Encode domain intent (these are specific aviation measurements)
• Don't sacrifice type safety (still checked at compile-time)

Complex Data Structures

The glider is modeled with its performance characteristics:

// definition of glide computer databases and utilities
struct glider {
  struct polar_point {
    velocity v;
    rate_of_climb climb;
  };

  std::string name;
  std::array<polar_point, 1> polar;

Each point on the polar curve describes the glider's sink rate at a given airspeed - fundamental aerodynamic data needed for flight planning.

Geographic Integration

The example uses a separate geographic module that provides type-safe geographic primitives.

Position and Coordinates

// Basic geographic coordinates
QUANTITY_SPEC(geo_latitude, mp_units::isq::angular_measure, mp_units::is_kind);
QUANTITY_SPEC(geo_longitude, mp_units::isq::angular_measure, mp_units::is_kind);
QUANTITY_SPEC(geo_elevation, mp_units::isq::angular_measure, mp_units::is_kind);

// Orientation angles (different zero references and rotation directions)
QUANTITY_SPEC(geometric_azimuth, mp_units::isq::angular_measure, mp_units::is_kind);
QUANTITY_SPEC(geo_bearing, mp_units::isq::angular_measure, mp_units::is_kind);
QUANTITY_SPEC(heading_azimuth, mp_units::isq::angular_measure, mp_units::is_kind);

inline constexpr struct equator final : mp_units::absolute_point_origin<geo_latitude> {
} equator;

inline constexpr struct prime_meridian final : mp_units::absolute_point_origin<geo_longitude> {
} prime_meridian;

inline constexpr struct horizon final : mp_units::absolute_point_origin<geo_elevation> {
} horizon;

// Geometric azimuth: 0° = East, counter-clockwise positive, mirrored wrapping [-180°, 180°)
inline constexpr struct east final : mp_units::absolute_point_origin<geometric_azimuth> {
} east;

}  // namespace geographic

// Geometric azimuth: mirrored wrapping [-180°, 180°)
// Note: This must be defined before using 'east' in relative_point_origin
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::east> =
  mp_units::wrap_to_range{-180 * mp_units::si::degree, 180 * mp_units::si::degree};

namespace geographic {

// Bearing: 0° = North, clockwise positive
// Note: bearing = 90° - geometric_azimuth (involves sign flip - cannot use relative_point_origin)
inline constexpr struct north_cw final : mp_units::absolute_point_origin<geo_bearing> {
} north_cw;

// Heading azimuth: 0° = North, counter-clockwise positive (heading = geometric_azimuth - 90°)
// Implemented as a relative origin: offset -90° from east
inline constexpr struct north_ccw final : mp_units::relative_point_origin<east - 90.0 * mp_units::si::degree> {
} north_ccw;

}  // namespace geographic

// Latitude: reflects at ±90° (symmetric wrapping - can't go past poles)
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::equator> =
  mp_units::reflect_in_range{-90 * mp_units::si::degree, 90 * mp_units::si::degree};

// Longitude: mirrored wrapping [-180°, 180°)
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::prime_meridian> =
  mp_units::wrap_to_range{-180 * mp_units::si::degree, 180 * mp_units::si::degree};

// Elevation: reflects at ±90° (symmetric wrapping like latitude)
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::horizon> =
  mp_units::reflect_in_range{-90 * mp_units::si::degree, 90 * mp_units::si::degree};

// Bearing: mirrored wrapping [-180°, 180°)
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::north_cw> =
  mp_units::wrap_to_range{-180 * mp_units::si::degree, 180 * mp_units::si::degree};

// Heading azimuth: mirrored wrapping [-180°, 180°)
template<>
inline constexpr auto mp_units::quantity_bounds<geographic::north_ccw> =
  mp_units::wrap_to_range{-180 * mp_units::si::degree, 180 * mp_units::si::degree};

namespace geographic {

template<typename T = double>
using latitude = mp_units::quantity_point<geo_latitude[mp_units::si::degree], equator, T>;

template<typename T = double>
using longitude = mp_units::quantity_point<geo_longitude[mp_units::si::degree], prime_meridian, T>;

template<typename T = double>
using elevation = mp_units::quantity_point<geo_elevation[mp_units::si::degree], horizon, T>;

template<typename T = double>
using azimuth = mp_units::quantity_point<geometric_azimuth[mp_units::si::degree], east, T>;

template<typename T = double>
using bearing = mp_units::quantity_point<geo_bearing[mp_units::si::degree], north_cw, T>;

template<typename T = double>
using heading = mp_units::quantity_point<heading_azimuth[mp_units::si::degree], north_ccw, T>;

The module defines six distinct angle types for geographic and aviation use:

• Latitude: reflects at ±90° boundaries (symmetric wrapping - can't cross poles)
• Longitude: wraps in half-open interval [-180°, 180°) (exclusive max)
• Elevation: reflects at ±90° (like latitude)
• Geometric Azimuth: 0° = East, counter-clockwise, wraps [-180°, 180°)
• Bearing: 0° = North, clockwise, wraps [-180°, 180°)
• Heading: 0° = North, counter-clockwise, wraps [-180°, 180°)

All types use is_kind to prevent accidental mixing (e.g., latitude + longitude or bearing + heading won't compile). Each has:

• Distinct point origins with appropriate overflow policies
• Custom user-defined literals for coordinates (_N, _S, _E, _W)
• Aviation-style display formatting with prefixes ("Az ", "BRG ", "HDG ")

Great Circle Distance

template<typename T>
// NOLINTNEXTLINE(bugprone-easily-swappable-parameters)
distance spherical_distance(position<T> from, position<T> to)

The spherical_distance function calculates the shortest distance between two points on Earth's surface using the great-circle formula. Since latitude and longitude use is_kind, the function explicitly converts them to plain angular_measure for trigonometric operations:

  const quantity from_lat = isq::angular_measure(from.lat.quantity_from_unit_zero());
  const quantity from_lon = isq::angular_measure(from.lon.quantity_from_unit_zero());
  const quantity to_lat = isq::angular_measure(to.lat.quantity_from_unit_zero());
  const quantity to_lon = isq::angular_measure(to.lon.quantity_from_unit_zero());

This ensures type safety while allowing mathematical operations when explicitly intended.

Waypoint Definition

With these geographic primitives, waypoints become simple and type-safe:

struct waypoint {
  std::string name;
  geographic::position<double> pos;
  geographic::msl_altitude alt;

Each waypoint contains:

• Name (airport ICAO code)
• Geographic position with latitude/longitude using custom literals
• MSL altitude in aviation-standard feet

This shows how mp-units integrates with domain-specific abstractions while maintaining type safety across module boundaries.

Multi-System Units

The example naturally mixes unit systems as aviators actually do:

auto get_gliders()
{
  using namespace mp_units::si::unit_symbols;
  MP_UNITS_DIAGNOSTIC_PUSH
  MP_UNITS_DIAGNOSTIC_IGNORE_MISSING_BRACES
  static const std::array gliders = {glider{"SZD-30 Pirat", {83 * km / h, -0.7389 * m / s}},
                                     glider{"SZD-51 Junior", {80 * km / h, -0.6349 * m / s}},
                                     glider{"SZD-48 Jantar Std 3", {110 * km / h, -0.77355 * m / s}},
                                     glider{"SZD-56 Diana", {110 * km / h, -0.63657 * m / s}}};
  MP_UNITS_DIAGNOSTIC_POP
  return gliders;
}

auto get_weather_conditions()
{
  using namespace mp_units::si::unit_symbols;
  static const std::array weather_conditions = {std::pair{"Good", weather{1900 * m, 4.3 * m / s}},
                                                std::pair{"Medium", weather{1550 * m, 2.8 * m / s}},
                                                std::pair{"Bad", weather{850 * m, 1.8 * m / s}}};
  return weather_conditions;
}

auto get_waypoints()
{
  using namespace geographic::literals;
  using namespace mp_units::yard_pound::unit_symbols;
  static const std::array waypoints = {
    waypoint{"EPPR", {54.24772_N, 18.6745_E}, mean_sea_level + 16. * ft},   // N54°14'51.8" E18°40'28.2"
    waypoint{"EPGI", {53.52442_N, 18.84947_E}, mean_sea_level + 115. * ft}  // N53°31'27.9" E18°50'58.1"
  };
  return waypoints;
}

• SI units (km/h, m/s) for glider performance
• Yard-Pound units (ft) for altitude (standard in aviation)
• Latitude/longitude in degrees with custom literals

mp-units handles these conversions automatically and safely.

Key Features Demonstrated

1. Quantity Points for Absolute Values

using duration = mp_units::quantity<mp_units::isq::duration[mp_units::si::second]>;
using timestamp = mp_units::quantity_point<mp_units::isq::time[mp_units::si::second],

Timestamps are absolute points in time, not durations - correctly modeled using quantity_point with chrono_point_origin.

2. Custom Quantity Specifications

QUANTITY_SPEC(rate_of_climb_speed, mp_units::isq::speed,
              mp_units::isq::height / mp_units::isq::duration);

Creates a specialized speed quantity specifically for vertical movement, distinct from general speed.

3. Dimensionless Ratios

constexpr mp_units::QuantityOf<mp_units::dimensionless> auto glide_ratio(const glider::polar_point& polar)
{
  return polar.v / -polar.climb;

The glide ratio (distance traveled per unit altitude lost) is a dimensionless quantity, correctly computed as a ratio of two speeds.

4. Complex Calculations

The library performs sophisticated calculations including:

• Distance between geographic coordinates
• Time-to-climb to thermal top
• Ground speed vs airspeed
• Safety margins and minimum altitudes
• Multi-leg route planning

All with full compile-time dimensional analysis.

5. Formatted Output

      std::cout << MP_UNITS_STD_FMT::format("  * {::N[.4f]} @ {::N[.1f]} -> {::N[.1f]} ({::N[.1f]})\n", p.climb, p.v,
                                            ratio, si::asin(1 / ratio).force_in(si::degree));

Custom formatting for all quantity types makes the output readable for pilots.

Scenario Simulation

The main program runs multiple scenarios:

• 4 different glider types (from trainer to high-performance)
• 3 weather conditions (good, medium, bad thermals)
• Multi-waypoint tasks with varying distances

For each combination, it calculates whether the flight is possible and estimates the time required.

Sample Output

The program outputs detailed flight plans with proper unit formatting:

Safety:
=======
- Min AGL separation: 300 m

Gliders:
========
- Name: SZD-56 Diana
- Polar:
  * -0.6366 m/s @ 110.0 km/h -> 48.0 (1.2°)

Waypoints:
==========
- EPPR: 54.24772° N 18.6745° E, 4.9 m AMSL
- EPGI: 53.52442° N 18.84947° E, 35.1 m AMSL

Weather:
========
- Good
  * Cloud base:        1900 m AGL
  * Thermals strength: 4.3 m/s

Task:
=====
- Start: EPPR
- Finish: EPPR
- Length:  162.5 km
- Legs:
  * EPPR -> EPGI (81.2 km)
  * EPGI -> EPPR (81.2 km)

Tow:
====
- Type:        aircraft
- Height:      400 m
- Performance: 1.6 m/s

Scenario: Glider = SZD-56 Diana, Weather = Good
===============================================

| Flight phase | Duration                    | Distance                  | Height                |
|--------------|-----------------------------|---------------------------|-----------------------|
| Tow          | 4.2 min (Total:   4.2 min)  | 0.0 km (Total:   0.0 km)  | 400 m ( 405 m AMSL)   |
| Glide        | 2.6 min (Total:   6.8 min)  | 4.8 km (Total:   4.8 km)  | -100 m ( 305 m AMSL)  |
| Circle       | 7.3 min (Total:  14.1 min)  | 0.0 km (Total:   4.8 km)  | 1602 m (1907 m AMSL)  |
| Glide        | 41.9 min (Total:  56.0 min) | 76.8 km (Total:  81.6 km) | -1600 m ( 307 m AMSL) |
| Circle       | 6.3 min (Total:  62.3 min)  | 0.0 km (Total:  81.6 km)  | 1383 m (1690 m AMSL)  |
| Final Glide  | 44.1 min (Total: 106.4 min) | 80.8 km (Total: 162.5 km) | -1685 m (   5 m AMSL) |

Note

The above is just a part of the actual text output.

Each flight phase shows:

• Duration - time for this phase and cumulative total
• Distance - distance covered and total so far
• Height - altitude change and resulting MSL altitude

The output demonstrates:

• Tow - initial climb to release altitude (400 m AGL)
• Glide - descending flight between thermals
• Circle - climbing in thermals to regain altitude
• Final Glide - direct glide to destination without further thermals

All with automatic unit formatting showing proper aviation notation (km/h, m, m/s, AMSL).

Practical Applications

This example is close to what a real glide computer might do (though simplified). Real aviation software needs:

• ✅ Type safety - mixing altitude and distance is dangerous
• ✅ Multiple unit systems - aviation uses nautical miles, feet, meters, knots, etc.
• ✅ Exact conversions - no room for approximation errors
• ✅ Performance - zero runtime overhead from the units library
• ✅ Maintainability - clear, self-documenting code

mp-units provides all of these guarantees.

Key Takeaways

• Complex real-world applications can be fully typed with mp-units
• Custom quantity specifications capture domain-specific knowledge
• Multiple unit systems integrate seamlessly
• Geographic and physical quantities work together naturally
• Type safety scales to large, multi-module codebases
• The library doesn't get in the way of domain logic

This example shows that mp-units is production-ready for safety-critical aviation software where correctness is paramount.