DRONE SWARM vErsion 3 Velocity Calculation:
The dreaded drift in an integrated measurement. The straight lines should be horizontal
Integrating Acceleration INto Velocity:
Here is the end result I am hoping to achieve with the low level controller:
High level controller looks at current GPS location and desired target location, and determines a direction and speed in order to move to the target
Receive desired direction and speed
Look at current direction and speed
Adjust speeds of the motors accordingly
This work log focuses on step 3. From the work in the previous log, the low level controller receives acceleration data that is normalized with respect to the outside world. However, this data is acceleration, in meters per second per second. This has to be turned into velocity data, in meters per second. To do this, it has to be integrated with respect to time (the acceleration values have to be continuously added up in each of the x y and z coordinates). The main problem with this method is that it leads to drift, as shown in the graph.
What drift means for the drone is that it will think it is moving in a certain direction at an increasing rate when it is actually sitting still. If there is a slight error in the data that remains constant, say 0.1 meters/second^2, integrating this over 1 second results in a constant error velocity of 0.1 meters/second. I have tried many methods of removing drift, with varying degrees of success.
Method 1 - Filtering:
The acceleration data is very noisy. This can lead to errors that make the drone’s flight erratic and unstable. To counteract this, I implement a low pass filter that smoothed out the data. The velocity data after integrating this still has drift, but it is a cleaner signal.
Example of using a low pass filter on noisy data
Here is a test with the low pass filter smoothing the accelerometer data:
To fight drift, I used another filter for the velocity data. Drift in the velocity data is an error that changes very slowly, compared to the actual motion of the drone. Thus it has a low frequency and can be eliminated by a high pass filter.
Problems:
Filtering data in real time inherently introduces lag in the signal. This means that the more signal processing that occurs, the more the time difference between when the movement of the drone changes and the controller realizes it. (As seen in the graph, the estimated data is rougly the same as the true data but with a time delay)
The second problem is attenuation of the signal. Sometimes high frequency vibration and acceleration is encountered that is actually something the controller needs to take into account. However, this would just get filtered out alongside all of the useless noise. In addition, a filter uniformly reduces the amplitude of a signal by a certain amount. (As seen in the graph, the estimated data doesn’t have as wide of a range as the true data). This causes problems when precise measurements are required.
Method 2 - Linear REgression Compensation:
The drift can be approximated as having a constant rate. In reality, the drift is not a straight line offset, but the difference is not significant.
Here is my custom algorithm to eliminate drift without any noticeable time lag or filtering:
Problems:
The issues with this algorithm are in red in the diagram above. The algorithm couldn’t properly recognize when movement stopped and started, because the values for the thresholds are arbitrary. Also the algorithm had trouble when the drone was moving for a long time, because errors started to crop up as the drift acted less and less like the straight line approximation.
Testing:
Here is a video of this drift elimination algorithm in action. Raw data is in red and compensated data is in blue.