Low Pass Filtering for the Position Controller

An amazing thing happened today. I didn't think this would ever happen.

I was still having trouble running the controller over the wireless. We were seeing large round trip time spikes, followed by input saturation and the plant crashing. I wasn't getting long enough test runs, and so I wasn't feeling confident at all about my data.

The first thing I thought about doing was putting constraints on my net thrust and net torques. Earlier, we established that the plant crashes because all of the motors saturate, and I thought that putting constraints on input values would solve this problem. I tinkered with these constraints for a bit, but didn't really get  any better performance.

Then, I took another look at the input plots, and realized the inputs were too noisy with time. I thought about low pass filtering the error signal in the position controller. The error signal didn't look noisy at all, so I didn't try this earlier, but I figured I'd give it a shot.

After debugging and getting the low pass filter working, the results amazed me. The controller was working almost as well over the wireless connection as the localhost and the ethernet connections. The state error remained small. The quadrotor never wandered off course, as it had done previously. Just to make sure I wasn't fooling myself, I verified with Ehsan that I was running over wireless. Yup. It was working perfectly.

The moral of the story is: NEVER use a PD controller without a low pass filter. Ever. Ever ever ever ever ever. Even if the error signal doesn't look noisy, it's always better to filter it. Derivative action and noise don't mix.

Improvements and Updates

I've done a lot of things to update the controller and the plant and to improve performance. Initially, I couldn't even get the controller to work over wireless for one minute, but now I can get it to run for 10+ minutes (and probably much longer).

We implemented a way to control the x and y position independently. We really should be able to control the yaw angle independently as well, but I haven't gotten around to that yet, and the point of this project is to examine the impact of network conditions and protocols on the performance of the controller, so that's not really essential. But for now, we can generate more complex 3D trajectories than when we just had x and z position controllers.

To get better performance, we tried to reduce the amount of data we were sending over the network. We're sending the data as strings (not ideal, but we're using HTTP and I'm not sure how to do it any other way). We were representing the data with much greater precision than we needed, so we dropped the number of significant figures on the states. For each figure we lost, that was one less byte of data that needed to be transmitted. We also didn't send over states that we didn't use in the control system (namely, the quadrotor velocities). All in all, this reduced the amount of data that was transmitted, but it didn't make a significant difference in terms of performance.

We found a bug in the controller. Specifically, I set the maximum roll and pitch reference angles to certain values, but those values were not actually being implemented. After fixing this problem, the references never exceeded these maximum values, which caused the system to crash much less. However, the system still crashed often. Our hypothesis was that the state was being driven outside of the region of stability in which linear dynamics accurately represent the system.

The most significant difference I made was to more intelligently implement a low pass filter with the PD controller. previously, I tried to tune the two together as a "lead compensator", and I didn't quite know how to do that. Consequently,  I got a poor response from the attitude controller. In particular, it was underdamped. After taking a second look at the controller and treating the low pass filter and the PD controller as separate entities, I was able to get a much better response. There is now almost no overshoot, and the noisy reference signal is not amplified.

With these modifications, we are now ready to take data. We plan to do long test runs with different client implementations using wireless, ethernet, and localhost connections. We will then compare the data to get a better understanding of what causes variability in system performance. Ultimately, we wish to use the knowledge we gain to design a better controller that can perform well in a variety of different network circumstances.

Performance Worsening with Time?

Over time, it seems like the performance of my controller drops. I don't understand why this is happening. For some reason, this doesn't seem to happen when Dr. Remy runs the controller over the network. It seems to maintain consistent performance throughout. Here are some plots to show the performance degradation. Specifically, this is caused in the x and theta controllers:

Here is the angle tracking. It should ideally be a sinusoid, but it gets worse over time:

And the x position tracking:

And the trajectory (brace yourself):

 Not a pretty sight, but I bet if Dr. Remy ran this controller for 5 minutes with the same references, he would get wayyyyyyyy better results.