Dolphin fly - altitude oscillations

ArduCopter Copter 4.3
1

@Leonardthall as per your request, a new thread with the dolphin fly issue.

We flew multiple tests with terrain follow enabled. The parameter RNGFND_FILT does nothing for us to stabilize flight. In this post Dolphin fly (big altitude oscillation) in rangefinder based Auto Mission - #17 by buckker you describe a parameter PSC_TC_Z. We do not see that in Mission Planner. Our firmware is 4.3.0. After changing parameters we do a reboot of the system.

It would make sense to me if there is a seperate PID controller for terrain follow vs. using GPS or barometer, but perhaps I am wrong. I do not see a PID setup for terrian follow so I have to assume it uses the main controller. What other options do we have?

We have numerous bin files at this location: https://drive.google.com/drive/folders/1jCz38F02jS2BBUF2_Hay31ICoPYuHyWk?usp=sharing

Let me know what else I can provide?

2 Likes
2

I donā€™t have access to the logs.

3

I was hoping the Google Drive link would prompt for access. Try this link: Drone Flights - 2022.11

It provides access until the 1st of December 2022.

4

What are you asking someone to do with 25 log files?

5

Sorry, that was for @Leonardthall who requested the log files. We have a Dolphin issue when using terrain follow. We also see instability when using optical flow. Previously in another post we noted a parameter called PSC_TC_Z which we do not see in Copter 4.3.0.

We made some changes to our sensor output using a low pass filter and now the dolphin fly issues seems to be resolved. At least for now. Weā€™ll have to test more environments.

6

I am not looking through 25 log files. You will need to point to a specific log file.

8

Leonard, below is a link to a single bin file. You will see some dolphining between timestamp 18:00 and 19:52 when viewing RFND and BARO[0] altitudes. The RFND should be more or less a flat line when surface tracking, but we have an altitude oscillation. For now I would like us to ignore the noise after the 20:00 time mark. That is related to sensor data collection and pitch data from the flight controller.

We are not sure what PID to tune to remove the altitude oscillation? The standard PID parameters on the extended tuning page of Mission Planner relates to Roll, Pitch, Yaw and Velocity XY. The altitude hold has gain only. That leaves us with Throttle Acceleration. What am I missing?

image
image1603Ɨ636 56.7 KB

00000107.BIN

9

In that log the firmware is 4.1.4 - you should definitely upgrade to latest stable.
There are very important fixes included for the Cube Orange, and much more.

What motors, props and ESCs do you have? Is it the T-Motor integrated motor/mount/ESC combination?

I think thereā€™s basic tuning problems to be solved before you can properly investigate rangefinder and altitude issues.
Thereā€™s sections where Pitch/DesirePitch and Roll/DesiredRoll have parted ways and Iā€™m a bit surprised you are not reporting a loss of attitude control and possible crash.

image
image1584Ɨ833 17.4 KB

image
image1601Ɨ836 15.6 KB

I would start by setting these, even though they are not directly related to attitude or altitude
ARMING_CHECK,1
ATC_THR_MIX_MAN,0.5
BATT_FS_CRT_ACT,1
FENCE_ENABLE,1 ā† check other Fence parameters
PILOT_THR_BHV,7 ā† I believe you have a spring-centred throttle

Your motors are sometimes hitting their minimum spin value, set
MOT_SPIN_MIN,0.15
This can cause what appears to be instability, when attitude control cant do what it needs to.

Yaw is the only axis that is working OK, but I suspect having Yaw PIDs twice the value of pitch/roll PIDs is taking too much away from the other axes
I would set:
ATC_ANG_YAW_P,5
ATC_RAT_YAW_I 0.08
ATC_RAT_YAW_P 0.8
This may make yaw a little less locked in than before, but you can deal with that later.

Set these to aid tuning
INS_HNTCH_ENABLE,1 ā† set this then refresh params to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.16
INS_HNTCH_FREQ,45
INS_HNTCH_BW,23
INS_HNTCH_FM_RAT,0.7
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4

