AC3.4-rc1 Testing Today

ArduCopter Copter 3.4
1

Loaded the 3.4rc-1 today on my MQ600 Quad with a Pixhawk on board, and got 5 flights with no issues. I did no calibrations or other setup from previous 3.3.3 software for the first flight. First 2 flights in calm wind, flight 3 in 10~15 Mph wind with greater gusts as a front was rolling in. 4&5 in light breeze.

Flight 1:
Take off , fly and land in Stab=OK
Take off fly and land in At Hold = OK
Takeoff, fly and land in Loiter = OK, Did notice some toilet bowl, and redid compass cal before 2nd flight. This may have been due to a remounting of the telemetry TX that I made prior to the first flight with this software. 2nd flight after Cal was with no further issues.
Circle mode, made 4 turns = OK- MP replay looked like a compass was used to draw the flight path on the screen !

Flight 2:
Auto 6 way point Mission with RTL = OK, landing within 2-3 feet from takeoff spot.
Manually triggered RTL from 30feet altitude and from 150 feet = OK
Low Battery warning with RTL = OK.

Flight3:
PosHold = OK
Fence = OK, triggered on altitude 2 different times. Set in MP at 150 feet, triggered at 163 feet both times. = OK, but noticed a bit of a sudden drop as transition to lower altitude as RTL was triggered, pretty much the same behavior on prior version of the software. Also saw a “Compass Variance” message which cleared after about 5 seconds after the RTL kicked-in.

Flight 4 & 5 , just flew a lot in Alt Hold & Loiter with Mobious camera installed, no issues.

Machine seemed way more snappy to control inputs in Stab and Alt Hold, with this version. I may need to lower RC Feel on this version, currently at 50%, but so far it’s been a great flying experiance. It was perfectly stable in the gusty weather with no surprises.

I hope to do more flight mode testing later this evening if the weather cooperates.

Great job and a big Thank You to all who developed this.

Questions:
On startup after the before the second flight( after the Compass Cal) I heard "Change EKF GPS Type to 1 " message in MP, what is this? Didn’t occur on flights after that first reboot after Cal.

Is it safe to try this on my PixRacer which is doing fine on the 3.3.4. software?
Thanks again for all the work into this release.
Joe

2

[Please use a new topic, for a new topic, it works much better in discourse with many topics and less gargantuan single topics, Thx :slight_smile: ]

3

Joe,
Thanks very much for the testing and detailed report.
We’ve made some changes to the attitude controllers and that involved modifying the scale of some params. It should convert the parameters as part of the upgrade but it’s slightly possible that the gains are modified a bit so we will keep an eye on this.
I’m not sure what the message is, I can’t find anything similar by searching through the code. The closest thing is the GPS detection string which is something like “GPS 1 detected as UBLOX at 38400”. If you see it again, maybe you can write down the exact string and I’ll have another look.

4

Also if you have a dataflash log that could help us get to the bottom of the message.

5

Randy,

Thank you for taking the time to read my report.

The message I received was received using Mission Planner: 1.3.38 Build 1.15990.37365 during the Compass Cal process, and in the next log after the re-boot after that process.

It doesn’t show up in subsequent flight Logs.

As I did not have Per-Arm Logging selected, (had Logs set at 163838), I have no Data Flash logs. I have - hopefully- attached the TLogs that show the message "Changed EK2.GPS-Type to 1.

The message “Changed EK2.GPS-Type to 1”.doesn’t appear in any flight Logs past these two that were done during and after the Compass Cal process. ( All done with 3 cell flight battery connected, R.C. Xmitter ON, and calibration done using “Live”- (not On-Board)" with radio telemetry feeding data to MP during the “Compass Dance” procedure.

This FC is an RCTimer Fixhawk 32bit Flight Controller V2.4.3 that I purchased in September 2014.and its’ accompanying GPS/Compass, if that helps explain this message.

Thanks again for all your and the other developers efforts.

Joe
2016-05-28 13-49-06.tlog (116.7 KB)

2016-05-28 13-44-07.tlog (441.5 KB)

compass cal.png1366×768 411 KB

6

I’m seeing this message too. Found this in AP_NavEKF2_VehicleStatus.cpp:

// Check that the vertical GPS vertical velocity is reasonable after noise filtering
bool gpsVertVelFail;
if (_ahrs->get_gps().have_vertical_velocity() && onGround) {
// check that the average vertical GPS velocity is close to zero
gpsVertVelFilt = 0.1f * gpsDataNew.vel.z + 0.9f * gpsVertVelFilt;
gpsVertVelFilt = constrain_float(gpsVertVelFilt,-10.0f,10.0f);
gpsVertVelFail = (fabsf(gpsVertVelFilt) > 0.3f*checkScaler) && (frontend->_gpsCheck & MASK_GPS_VERT_SPD);
} else if ((frontend->_fusionModeGPS == 0) && !_ahrs->get_gps().have_vertical_velocity()) {
// If the EKF settings require vertical GPS velocity and the receiver is not outputting it, then fail
gpsVertVelFail = true;
// if we have a 3D fix with no vertical velocity and
// EK2_GPS_TYPE=0 then change it to 1. It means the GPS is not
// capable of giving a vertical velocity
if (_ahrs->get_gps().status() >= AP_GPS::GPS_OK_FIX_3D) {
frontend->_fusionModeGPS.set(1);
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_WARNING, “EK2: Changed EK2_GPS_TYPE to 1”);
}
} else {
gpsVertVelFail = false;
}

7

@Crow57,
Thanks for looking into that. So if that was happening during a flight then I think it’s not good but but it’s not too bad either. We definitely want 3-axis velocities from the GPS but I think the vertical velocity is the least important.
I’ve dropped a skype message to Paul so I hope he will see and comment on this issue.
For me, the question becomes, should we log an event (or maybe even an error) in the dataflash logs? Maybe we should downgrade this message to an “INFO” message if it’s not that important?