Building the Infrastructure

So the journey has begun as I have started to grind the gears into making a living off of unmanned aircraft. I have booted up the server sitting dormant for months, codenamed WidowLabs, which is running a webserver and application called Tactic. This system was originally meant to start a different type of system, meant for visual effects and animation but I changed it after realizing that it was perfect for what I had it in mind for. It is a digital asset and project management tool so it can be configured to be used for a design and manufacture pipeline, right down to having individual parts all linked to a particular UAS model.

This will serve in the "back-end" of the business, the engineering end where the design and modification of assets can easily change over the course of time, so having a stable and production proven tool such as Tactic is a huge advantage from the get go. Currently the server is running as a test model of how I would be setting such a thing up, previously I had been setting it up for a completely different purpose so there is still those projects and assets in the database, in other words this is not going to be the end product. Very literally an evaluation and demonstration of what it would be in the end.

At the moment Tactic 3.9.0.v01 is installed in the server, this is after a few upgrades since the initial setup. There has been some key advances since then including a mobile friendly interface, so the ability to log in remotely from your phone via the web is a very useful feature. Previously viewing the server on a smart phone, even a Galaxy S3, proved to be very painful. So when the real production server gets setup this is going to be heavily worked on in order to provide an optimal interface, for both internal and client use.

Since this is also going to be connected to the internet, some security is going to installed, even if that means building a cheap firewall from scratch using FreeBSD, multiple network cards, security tools and then use a router, connected to a network switch which is where internal workstations, servers and web tools are located. While this won't be a problem for agencies such as the NSA to crack into, it should provide decent security otherwise. However already in the thought process is to have a network clean from the internet, where the "TOP SECRET" stuff is being developed and only a select few have access to the workstations. The workstations themselves are locked up so there is no disk and USB access, and only two people will own those keys. This would be where the next aircraft is designed in CAD, code and some fabrication. This way nobody other than a select few can even be allowed to SEE it, reduces the "leak" factor a little. However this is thinking too far ahead lol.

In the meantime pretty much any computer system connected to the actual initial start of this business, which is a high powered workstation, an old laptop, a server and a couple smartphones. Not bad for a start up I guess.

The next crucial element to this whole thing is Linux, Debian to be exact. I have been a long time user of Debian and Debian based distros such as Ubuntu. Currently I have Debian 6.0 on my workstation which is soon going to be overhauled and putting the newest version on. The server is running Ubuntu Server 12.04, so again very easy to work with. The laptop has Windows 7 on it so at least it provides an example of what would be needed for minimum specs for that platform. Of course the smartphones are running Android. So while not a pure Linux setup, it primarily is being used for crucial systems operations and provides a consistent system environment with that much needed open source base. For instance it may be useful to develop a UAS specific Debian based OS for easy deployment, plus give customers a copy so in case of worst case scenario a reinstall won't be a horrifying experience. Take note from Ubuntu on that front.

Opening a github account would also be a useful thing, as we could fork projects like QGroundControl, ArduPlane, APM, JSBSim and others so when and if we make some small change to code we can also contribute back to the community, thus keeping a solid relationship the open source community. This of course is just in the planning stage, there is no way anything I could do right now would be of any help.

This also brings up the challenge of the different types of data this back end needs to keep track of. In the film industry this also becomes a problem, hence the reason for the asset tracking system. There has been a lot of thought over which types of data we would be using and for what. Below is a list which may be incomplete.

• .blend : CAD, 3D printing design, modeling for simulation and product visualization.
• .ac : File format most commonly used in the Flight Gear flight simulator
• .stl : CAD file format that Blender, FreeCAD and 3D printing service Shapeways can use
• .xml : Various uses from flight simulation to autopilot programming
• .pdf : Plan prints, internal documents, manuals and anything paper related

In my experience working with a team of volunteers on a 3D animated short, a pipeline had to be established before any real serious work could be done, there had to be a process to follow as well as making sure software tools for each of those processes work as they should. The same applies here, where various tools are used for each process and these processes are being programmed into the Tactic server. Early on in the Design process alot of drawings, basic 3d modeling and rendering will be the primary focus, as well as technical notes related to parts and functions. The CAD process starts once final approval for the design is complete, of course have to take in account that during CAD some design changes would be required, which also in turn produces the models used in the Simulation process. During this process it may be required to make changes to both design as well as CAD in the event that under simulated conditions the aircraft is not performing as well as it should be. These steps will usually take the longest time to complete as changes take time to complete. Once a solid aircraft is finalized in all processes, it then moves on to Fabrication, where the parts designed during the CAD process are sent out to be either built, printed or fabricated in house. Once the parts are accounted for then the Build process begins which usually takes the least amount of time to complete. Then the final Testing process where the aircraft is flight tested in the field, where it is determined if all the hard work to build a plane actually does in fact perform as expected. This of course is not always the case, in which case the process is started all over again.

This is of course begun after spending several years studying UAS systems, simulations, reading tons of flight papers, FAA regulations and restrictions, local area UAS markets (none, bonus there I guess) and countless hours thinking and taking notes. Think that this could be the start of something pretty damn cool.