You pitch and roll PIDs are a bit odd, I would do a test in Stabilise and AltHold (no payload) with these
If there is reasonable stability, then do some pitch and roll maneuvers and try Loiter mode.
ATC_ACCEL_P_MAX,40000
ATC_ACCEL_R_MAX,40000
ATC_ACCEL_Y_MAX,14000
ATC_ANG_RLL_P,5
ATC_ANG_PIT_P,5
ATC_RAT_RLL_P,0.12
ATC_RAT_RLL_I,0.12
ATC_RAT_RLL_D,0.003
ATC_RAT_PIT_P,0.12
ATC_RAT_PIT_I,0.12
ATC_RAT_PIT_D,0.003
If there is slight instability, reduce the ATC_RAT values by 10% and retest
Letā€™s see that log file.

10

Also I suggest you set these
BRD_BOOT_DELAY,3000
GPS_GNSS_MODE,7
to ensure the GPS unit boots up before the flight controller
and to limit the number of constellations and settle down the update rate (GPA.Delta in logs)

You can probably drop the raw IMU logging and fast attitude too, unless thereā€™s a specific reason.
LOG_BITMASK,442366
Youā€™ve already got PID logging so that should be enough for basic tuning, although fast attitude is handy if thereā€™s tuning difficulties.

11

We pull the IMU data through the MAVLINK paramter Attitude. We run a line sensor and have to correct for pitch in the data, that is why we log the IMU info. We are unable to get a datastream with an update interval of less than about 250 ms from the attitude parameter. Is there a way we can get the pitch from the flightcontroller at about 40 ms intervals? I have not looked at the possibility of using SCALED_IMU. What is your suggestion?

12

Logging raw IMU and Fast Attitude is not causing excessive load, so thereā€™s no real issue with them. I only suggested turning them off in case they were confusing the issue.

Are you saying the copter should follow a line on the ground? with corrections from the ground station?? Please feel free to correct me, but I dont think I can help with any of that. I am certainly no guided mode/mavlink expert by any stretch of the imagination. I see you already have the serial ports set to relatively high speed, 115k baud.
Would it not be better to run a LUA script for corrections, or a companion computer onboard?

What I am suggesting is improving the basic tuning, which will hopefully allow any advanced issues to stand out more.
Weā€™ve often seen people asking questions about why something is not working well in guided mode or missions, yet their basic tuning is either not attempted or terrible. That makes it hard to tell if there is an actual issue with their mission or guided mode commands.
Iā€™m not saying your tuning is that bad :slight_smile:
I would persist with some additional tuning though, and use RC to test, until pitch and roll are doing what they are meant to do. Then see how the missions are affected and what needs altering.

13

The test flight team reported more instabily following above process. They reverted back to previous parameters and ran auto-tune for roll and pitch.

What part of the PID is used to run control for altitude position setpoint? Alt Holt, Acceleration? We see for xy position, but not for z, except the alt_hold parameter. I am refering to the extended tuning page in mission planner (see image).

Part of our oscillation stems from the rangefinder signal lag. This lag comes from the implemented low pass filter. We are going to dial back on our low pass filter cut-off frequency (make it larger) to reduce the lag, but we still need to know where do we tune the control loop for altitude?

image
image1093Ɨ1003 205 KB

14

Hi @hbrenkman,

There are a lot of changes between 4.1.4 and 4.3 in the terrain following. I suspect there are a few things we can do better in this area. However given you are running old firmware it is difficult to help you.

15

Thanks for the info. We upgraded to the latest. We also made changes to our rangefinder code in order to remove lag. Plan to test Thursday and Friday. Weā€™ll update new bin files once we have them.

16

Ok, if you are not using the standard release, I canā€™t help you.

17

Just to clarify, if you are using the standard release I may be able to make changes to address the problems you see if the existing flexibility canā€™t address the problem. But when you use custom code that is no longer an option.

18

Yes, we are using the standard release. Copter 4.3.3.

19

Then I donā€™t understand this:

Can you please explain?

20

The changes relate to a radar sensor we use. We had some lag originating from the radar sensor output due to filter implementation. We changed our code and now it gives a very good signal without lag issues. The lag was visible in the oscilation when we fly with terrain follow enabled, or shall I say, surface tracking. You will see it in the previous log posted. We just tested our new code this morning and do not see lag. We have not yet tested with terrain follow on. So, no we have not changed any ardupilot code, just our own sensor code.

23

I still believe you should improve the tuning using the params and methods I provided.
Dont run missions and such, just concentrate on the tuning and get it right - then do the missions and radar fault-finding.
Thereā€™s no way that autotune produced the results you pictured in that screenshot. And the Harmonic Notch Filter settings were not even updated.