ME 461 Balancing Quadrotor

Goal

In our final project, our team is attempting to have the quadrotor balance itself around a central point, similar to the segbot balancing on its front wheels. To do this, we will implement similar filters to those of the segbot where the MPU will give us acceleration and gyro data, which will in turn be used by the motors to correct the pitch and yaw. A complimentary filter using gyro data and the compass readings was used to find the yaw angle. State estimates for roll and pitch were generated using the lightweight Madgwick algorithm instead of the more traditional choice of a Kalman Filter, due to the processing limitations of the F28027 chip. These angle readings were then used to provide control about the three rotational axes of the quadcopter, and then translated to motor power commands. We will also be using the Raspberry Pi and OpenCV to provide angle tracking of two colored blobs, which are then sent to the quadrotor as angle commands in pitch and yaw. Lastly, we will also be attempting to make the Raspberry Pi work wirelessly. This will be done using an ESP8266 chip. The chip should use Wi-Fi to communicate wirelessly with the F28027 board. This would help with the calibration since we could remove some sending and receiving wires. Although this is not as useful because the quadrotor won’t be moving, it will be good practice and provide more simplicity in setting up the Raspberry Pi.

Process

CircuitBoard

The physical makeup of the project will build off of the schematics from project 2. The base circuit consists of a USB COM port circuit that can read the UART to USB for our control inputs. This is a similar protocol to our previous labs involving the robo-car and seg-bot. Through this port we can upload machine code in C from the computer's compiler to the TMS320F28027 processor. Make note that this processor is equipped with the lowest speed and memory within the C2800 processors and will determine our process to achieve three axis control.

The board also consists of both male and female header pins to allow for connections to external surface mounted chips. In our case we designed it to incorporate a Raspberry Pi. We had plans to potentially incorporate Lidar for distance feedback and ESP8266 for wireless communication possibilities.

The rotor circuits consist of 4 RC servos that are wired to the EPWM pins, and each include a respective MOSFET to drive current to each motor. There will be a lightweight plastic screw and nut to fasten each servo directly to the printed circuit board. The through holes on each corner of the board were incorporated in the PCB fabrication and will be used for this reason. The arms will extend from each corner at the midsection 45 degrees to the edge.

Raspberry PiandOpenCV

The Raspberry Pi's purpose in this was to run the OpenCV program and to send values to the quadcopter. The first steps of the Raspberry Pi were simply updating it and making sure that the directories were all set on the board. With that setup complete, a blob tracking program was implemented using OpenCV and a camera. The camera takes the basic image in front of it, and then the OpenCV software does image filtering so that only certain HSV values are taken. HSV is hue, saturation, and value, which defines colors and lighting for a given environment. By defining certain HSV values, it was possible for the camera to then only see colors that were deWith the image filtering done, two blobs corresponding to different colored pieces of paper were then seen, where the size and center of the blobs could be found. This then allowed for the angle between the blobs to be found in the vertical direction using the centers and the angle between the blobs in the horizontal direction using the size.

With the two angle values, it was possible to send them to the quadcopter so that the quadcopter would respond to what the camera was seeing. To communicate with the quadcopter, UART was used. This allowed for the serial port to send the two angle values and then also receive values back if needed. The Raspberry Pi turned out to be very useful as it allowed to take some of the processing weight off of the relatively small quadcopter processor, which was already loaded with the Madgwick Filter.

ESP8266 Chip

The goal of the ESP8266 chip was to reduce the wires required for quadrotor. The chip would enable the quadrotor to communicate with the computer over a Wi-Fi network. This would allow the quad to have less cables and be wireless. Having the quadrotor be wireless would make it easier to balance instead of having it be attached to multiple wires.

To start out, the LaunchXL-F28379D board and the green expansion board provided to us at the beginning of the semester was used. The code used many ESP commands to connect to the Wi-Fi network, IP address and the chip. The given commands worked flawlessly on the LaunchXL-F28379D board. A LabView program was then used to send and receive given data. This could be printed out in Terra Term to ensure the data was being sent properly. This worked perfectly on the green board and was able to ping the IP address.

