Autonomous Mini Powered Paraglider

• 

  Second MDF Chassis

• 

  First MDF Chassis

• 

  Original 3D printed chassis

• 

  Rolling Chassis Design

• 

  System Architecture

Goals

Our baseline goal was to build our RC paraglider and operate a remote-controlled flight. This baseline goal is comprised of a series of underlying goals, including chassis design, and successful actuation of our control actuators. We had a successful flight! We also were able to demonstrate important elements of it individually, by operating separate flights that demonstrated roll and thrust. Our paraglider build went under a number of iterations, as described in the mechanical effort section. Our actuators were all successfully controlled, as described in the software and mechanical effort sections. Our RC transmitter successfully interfaced with our Pixhawk flight controller such that we could adjust thrust (changing the speed of our BLDC motor), pull the glider left or right (pulling on the left or right control lines, pulling on the parachute to veer it left or right), or brake the glider (by pulling on both the left and right control lines at once). Upon fixing our motor, ESC, flight controller, and power hardware to a temporary chassis, we have shown that we can use our thrust controls to fly, without attaching our roll control.

Our reach goal was to achieve various levels of autonomous flight. We did not explore autonomous flight very deeply, as we got the RC flight working at the 11th hour. However, we did successfully explore and implement elements of autonomous flight. We were able to set up our actuators in “auto” mode, where tilting the paraglider in one direction caused the servos to pull on the control lines to counter the tilt and return the chassis to level orientation.

System Architecture

As shown in block diagram in photos at top.

Problem Identification

The problem we are trying to solve is how to fly using a parawing design and to automate as much of that process as possible. We were trying to explore the feasibility of this mode of flight and evaluate it for its possible utility when combined with autonomous operation. In order to achieve this, we have come up with our own vehicle design. We were successful in accomplishing multiple aspects of our project. We were able to control the parawing using servo actuation, rolling to both the right and left, as well as braking. We were also able to generate lift and achieve uncontrolled flight using the parawing in a stripped-down design. Additionally, we were able to automatically actuate the control mechanisms of the vehicle. We had a successful, controlled flight! However, we were not successful in our reach goal of testing autonomous flight.

Mechanical Effort

We constructed 3 different prototypes of our chassis. The first was a 3D printed model, composed of two 3D printed flat squares with threaded standoffs between them, the servo motors mounted between them, and the BLDC motor mounted on the back. This proved to be too obvious heavy. The next iteration was comprised of the same design, but made of ¼“ MDF. Another sub-iteration was made afterwards out of ⅛“ MDF, to decrease the weight. This design seemed feasible, but was destroyed far too easily when tested in flight. One crash landing would result in 30-60 minutes of reconstruction on the bench. In testing, we found that this design presented a great issue. The propellor was level with the control/structure lines from the parachute, and they could get easily tangled in flight, which would immediately cause a crash and could irreparably damage components.

The final mechanical iteration was a brand new design, to solve our issue of the propellor colliding with our structural and control lines. We had constructed landing gear out of balsa wood and small wheels and axles, and built a vertical back wall to mount our BLDC on. This design also gave us the new opportunity to attempt to take off from the ground, as opposed to throwing the glider, which would be the first step towards our reach goal of automating takeoff. Our structural lines were mounted above the highest point of the propellor, such that they would be unable to interfere with one another. To handle the case of the lines being horizontal, when taking off, we installed a wire as a motor guard. Our servos were mounted immediately below the structural lines. Lastly, as this design was top and back heavy, the chassis had a tendency to tip back during takeoff, when gunning the motor. To combat this, we attached small wooden pieces at the bottom back of the frame for the chassis to lean on when it tipped backwards, so it wouldn’t fall all the way back. This design was modified several times, by altering our motor guards, altering the runners to prevent falling back, and changing the motor directions/orientations.

Each of our mechanical design iterations were done to solve an issue that the previous iteration presented: We reduced weight repeatedly, and solved the issue of the propeller interfering with the control/structural lines.

Electrical Effort

