Was an intergral part of the development team developing Galaxy Onboard, a revolutionary airbourne surveyor software that collected and processed lidar data in real time. The goal of the project was to increase usability from our previous surveying software and to lower the barrier of entry for other companies venturing into the airbourne surveying space.
Starting with my contributions
As this a huge piece of enterprise software, I worked as part of a team to help complete and launch this software. The team included of 2 frontend developers, 1 backend developer, 1 full stack developer (me), 1 systems developer, 1 UI/UX designer/project manager another separate project manager, and a hardware engineer. Unfortunately I do not have code to present here but I will attach images of the UI and briefly explain my contributions to the system.
I will quickly explain a breakdown of the project stack to reference later in the article.
On Flight Lidar Sensor
connects to
Galaxy Box:
C Data Layer:
processes raw data into coded key value pairs
(this component is written in C, I did not touch this component as it was previously implemented.)
Java Backend:
Interpolates data into objects which are stored in a on-system
Postgres Database:
which then the data is sent back to backend, and sent through a
Web Socket:
to the
React Frontend (Typescript)
Any data processed on the frontend is updated to the backends through REST APIs
Flight Queue.
Essentially, the biggest interactive component was a prototype that had been drafted shortly before I started working for Teledyne. It included using a dot matrix of numbers to represent the entire queue, with each row being a flight and each column representing different properties such as progress, queue position, what queue it was in, whether it was filtered, and so forth. The numbers in the dot matrix were essentially status codes that needed to be constantly cross-referenced with the data layer documentation. 🤢
This was my first major task working with the company as the front-end developer, since the one who attempted it before me got severely stuck. My project managers thought it would be better on the front end, so I recoded the dot matrix processing component. To put this in simpler terms, we were essentially bypassing the backend, passing the raw data from the data layer into the front end to be processed, and using the backend to just store the last processed dot matrix. I completed the task, but it was extremely buggy, very hard to work on, and shortly after, I was assigned more backend tasks and learned the system much more in depth. I objectified the raw dot matrix data in the backend, having all the processing happen there, stored it, and then sent just the flight queue object to the front end through the web socket. Whenever the flight queue was interacted with, an API was sent to the data to reprocess the data, which was then stored and sent back to the front end. The efficient part of this solution is that every time the data layer sent an updated flight queue dot matrix, the backend would parse the dot matrix for changes and only update what had been changed to the stored data, as well as with the reprocessing for the API coming from the front end.
Filtering and "refly" controls were added as well. Once I had objects to work with, it was simple; I hid flights in the flight queue depending on a list of parameters chosen on the front end and sent back to the backend through an API. "Refly" was easy as well; if a flight needed to be re-flown, a duplicate flight would be created and added back to the "up next" queue.
Map Component:
When I started the project, we just had the OSM Layer in our map component and very basic, unstyled representations of the Lines and Survey Areas without the Status Strip. I'll quickly list my visual contributions to this component.
If you look closely, the line the plane is on and the next line in the queue are represented by blue and orange strokes, respectively.
The dots underneath the line number depict whether the line has been flown, is up next, or is a refly. There is not an example here of a refly, but essentially, every time the flight is reflown, you add another dot to it. I programmed the logic behind representing the status strips. My manager developed the QC Chunk system for testing what data is correct, satisfactory, and failing, but I had to take the positional data of where the plane has flown on the line, compare it to where the line is, find a percentage from that, and whenever the data quality changed, track that change as a new chunk and send it to the frontend to be displayed as a new data chunk.
Status Panel:
The status panel was just an extension of the flight queue panel frontend object. I abstracted the panel part of the flight queue and made a management system for showing and hiding the status/flight queue panel. If they were both showing, then they would take up half of the screen each. The panel consisted of some graphs using LiDAR, plane, and positional data. I can't specifically remember everything on the status panel, and I do know that a lot of what was shown was surveying industry jargon. I also, unfortunately, cannot find a picture of it.