Let’s look at how a HAB Bounder can be used to limit where a balloon flight goes during the April 8 2024 Solar Eclipse in Texas. The HAB Bounder will ensure that the balloon flight stays within Texas, avoiding international transgressions. The HAB Bounder will also ensure that the balloon flight is above commercial airspace around large cities and airports. If either of the above conditions are not met then the HAB Bounder will terminate the flight.
Solar Eclipse Balloon Flight Overview
Google Earth Pro Desktop is used for initial flight planning. The solar eclipse path is imported via a kmz file from Xavier Jubier’s website. The boundary polygons are drawn using the ‘Add Polygon’ tool. For clarity, the green boundary polygon is the zone the flight needs to remain inside of. The red boundary polygons are the zones where the flight needs to be above 20 km altitude. Finally two balloon trajectories are generated with of the CUSF landing predictor. The first trajectory shows the desired flight profile where a tandem balloon is used to float the payload at 22 km altitude. The second trajectory shows a possible flight profile if something were to go wrong with the float attempt.
Programming the HAB Bounder
Let’s use the solar eclipse balloon flight plan in Google Earth to generate the Flight.cfg that is by the HAB Bounder.
The first step is to export the boundary polygons. Right-click on each polygon and select ‘Save Place As…’. Using the pop-up dialog, select a name and location to save each as a KML. Google Earth defaults to KMZ, but it is easier if these are not compressed files.
The second step is to open a text editor and begin creating the Flight.cfg file. I usually start with an existing file from a recent launch to avoid having to recreate the header section of the config file. A default Flight.cfg file can also be generated from your HAB Bounder by placing a blank micro-SD card in it and powering it on for a couple of seconds. The later option has the added benefit of making sure the config options are valid for the firmware version on your HAB Bounder.
Once the Flight.cfg file’s header section is complete we can move on to step three, configuring the commands and geofences. For this solar eclipse balloon flight example we have a couple of options on how to do this. The cleanest would be to create two commands, the first has the green boundary polygon that keeps the balloon within the Texas borders. The second command has all of the city/airport exclusion zones we want to avoid grouped into an OrCollection{}. Grouping the geofences this way will make it easy to interpret the Flight.log file by clearly indicating if the flight was terminated because it started leaving Texas, or if it started straying into a city/aiport exclusion zone. This isn’t strictly necessary as you could also look at the Flight.kml or Flight.csv data to determine why the HAB Bounder activated.
Geofence Waypoints
For each geofence, the corresponding Google Earth KML file needs to be opened and the lat/lon waypoints need to be copied over. This is a little tedious as the HAB Bounder uses a slightly different format than Google Earth. Google Earth strings all of the waypoints together and associates an altitude with each. The HAB Bounder splits each waypoint out and only associates an altitude with the geofence, not each waypoint. But the lat/lon format and order are the same.
Geofence Waypoint Pitfalls
By default, the HAB Bounder’s geofence expects between 3 to 12 waypoints. The total can be increased if the boundary polygon has more than 12 waypoints. In this example, the Austin area has 13 waypoints. To do this specify how many waypoints are expected in the geofence (example below). Each geofence can handle a maximum of 128 unique waypoints.
GeoFence: 13 #Austin Area
{
Remain: outside
Altitude: -500, 20000
Waypoint: -97.59928554187853,30.78343757241942
Waypoint: -97.98901443675442,30.68593859868156
Waypoint: -97.88536273688074,30.26787526840682
Waypoint: -98.05386787433844,29.96995827476525
Waypoint: -98.36133668898164,29.75589413547432
Waypoint: -98.72077801148517,29.65089316085586
Waypoint: -98.8099631259129,29.24270143480945
Waypoint: -98.53608945675334,29.1155340741174
Waypoint: -98.07629998103896,29.50585537618366
Waypoint: -97.72924461032419,29.8720692570415
Waypoint: -97.4575596812881,30.14097877028445
Waypoint: -97.34045043225656,30.53934135294476
}Geofence polygons normally need to be closed. This means that the first waypoint is repeated as the last. Both the HAB Bounder and Google Earth do this automatically. But due to floating point math rounding errors (and a lazy programmer) the HAB Bounder will frequently duplicate Google Earth’s last entry. The simplest solution is to let the HAB Bounder close the polygon by not copying over Google Earth’s last waypoint. Failure to do this usually doesn’t result in an issue unless it causes that geofence to exceed 12 waypoints, see above.
Checking the Flight.kml file
The HAB Bounder creates a Flight.kml file when it starts. Initially this file provides a visualization of how it interpreted the Flight.cfg geofence(s). During the flight, timestamped position data is added every ten seconds.
I suggest taking a quick look at the file after a ground test to make sure the geofences were interpreted correctly. Geofence altitude constraints are indicated by extending the boundary polygons from the ground to their target altitude. This works well for this example but might cause confusion if geofences started above ground level. In that case, KML limitations will create a slightly misleading visualization. Click on each geofence in Google Earth to see the actual min/max altitude (pop-up dialog box over DFW).
Files for the Solar Eclipse Balloon Flight
I have included the HAB Bounder’s Flight.cfg file below that I created for this solar eclipse balloon flight example.