The brain of our glider was the Pixhawk flight controller, and all of our actuators and signal-carrying elements had to be connected to it. Our RC receiver connected to the RC input of the Pixhawk, the servo motors connected to the MAIN outputs, and the ESC used for our BLDC control was also connected to a MAIN output. We also had to find a way to power all of our elements. We chose to use a 7.4 LiPo battery, as that was the intended voltage supply for our servos, and we found, in testing, that it could also power the ESC to successfully spin the BLDC motor. A wire arrangement was rigged together to provide the battery power to all elements. The battery outputs were cut and re-soldered to a female T plug connector. A male T-plug connector was then soldered to multiple outputs: to a pair of bullet connectors, to connect to our power module, and pair of bullet connectors to connect to the ESC, and to a pair of DuPont connectors to connect the servo power rail on the Pixhawk. The power module had its own DF13 connector to connect to the power input on the Pixhawk. The overall electrical schematic of our system can be found in the system architecture.

Software Effort

To fly our vehicle we used the px4 open-source software running on the pixhawk open-source hardware board. We used the SDK associated with this software to program the board. As we were using software designed for flight, the software infrastructure required for flight was largely included. This proved to be a large and cumbersome software stack to work with as the development environment offers few features and testing and building the code was a long process. The major challenges that we completed include successfully mixing the commands for actuation control of the vehicle.

The mixer files proved to be a significant challenge in this project. These files take in the input from the RC transmitter and transform them into the proper PWM outputs. However, the documentation on these files is poor and their construction is arcane. The system takes these numbers as inputs ranging from -1 to 1, and outputs them in the same scale. However, these numbers are scaled for manipulation to range from -10000 to 10000. The files are composed of several number lists in the following form:

For example, to translate the ‘roll-right’ command from the PWM inputs we use the following line:

S: 0 0 0 20000 -10000 -10000 10000

‘S’ - the output is a servo motor ‘0’ - control group input selection. This is the default control group and directly maps commands like roll, pitch, yaw, and thrust. ‘0’ - index of the input in the control group. This input maps to roll. ‘0’ - lower bound of the inputs. This is 0 because we only care about the positive value as only the positive roll values translate to the ‘right’ direction. ‘20000’ - upper bound of the range. In order to utilize the full output range, the input scale must be of the same magnitude as the maximum scale (2). ‘-10000’ - offset applied to the input. This value translates the 0, 2 scale of the input into the -1, 1 range. ‘-10000’ - lower bound of the output range. ‘10000’ - upper bound of the output range. Using the lower numbers ensures the direct proportionality.

However, the controls for servo 2 are more difficult to parse.

S: 0 0 20000 0    0        -10000   0

‘S’ - the output is a servo motor. ‘0’ - control group input selection. This is the default control group and directly maps commands like roll, pitch, yaw, and thrust. ‘0’ - index of the input in the control group. This input maps to roll. ‘20000’ - lower bound of the inputs. This number is automatically interpreted as negative. ‘0’ - upper bound of the range. In order to utilize the full output range, the input scale must be of the same magnitude as the maximum scale (2). ‘0’ - offset applied to the input. ‘-10000’ - lower bound of the output range. ‘0’ - upper bound of the output range. We only want the servo to travel half the possible distance.

We also altered the attitude controller code in order to complete our automation goals. This involved altering the code to allow for control of a paraplane rather than control of a standard plane. This involved altering calculations that use ‘yaw’ as an attitude controller. For instance, When the position controller commands an attitude adjustment to achieve a turn, a component of the turn in certain situations comes from the yaw command. In order to properly calculate the roll for the powered paraglider this component must be eliminated.

We encountered several software issues that we decided to bypass rather than surmount because they were of questionable value to the project. For instance, we tried to build the simulation environment for the pixhawk software. However, this proved to be difficult on the OSX development environment. The only free fixed-wing flight simulator available was the Gazebo flight simulator. However, Gazebo failed to build in the PX4 context even though the application ran and built fine on its own. We attempted several fixes, including installing different versions to find a compatible one. We also attempted to manually resolve the build errors by altering the simulation environment code but this failed as well.

