Vayu Internship

This summer I was fortunate enough to be offered a summer internship at Vayu Aerospace. Vayu specializes in VTOL long distance drone technology for payload delivery. Since their merger with Impossible Aerospace, they also now specialize in extended flight quadcopter technology. 

My team and I were offered this internship after presenting our Software Engineering class’s semester project to Vayu’s offices. They were impressed with our work and offered us work throughout the summer at Ann Arbor, Michigan. Departing from Illinois, we took the 5 hour drive and stayed at a hotel for the 40 days we were there.

While we were there, we focused on two main projects: a new satellite communications backend and updating drone landing algorithms. 

Satellite Communications Update

The first project we were introduced to was the new satellite communications backend Vayu wanted to implement. With their current set up, only one specific drone could interface with a ground control station (GCS) at a time. The objective was to make it so that any drone could interface with any GCS, the server handling multiple connections at a time.

In order to accomplish this we needed to analyze the existing framework Vayu used to allow drones to communicate with one another. The system consisted of a GCS, an AWS backend, SatCom (Rockblock) server, and drone. Here is a diagram on how the infrastructure worked: 



This involved a complete redesign of the existing infrastructure, and rework of existing code. We created a brand new virtual machine on AWS, and got to work creating the new satellite backend.

We decided to use a Python based MQTT broker and a Python relay script which received and handled communications from both ends of the system. We then compartmentalized each of these processes in their own Docker containers with encrypted communication using the inbuilt security options in the MQTT broker we used (Mosquitto). This ensured that no client could communicate with the wrong broker and interact with the wrong drone. In addition, this protocol secures possible confidential data from prying eyes. Finally, each Docker container was assigned its own TCP port to receive data from which was allocated in the AWS portal.

The relay.py script itself was responsible for receiving and processing subscriptions and packing them into HTTP requests to the Rockblock server. The script was also responsible for doing the reverse: receiving and unpacking HTTP requests and sending them as published messages to the MQTT broker. This was done through publicly available libraries which subscribed and published to specific topics, each topic corresponding to a drone. Since IMEI numbers are specific to every single drone (each satellite modem had its own IMEI),  we needed to use IMEI numbers to identify what data needed to go where. As a result, we used labeled topics after the drone’s IMEI number.

Finally, we developed a bash script which automated many of the processes of creating a container for new clients. Every time a new client needed to be added to the server, an employee could run the script, fill a few fields out, and immediately create a new client. However, every time a new client was added, there is about 20 seconds of downtime for clients. 

While there are a few limitations with this solution such as downtime, the solution was a great improvement over the existing framework and was adopted by Vayu.

Dynamic Landing Algorithm

The second project we worked on involved creating a landing algorithm to stop the plane from overshooting the landing point. Before our fix, the plane would regularly overshoot the landing location and would track back 200 meters to the intended landing location.

In order to combat this, we implemented a two step approach. We decreased the deceleration by force stalling the plane by using a dynamic deceleration algorithm and a pitch up maneuver which greatly increased the distance the plane needed to slow down. We tackled this problem by checking the flight conditions within our code, and executing specific commands to control the throttle and pitch of the plane. 

Our first and hardest challenge was understanding previously written code, and implementing our own controls within it. Unpacking and walking through the code took the most time. After this, we started to implement our landing algorithm.

First, we focused on the slow down maneuver. Since the plane can’t slow down past 13 m/s without stalling in fixed-wing mode, that was our target speed. Once the plane’s navigation set-point was in range of the landing waypoint, the plane would pitch up immediately. This would force the plane to stall and lose the majority of its speed and go into VTOL mode. Pitching up would result in a change in altitude within ±5 meters and slow the plane to a stop.

For visual reference, here are some diagrams of our slow down algorithm:
 




The first diagram (top) showcases how the slow down algorithm works. The second shows how we calculate our desired speed using the plane’s acceleration. We essentially continually throttle the plane up and down to maintain a desired speed until we reach 13 m/s. After which we use our pitch up maneuver. 

This resulted in the plane no longer overshooting in most test scenarios unless there was a great deal of tailwind. While our method can definitely be refined, it should be the groundwork for future improvement. 

Takeaways

This internship was one of the most eye opening experiences of my life. It gave me insights into the professional world of computer science, and how development takes place in the real world. Here’s a list of the big things I took away from this internship:

However, more than anything else, I am grateful for the opportunity Vayu presented and for the learning experiences that came along the way. 



Thank you for taking the time to read this paper! I definitely have more blogs and write ups on project work coming soon: stay tuned.