Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
I've also asked MichaelO to create a setup page.
Thank you both for the information. My failing was being in the OpenTx paradigm as I was searching for a way to define which of the two input choices went with which of the four possible outputs. Happily I didn't need to worry as the firmware sorts that out for me.
Yes, the way this works basically, is that there's some logic which handles the landing gear, which is looking at the state of an internal switch, as well as a few auto-modes, such as RTL, etc. That internal switch is manually controlled by whichever RC Input you choose.
The controller decides if the gear should be up or down, based on a blend between the state of the switch, and the flight state of the vehicle (forced down when landing). Then it publishes a LG output state to the RC Output controller. Like "Hey, whoever is controlling landing gear, go down!"
The RC Output controller checks to see which channels are defined as controlling the LG, and makes them act accordingly.
In fact, I think you could have more than one output channel set to LG, and it would just work. So you could have two LG controllers without using a Y-splitter if you wanted. (You cannot have to LG switch inputs however).
Mike,
In the Extended Tuning screen you are setting your input channel for manual gear up/down.
With RCX_FUNCTION you are telling to the FW on which AUX channel your gear servo is connected, ie your output channel.
The fw is using that info to manipulate your gear either in automated mode (Land, RTL) or in manual mode with Ch7/8.
A little different to setup then the gimbal, which setup screen has input/output channels, but it works in a similar way.
HTH
Have others experienced a lot of noise in Rcout and increased vibration levels on rc7? I'm used to seeing .5-1 vibration levels vs 2+. I opened a few logs pre-rc6 and the data looks completely different. Mechanically only the props changed and new case for the AUAV-X2, but I had these props on before and didn't exhibit these high noise levels. The wiring for the new case was not removed from the board, basically a transplant; new 3DR vib foam was used.
Today after AT I took it back up and played with Follow Me Circle, then Face Me, and GCS failsafe kicked in (no audible warning), it went into what I assumed was RTL and just kind of floated and did not gain much altitude, so switched to stab and throttled up (when it doubt, go UP), then switched to RTL. It did not move into position to land but kept moving away slowly. I then switched to stab/poshold and it seemed ok, so landed.
I'm wondering if there is an issue with Tower conflicting with Pixhawk. This odd behavior is a first. Tower is also giving false audible voltage %.
There were no GPS glitches that I could find. Rcout is extremely noisy. Vibration levels higher than normal.
Link to file (it's 90mb, includes AT and rest of flights) for anyone interested
http://www.mediafire.com/download/o7b4v1nja0kyh8i/2015-06-30_20-10-...
Hover after AT and switch to APC MR props was pretty good.
https://youtu.be/S0mTA68dKv0
DG,
Thanks for the testing & report.
I had a quick look at the logs and I don't see any particular issues. The vibration levels (see VIBE message) are pretty average. X-axis is higher than the other two (normally Z is the highest) but in any case, the levels are not terrible.
As you suspected, the vehicle entered RTL while it was in Guided mode probably because the connection to the tablet failed. I would have expected Tower to cry out "lost connection with vehicle" but that's really up to the GCS developers. Although the vehicle would have updated it's status to "CRITICAL" and sent that to the GCS, with the telemetry link down, it would not have gotten through.
The vehicle does seem to climb from 4m to 10m at the beginning of the RTL. I suspect if it was given a bit more time it would have completed the regular RTL cycle. There's no record of the vehicle attempting to go into RTL a second time. It looks like you're not using ch5 flight mode switch to control modes, so perhaps it was switched using Tower? in which case, with the telemetry link down, that wouldn't work of course.
The voltage and current recorded in the logs appears reasonable with the voltage dropping slowly from about 16.6V to 14.8V during the flight. The current seems strongly correlated with the throttle output and is at a reasonable 20apms most of the time.
I completed Yaw autotune successfully then tried some flight modes.
RTL doesn't seem to work on my quad (rc7). It just hovered there at current location and altitude. It's supposed to climb to 20m, fly to the launch point and hover for 3 secs before descent.
I had manually maneuvered the quad to about 8 or 10 meters from launch point and tried RTL, twice, going back to Loiter between tries. I had 10 to 11 sats and hdop = ~1.65.
Other than that, things went very well & I even tested Emergency Stop on landing which is real handy.
Screen Shot 2015-07-01 at 11.23.57 AM.jpg
hi,
tried flying a hexa with master branch this morning (pulled latest 12 h ago), which I guess is much like 3.3 rc 7. Previous 3.2.1 flying went ok in manual mode. Felt bold so went directly to guided mode and armed (with newest APM SW). Got annoying EKF variance error (struggling with it for a few days and not knowing why i get it) so disabled that check. After arming, the drone went crazy; it took off in a strong left-tilted way and crashed into my house. Only thing i ever did was arm. I had rc on so I could flip to stabilize mode quickly, perhaps the throttle being at mid-position had an influence even in guided mode.
Not a good day for flying.
15-06-30_13-37-42.bin
@Heddn,
I think the reason for you crash is the same as why people were crashing with -rc6. Master does not yet include the patch that resolved the attitude issues found in -rc6 because the fix affects plane and rover so I need to get the plane/rover guys agreement first (Tridge and Grant). Hopefully we can get that into master soon, until then, stick with -rc7!
Randy,
I thought that this patch solved it:
https://github.com/diydrones/ardupilot/commit/686b1137fa18713124868...
Maybe he just missed it...