System Evaluation

Our first goal to build our system was to use our RC transmitter, RC receiver, Pixhawk, and battery/power supply to control our actuators (BLDC motor and servo motors). We sought to be able to (1) control the speed of our BLDC motor with the thrust control of our RC transmitter, (2) rotate our servo motors in opposite directions with the same range with our roll control, and (3) simulate a “brake” by rotating our servos in opposite directions at the same time at the same angles with our pitch control. By designing a custom airframe in the Pixhawk environment and writing a custom mixer file, the file that maps inputs to outputs, all 3 of these were successful.

Control of our actuators had to also be evaluated by their in-flight performance, not just on a desktop. During the process of attempting a full RC flight, we sought to evaluate parameters separately. Two important parameters to evaluate were the performances of our thrust control and our roll control, independent of one another. Separately, we practiced ground takeoff and test of our automation system.

Thrust control was tested by attaching our thrust controls (BLCD, ESC, power, flight control) to a temporary chassis (that we would be comfortable damaging). This was also an opportunity to practice takeoff protocol via “throwing”. One team member controlled the RC transmitter, and the other held the chassis. The team member with the chassis ran with it, allowing the parachute to catch the wind and open up. As it opened up, the first team member began running the motor. As the motor sped up, the second team member let the chassis go in the air, as the first team member ran the motor to full speed. Evaluation was based on the flight performance after letting go of the chassis, and ramping the motor up to full speed. It was shown that after those actions take place, the glider gained speed, and, as a result, began to generate lift and flew higher into the air. Thrust control was successful.

Roll control was performed in a similar manner, with the first team member manning the RC transmitter and the second team member holding onto the chassis, and running with it to allow the parachute to catch the wind and open up fully. During this time, the first team member tested left and right roll controls. It was shown that using the left roll control, which caused the left servo motor to pull down on the left control line, forced the parachute to veer to the left side and pull the chassis along with it. The same was shown for the right roll control.

Lastly: We integrated all of the elements and flew the aircraft. We took off manually by throwing it, it attained lift, and our pilot directed it around a large open area, avoiding obstacles and eventually choosing to crash land it when it would be safe to fly further.

Awesomeness

This project is awesome because of the novelty of the airframe design. Many people have built frameworks for fixed-wing and multirotor aircraft. However, very few have explored the powered paraglider as a flight form. No one has yet explored methods of automation for this frame. The project incorporates many elements: it required us to iterate repeatedly on mechanical design, which was something we were not accustomed to. We had many degrees of choice, as shown by our multiple different attempts at the chassis design, but also by our takeoff: we were able to explore different options, such as manned takeoff (with one team member running with and ‘throwing’ the glider into the air), and ground takeoff. To accomplish these takeoffs we had to establish set communication protocols to coordinate the safe release and throttling of the motor. In aviation this process of establishing safe and clear communication protocols is referred to as Crew Resource Management. These different methods taught us quite a bit about the physics of our project and the dynamics of working with safe unmanned flight.

It afforded us the opportunity to work within a framework (Pixhawk airframe design) that we were not used to, whereas simply writing microcontroller code to produce PWM outputs would’ve been fairly trivial and not new to us. Choosing a paraglider as our vehicle, as opposed to a multicopter or a fixed wing vehicle, made our choice to use Pixhawk even more interesting. We had to figure out how to add to that framework, since its intended uses are typically for those aforementioned vehicle types.

Outside of our application, paramotors are interesting vehicles. They provide interesting advantages over a multicopter or a fixed wing flight, including a higher lift-to-power ratio and longer flight time with the same battery. They also offer advantages over fixed-wing flight such as higher payload capacity due to the increased lifting area of the wing.

Videos + Code

https://github.com/dmilewicz/Firmware/blob/master/ROMFS/px4fmu_common/mixers/paraplane.main.mix

https://www.youtube.com/watch?v=jE_ItS7-fSU&feature=youtu.be