Quadrotor Flight Demonstration
QUICK SUMMARY
-
The project was the focus of a Northwestern graduate level course, MECH_ENG 495: Mechatronics with Quadrotor Project
-
A partner and I worked through weekly milestones over the quarter-long course
-
We programmed Raspberry PI (using C++) to operate quadrotor IMU & motors
-
I wrote the PID control loop which controlled the motor speeds and tuned its gains
OBJECTIVE
Control a quadcoptor’s flight using a Raspberry Pi computer, initially with user input from a joystick plugged into a laptop, then autonomously with feedback from an HTC Vive positioning system
Left: Logitech joysticks were used as the initial control input
Right: The quadrotor with HTC Vive sensors mounted on top
(the sensors are the small PCBs inside the purple 3D printed case, more info on the Vive system is below)
PROJECT PROCESS
Quadcopter Assembly:
We assembled the quadrotor from a course kit with the necessary hardware:
-
Raspberry Pi running linux to control the quadrotor
-
Inertial Measurement Unit (IMU) to sense acceleration and rotation
-
Protective gaskets to reduce vibrations/noise sensed by the IMU
-
4 brushless DC motors
-
Electronic Speed Controller (ESC) to control the DC motors with PWM
-
Wi-Fi module to communicate between the laptop input device & the quadrotor
-
HTC Vive photo-diodes
-
Lithium-ion battery
-
Carbon fiber frame
-
4 propellers
Safety Checks:
In the interest of personal safety and mitigating potential errors, we implemented the following safety checks. The motors would shut-off and the controlling laptop would print a relevant error statement if:
-
Roll or Pitch angle was above 35 degrees
-
IMU acceleration in any axis exceeded 1.4 G's (relative to Earth's gravity)
-
Quadrotor exited the 4 square meter test area (only for HTC Vive control)
-
Communication "heartbeat" from the controlling laptop was not detected by quadrotor
-
A kill switch was pressed on the controller
IMU Data Filtering:
The first milestone towards functional flight was processing the IMU data to understand the angular position of the quadrotor. This information is critical to controlling the motors and creating level-flight.
Angle Computation:
The IMU does not sense angles directly. It senses linear acceleration about 3 axes, and angular velocities about 3 axes. Thus there are two relatively simple ways to compute the quadrotor's angular position.
Gravity provides a constant 1 G acceleration downward, so the arctangent of the x-axis and z-axis acceleration approximates the roll angle (diagram to the right). Unfortunately, linear acceleration data is noisy due to vibrations, air currents, and sensor limitations.
Integrating angular velocities from the IMU gyroscope provides a smoother dataset. However, this assumes consistent velocity between time steps, which leads to drift of the data over time.
A complementary filter was used to combine these two data sets into into a single one which is consistent and accurate at sensing the quadrotor's angular position.
Complementary Filter Components:
The graph to the right compares the different estimates of the roll angle from gyroscope data (blue line, which drifts over time) , accelerometer data (orange line, which is noisy) , and the filtered data (gray line, which is most accurate). Note that the graph above only shows this data for the roll axis; each degree of freedom was filtered separately in a similar fashion.
The complementary filter was computed via the following code (lightly edited for readability and focused on the roll axis):
z-axis acceleration,
-imu_data[5]
roll angle
gravity
x-axis acceleration, imu_data[3]
CF_roll = 0.003; //coefficient for the complementary filter in roll axis
void update_filter()
{
timespec_get(&te,TIME_UTC); //getting current time in nanoseconds
time_curr = te.tv_nsec; //passing the time data to a local variable
time_diff = time_curr-time_prev; //computing time since last execution
roll_accel = atan2(imu_data[3],-imu_data[5])*180/pi - roll_calibration; // roll angle computed from accelerometer data
roll_gyro_integrated = imu_data[1]*time_diff + roll_gyro_integrated; // roll angle by integrating gryoscopic data
roll_filtered = roll_accel * CF_roll + (1-CF_roll) * (imu_data[1]*time_diff+roll_angle); // complementary filter on the roll data. The first term is pure accelerometer data. The latter term is integrating the gyro data
}
Tuning the control system:
A PID control loop was used to stabilize flight. The quadrotor was tied up to limit it to a single degree of freedom, allowing the process of tuning control gains to be focus on discrete behavior. The following video shows a test of controlling the roll. The desired roll angle was set by moving the thumbstick of the joystick.
Testing Roll Control
Tuning PID gains: Graphs like the above one were plotted after each test to observe how responsive the quadrotor was to control. In this example, around T = 9 and T=10 there is noticeable overshoot in the real behavior, which indicated the damping gain was too low.
Autonomous Flight with HTC Vive:
After tuning each angular degree of freedom and testing flight controlled by a joystick, the HTC Vive sensor suite was added.
The HTC Vive is a virtual reality system that tracks users' motion with infrared pulses. Northwestern faculty have used the system's infrared emitters as a position sensor for many indoor robotics projects, like this quadrotor. If you are curious, the Vive creator lectured about the underlying technology here on Youtube (it is pretty interesting technology)
An array of photo diodes on top of the quadrotor were used to measure the Vive's infrared signals and compute the real position of the quadrotor. This data was used in a second control loop to facilitate autonomous position holding as shown in the following video. Note that the joystick is used to adjust the desired position that would be held.
Autonomous Position Holding
CHALLENGES
-
The motors had slight variation in performance, so an offset was added to adjust PWM in select motors to even out their performance
-
Tuning PID gains required compromise between agility and stability
-
The interconnected embedded systems were challenging to debug
-
The quadrotor raspberry Pi had a faulty WiFi module which led to many unfortunate communication interruptions during testing