Difference between revisions of "Habmc"

Revision as of 18:50, 17 September 2017

REDIRECT HABMC

@@ Line 1: / Line 1: @@
-HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.
+# REDIRECT [[HABMC]]
-== Public Page ==
-The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
-[[File: HABMC_Public.png | 500px | right]]
-== SSI Interface ==
-If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.
-=== Dashboard ===
-This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.
-=== Full Map ===
-This page provides a full look at the flight so far, much larger than the version on the dashboard.
-=== Transmissions ===
-This is a table all parsed transmissions that have come in so far.
-=== Send Message ===
-This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.
-=== Sent Messages ===
-This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.
-=== SPOT Pages ===
-These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.
-=== Iridium Transmissions ===
-This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.
-=== Iriridium Map ===
-This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.
-=== Predictor ===
-This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
-It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.
-=== Charts and Graphs ===
-This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).
-=== Configuration ===
-This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.
-== Technical Background ==
-HABMC is written with Ruby on Rails and Angular.js. While in a previous iteration the backend was written with PHP and hosted on GoDaddy, it is currently hosted on Heroku. We have a Postgres database and use NewRelic for analytics.
-So that the data can updated with minimal latency, we open up a websocket connection from the client to the server. Then, as soon as the data changes on the server, such as when a new transmission comes in, a message is sent through the websocket back to the client that tells it to refresh its data. This refresh is done with a HTTP request, rather than sending the data through the websocket, because HTTP requests are much more developed than websockets. These HTTP requests are able to support functionality like authorization, CORS, and caching easily, in addition to avoiding repeated code on the initial load of the page.
-== History ==
-=== Origin ===
-Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.
-=== First Iteration ===
-The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.
-To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.
-The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.
-In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.
-=== Recent Development ===
-The most recent stage involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.
-Another achievement with the new server was creating a login system, based on Google Oauth. This provided the structural background for separating out who could view or edit what. For example, this let us make it so that only admins could edit the current mission configuration. This login infrastructure required, beyond integration with Google, session control and tables in the Postgres database for both users and various roles. It also needed a way to edit these roles for super admins, which resulted in a page that allowed easy viewing and changing of user roles.
-A few new features also were released. One of these was the ability to plot FAA Zones on maps, helping us plan our way around restricted areas. We also added mission concurrency as an option. When multiple flights are active, users are able to select from a dropdown which flight to view; charts and graphs update accordingly. Additionally, we routed sent messages through the backend. Before, messages would be posted directly to RockBlock, in a completely opaque way. Now, messages are routed through the backend, storing them and providing an additional layer of security for the balloon alongside letting us view historically sent messages.
-We also did a rewrite of the styles, making it look much better on mobile. This also included changing the editing of the parser, which determines the format of the incoming messages. Rather than having a difficult comma separated list that was prone to typos, we moved to a more stylish autocomplete.
-To reduce server load, rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.
-=== Future Plans ===
-In the near future, we will be building a log file analyzer. This will let us upload and explore historical flights, providing a united system of examining our data. We will also be working on active guidance -- systems that tell us which altitudes to fly the balloon at to avoid restricted FAA zones.
-{{balloon-footer}}
-[[Category: High Altitude Balloons]][[Category: Projects]]

Difference between revisions of "Habmc"

Revision as of 18:50, 17 September 2017

Navigation menu

Search