Then, a new quadrotor was created to test the ESP8266. Several wires had to be added to and solder the ESP to the quad. This is because the quad board does not have a set of pins for the ESP. Using female header wires and the male headers on the ESP chip, the ESP was attached to the quad board. Then the LaunchXL-F28379D board ESP code was changed for communication between the quad board and the ESP chip. This is where issues were encountered, which are explained more in the Issues section. The ESP did not end up working on the quad board due to communication issues.

Filtering

Each time the code is restarted, the quad must define its states. This happens as the Madgwick filter calculates gyro offsets during an initial calibration, using the gravity vector. During this time, it is important that the quad is level and oriented in the desired direction. Inconsistenties during calibration can lead to incorrectly calculated offsets, which cause the filter to produce offset readings.

The Madgwick filter uses quaternions defined by the arctan of gyro readings. This definition breaks down at certain orientations past 90 degrees, but all angles should be below 45 degrees for our project, so this limitation was not considered a problem.

A complimentary filter was attempted originally, however this yielded extremely high drift following high rotational rates. Even with large trust to the steady-state measurement - accelerometer z, this filter yielded drift in excess of 30 degrees for roll and pitch after only a minute of strong induced oscillations. This lead to the use of the Madgwick filter, a more computationally intensive algorithm. However, by maximizing offline computing on the Raspberry Pi for other calculations, a lightweight filtering and controls loops was developed which could be run by the F28027 chip.

Control system

Control was performed independently about the 3 quadcopter body-frame axes: x (forward), y (sideways), and z(upwards). These axes correspond to the pitch angle theta, the roll angle phi, and the yaw angle psi. The default control design used a setpoint of 0 for each angle. This controller ensured the quad’s stability about a steady, level, hover. The quad was approximately symmetric about the x and y axes, and therefore the control about these axes was nearly identical. A steady state z-state representing total upwards thrust was chosen to be approximately 75% of the quad’s full power after experimentation, which represented the 4th control input. A PID controller was first implemented for the 3 rotational axes. Continued attempts at gain tuning lead to usable controllers with a slow settling time, but attempts to improve controller responsiveness lead to oscillatory behavior. Given that the gyro data was itself a relatively low variance measurement, a double derivate term could be added to the control loop, to reduce accelerations in tilt. This double derivative term, used with a relatively small gain, allowed for an extremely responsive controller which nearly instantaneously returned to a zero angle for both pitch and roll. Control in yaw was somewhat more limited. This was in large part because yaw has a dynamic coupling with roll and pitch: attempts to correct yaw also affect roll/pitch if either angle is not precisely 0. This means that stiff controller design on both roll/pitch and yaw is likely to produce instability, with the yaw response causing pitch/roll, and the pitch/roll response causing further yaw. Additionally, the quadcopter has a larger moment of inertia about the yaw-axis, as well as a lower ability to actuate due to the non-alignment with the propeller thrust, leading to a slower control response. For this reason a slower but more stable yaw response was chosen, with a moderate proportional gain, and low derivative gain term. Yaw returned to equilibrium within several seconds, following several gentle oscillations, which was deemed acceptable performance.

With the calculations of torques about each of the rotational axes, these are translated to motor commands between 0-3000, and sent to PWM 1 and 2. The steady state thrust is 2300 for each motor- differences in force between two pairs of parallel propellers leads to pitch, with differences between the perpendicular set acting on roll. Finally, due to the counter-rotating nature of the quad causing opposing aerodynamic torques, yaw can be affected by changing the motor commands between the diagonal pairs of propellers. The relationship between torques and motor commands was estimated by a scaling of motor thrust and torque and quad inertia to the PWM input range (0-3000). This was then tuned to provide a good response. Once the Raspberry Pi was configured to calculated yaw and pitch of the tracker, these setpoints were sent to the F28027 chip in place of the equilibrium setpoint. This allowed for physical control of the quadcopter orientation through the OpenCV camera.

Issues

ESP8266

One of the issues was the ESP8266 chip not communicating properly with the quad board. The code complied, but there was trouble communicating with the chip. This was clearly displayed in the LabView program. The LabView kept timing out when it reached the TCP, meaning there was not proper communication. The code was reworked several times and ensured that all of the parts were working. Through debugging, the IP address was able to be pinged. This meant that there was some communication. However, it seemed to not be able to communicate due to the incompatibility of the board and chip.

Images

QuadRotorCircuitBoardandSchematic

ESP8266

Testing

GroupMembers