Copter-4.7.0-beta1 available for beta testing!

I seem to have restored the EPROM so I got the QModes back. QLOITER is still odd. Stupid Realfight can really be tricky.

Going back to a Tailsitter setup 4 motor pusher I just simulated for a clinet seems like QLoiter is working fine. My thinking is the Bi Motor rig that I had issues with this week is the problom. More testing.

I did additional test with circle radius set to 20m, hoping gimbal is pointed to direction based on this radius when Make Mount ROI the center of the circle is selected, but still gimbal pointed straight down after selecting circle mode with or without POI lock enabled.

Hi @Adam_Borowski,

Thanks for the report. Do you have an onboard log by any chance? Also which camera gimbal is being used?

I also wonder if you’ve ever used AP’s ROI feature with an older version of AP or is this the first time? I just suspect that something else is going wrong that isn’t related to AP-4.7. Could you try out MP’s “Point Camera Here” feature and see if you can get the pitch of the gimbal to move correctly?

This can even be bench tested (e.g. no flight required) as long as the EKF has a good position estimate (e.g. GPS needs to be working well).

Hi!

I gave this quite a bit of time, but I fear it’s still not enough. I can’t spend much more for now, but anyone is welcome to double check me.

@Quadzilla sent me his aircraft model AMDL91-6 for RealFlight and a parameter file for the 4.6.3 release.

The aircraft didn’t fly well in 4.6.3 to begin with, but in 4.7 it’s a bit worse. It didn’t crash for me at any point, though.
I also think there’s a critical problem with the parameter file: It has configured tilt servos for the thrusters. IIRC this will make the AP behave as a tiltrotor. But the actual model doesn’t have any tilts.

You can find the files I’ve generated in this Dropbox link.

Running 4.6.3

In QSTABILIZE, pitch angle is aggressive, overshoots. Roll is weak. Yaw is ok.

In QLOITER, on pitch demand, the pitch angle banks with authority, but on stick release it takes very long to recover the angle and arrest horizontal speed.
On roll demand, the angle onset is strong. Reaches 55deg roll at 10m/s lateral speed and oscillates, even though the limit is 45deg.
Yaw has good authority.

In QRTL it struggles a lot with position control after back-transition. The pitch angle really doesn’t want to play nice. Almost impossible to land, but it doesn’t pitch over and crash at any point, barring the actual touchdown.

You can find the log file attached.

4.7beta2

I tried using the eeprom.bin from 4.6.3 on the 4.7 sim_vehicle.py. Unfortunately it doesn’t seem to work.

I have to convert the parameters manually. These were the relevant parameter differences that I fixed. You can file the manually modified parameter file attached. I hope I didn’t miss any.

Q_ANGLE_MAX      : 4500            > X                 
Q_A_ANGLE_MAX    : X               < 30                
Q_A_ACCEL_P_MAX  : 110000          > X                 
Q_A_ACC_P_MAX    : X               < 300               
Q_A_ACCEL_R_MAX  : 110000          > X                 
Q_A_ACC_R_MAX    : X               < 300               
Q_A_ACCEL_Y_MAX  : 27000           > X                 
Q_A_ACC_Y_MAX    : X               < 100               
Q_LOIT_ACC_MAX   : 500             > X                 
Q_LOIT_ACC_MAX_M : X               < 2.5               
Q_LOIT_BRK_ACCEL : 25              > X                 
Q_LOIT_BRK_ACC_M : X               < 0.5               
Q_LOIT_BRK_JERK  : 500             > X                 
Q_LOIT_BRK_JRK_M : X               < 2.5               
Q_LOIT_OPTIONS   : X               < 1                 
Q_LOIT_SPEED     : 1250            > X                 
Q_LOIT_SPEED_MS  : X               < 5                 
Q_M_SPIN_MIN     : 0.4             | 0.3               
Q_P_ACCZ_I       : 0.5             > X                 
Q_P_D_ACC_I      : X               < 0.1               
Q_P_ACCZ_P       : 0.6             > X                 
Q_P_D_ACC_P      : X               < 0.03              
Q_P_NE_POS_P     : X               < 0.5               
Q_P_POSXY_P      : 0.7             > X                 
Q_P_NE_VEL_D     : X               < 0.25              
Q_P_VELXY_D      : 0.35            > X                 
Q_P_NE_VEL_I     : X               < 0.5               
Q_P_VELXY_I      : 0.35            > X                 
Q_P_NE_VEL_P     : X               < 1                 
Q_P_VELXY_P      : 0.7             > X                 

I had to also set
Q_M_SPIN_MIN to 0.3
RTL_AUTOLAND to 0
to be able to arm.

Also getting compasses inconsistent and 3D Accel calibration needed, even though ARMING_SKIPCHK=10. I would expect this to skip these checks.
Setting ARMING_SKIPCHK from 10 to 31 allows arming. Weird.

In QSTABILIZE pitch is about the same. Roll is stronger on the onset, but equally weak on return. Yaw is about the same.

In QLOITER cruising at max roll eventually induces a bad pitch oscillation. But doesn’t go to 55deg roll this time.
Max pitch stick will cause elevon flutter. Going back to zero is very slow once again.

QRTL can’t control its pitch well, goes over the limit often. Eventually settles over Home and lands vertically.

In no point did I manage to actually crash the vehicle.

The log file is attached.

1 Like

Hi,

I have log from my very short test flight with circle radius > 0 just before going to holidays. Sorry for the size (65MB) https://drive.google.com/file/d/1AX_7VYJUZeoZ8CwG7Ze5UJpUGuAuUGZ5/view?usp=sharing

Also test flight video available: https://www.youtube.com/watch?v=RCnIDZJGcy8

I have never used APs ROI feature with older versions as normally I fly without GCS and was waiting this to be available as RC option, which I belive is not with older than 4.7. I tried “point camera here” on ground and gimbal pitch moves correctly and working just fine. Good GPS position, and entering varius target altitude relative to home changes gimbal pitch as I was expecting.

Gimbal is Caddx GM2 or GM3 with XF-robot 3.8 in it. Flight and bench test with GM2.

1 Like

Need explanation Brigade :slight_smile: - Is it recommended from now? Or how it will work now?

Hi @poruchik111,

Re the change to the EK3_SRC_OPTIONS parameter, for most use cases we think this parameter should be set to 0 (e.g. do not FuseAllVelocities). This has actually been our advice for a long time (see GPS / Non-GPS Transitions and EKF Source Selection and Switching wiki pages) so with this release we made it the default.

To give more background, if EK3_SRC_OPTIONS = 1 then velocities from all sensors listed in these parameters will be fused into the EKF’s estimate:

So this could mean that velocities from both optical flow and GPS might be fused. This is fine if the vehicle is flying outdoors in a location where all sensors are functioning well but if, for example, the GPS is getting interference then it’s much better that its velocities are not fused.

1 Like

Thanks, Randy. I expected you changed some deep in code about fusing.

But not only GPS fused. I checked code and nothing changed in Ekf Fusion.

In my opinion fusing is ok. Just need more extended GPS check.

We tryed both- fuse/ don’t fuse. And I like fuse mode. My friend- non fuse :grin:.

We use external nav and GPS in EKF Source switch. One IMU. Not lane switch.

Now I work on GPS total remoove from Altitude if Ekf Z source is not GPS.

1 Like