Update: Clark 2018-12-21

1. Updates Summary
  • Measured and updated the volume of the UAUV to eliminate modeling error.
  • Attempt to eliminate the tracking error:
    • Attempt 1: Adding additional payload.
    • Attempt 2: Setting minimum thrust force.

 

2. Detailed Updates

a. Volume Measurement

I measured the volume of the system by submerging the quad in a bowl filled with water and measured the volume of the water flown out of the bowl.

The volume of the underwater quad system is 170 cm^3, which is 40 cm^3 larger than the original estimated value.

I updated the simulator with the new measured volume. For a command of 0.2m, the drone would hover at about 0.26m in the estimator, which is about the tracking error we observed in previous experiments.

However, after updating the volume information, the motors of quadcopter would experience difficulty in starting spinning underwater. The phenomenon can be explained as following:

i. As the volume in quadcopter constant increases, the controller would take more buoyancy into account. As a result, it lowers its desired thrust command during the take off phase.

ii. As the thrust command decreases, the PWM value sent to the motor would also decrease.

iii. Motors we currently use have difficulties in responding to low PWM (<1030) commands.

As a result, to solve the problem, we need to either increase the desired thrust (by decreasing buoyancy or adding weight) or overwrite the thrust command with a higher value.

b.  Attempt 1: Adding additional payload.

I made a payload out of the scrap metal in machine shop. Its mass is 63g and its volume is 7.68cm^3.

Followings are the experiment results after adding this piece to the system: 

Figure 1. Command = 0.15m

Figure 2. Command = 0.15m (zoomed in) Figure 3. Command = 0.1m

Figure 4. Command = 0.10m (zoomed in) Figure 5. Command = 0.05m

Figure 6. Command = 0.05m (zoomed in)

We see that the approach solves the tracking error problem. However, the method is not ideal, and as Mark pointed out, may be “a step backwards”.  We are adding additional weight to the system, making it less efficient. Moreover, the additional payload may cause center-of-mass drift, adding additional inconvenience to the experiments.

c. Attempt 2: Setting Minimum Thrust Force

After analyzing the previous experiment plots, I gain an intuition that the motor will start to spin reliably with a thrust command of around 0.2N.

To pinpoint this value, I experimented with different minimum thrust commands settings.

Following plot is one of the examples: I set target hover height at 1.5m whereas I set the minimum thrust force as 0.18N.

The vehicle would attempt to take off, but one or two propellor would fail to spin. As a result, the vehicle engages in a “jump” motion. As is shown by the following video:

https://drive.google.com/file/d/10beC-W_r4DBoGKRaXwx-FRIWw-ODomkr/view?usp=sharing

When I set the minimum thrust to 0.2N, the propellers will rotate reliably and the UAUV would be able to successfully take off. Following plot depicts the situation when command height=0.15m and minimum thrust = 0.2N.

Figure 7. Command = 0.15m, Minimum Thrust = 0.2N

Figure 8. Command = 0.15m, Minimum Thrust = 0.2N (zoomed in )

From the plot, we see a 0.07m tracking error. This might be caused by the unreliable mapping between PWM and thrust. In the model, we assumed a quadratic relationship between PWM command and thrust output. This mapping however, is not very accurate in the low-PWM (and hence low thrust force) region. In low PWM region, the real force generated by the propellor deviates from the thrust that the controller thinks it is generating and hence caused the tracking error.

In fact, this mapping error between PWM and generated thrust force is also shown in the hovering force mismatch: according to measurement, the total mass is 0.24 kg and total volume is 0.00017m^3. Considering gravity and buoyancy, each  propellor should generate only 0.1715N when the system is hovering. However, we see that we need at least a force command of 0.2N to achieve underwater hover.

3. Planned work for near future

(I will be out of town for the next week. I will try carrying out the following plan during/after Christmas break)

  • Work with Eric to create a detailed mapping at low PWM region.
  • Hardware maintenance: print another case as current case started cracking under pressure of fasteners.
  • Bring tracking error to less than 0.03m for UAUV without additional payload.
  • ( I also want to explore the possibility of adding an integral term to the controller and see its performance).
  • Communicate with potential undergraduate research assistants and design undergraduate project for the next semester.

 

 

 

Update: Clark 2018-12-07

1. Updates Summary
  • Tested and confirmed that UAUV is being controlled underwater.
  • Estimated the tracking error and depth estimator error with experiment.
2. Detailed updates

Setup of Experiment:

UAUV was commanded to hover at underwater at different depth in a large plastic box. Videos of hovers were taken with GoPro to visually measure the hover height underwater. The result was then compared to vehicle’s depth estimator outputs to analyze the vehicle estimation/tracking error.

Experiment Result:

Scenario 1: Command Z = 0.15m

Figure 1. Estimator Output of UAUV Underwate Hover with Command Z = 0.15m

Figure 2. Enlarged Position Estimator Output with Command Z = 0.15m

Figure 3. GoPro Screen Shot of UAUV Underwate Hover with Command Z = 0.15m

Scenario 2: Command Z = 0.10m

Figure 4. Estimator Output of UAUV Underwate Hover with Command Z = 0.10m

Figure 5. Enlarged Position Estimator Output with Command Z = 0.10m

Figure 6. GoPro Screen Shot of UAUV Underwate Hover with Command Z = 0.10m

 

Scenario 3: Command Z =0.05m

Figure 7. Estimator Output of UAUV Underwate Hover with Command Z = 0.05m

Figure 8. Enlarged Position Estimator Output with Command Z = 0.05m

Figure 9. GoPro Screen Shot of UAUV Underwate Hover with Command Z = 0.05m

Scenario 4: Command Z =0.02m

Figure 10. Estimator Output of UAUV Underwate Hover with Command Z = 0.02m

Figure 11. Enlarged Position Estimator Output with Command Z = 0.02m

Figure 12. GoPro Screen Shot of UAUV Underwate Hover with Command Z = 0.02m

Analysis of the Result:

From the test, we observed that the vehicle hovered at different depth with different command input, confirming that the system is being controlled underwater.

Meanwhile, we observed that for the current control algorithm, the system has a 0.05m tracking error. During the hovers, estimator would give a height that is 0.05m higher than indicated.

We also found that the major error of the system stemmed from depth estimator. I believe the error was caused by an erroneous attenuation rate of the shell that is hard coded into the system. The value was obtained in an experiment a month ago and I didn’t count the temperature change factor during that experiment. I will do a new round of experiment and update the rate. Hopefully it will fix the error.

Link to Test Videos:

https://drive.google.com/file/d/1XMd_vfEg_-fw12EKhz1P5jNwdoTYLGDf/view?usp=sharing

3. Planned work for next week

As next week is the final exam week, I am writing down here my planned work for the next two weeks.

  • Fix the estimator error
  • Autonomous Water Breaching Test (Write a program that can detect the status of the drone and enables it to shift between underwater and in air mode.)
  • (Reach Goal) Study the wave breaching algorithm and recreate it in C++