31
edits
Changes
Jump to navigation
Jump to search
Line 4:
Line 4: − + Line 40:
Line 40: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
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.
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.
== SSI Page ==
== 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.
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.
=== Configuration ===
=== 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.
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}}
{{balloon-footer}}
[[Category: High Altitude Balloons]][[Category: Projects]]
[[Category: High Altitude Balloons]][[Category: Projects]]