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 cannot get serial 2 to work on this RTFQ radio; haven't tried Serial 1 but 3DR V2 works fine on Serial 1.
For $30 it was a low cost alternative to the 3DR version, but I'm done messing with it, will bite the bullet and get the 3DR.
this is not Radio's fault.... I have tried multiple radios and even an FTDI connection through 2 of the serial ports in-front of the X2 they seem to be non-functional at least on my board. I have spliced the serial connection from the serial port near the USB as a work around, but soon I will be connecting an alexmos gimbal and will need to figure out why that serial connection doesn't work. (this is my only complaint about X2). I will try running 3.1.5 and see if that'll help as well as I'll try to power the accessories I am connecting to the serial ports separately (minimOSD, teensy and the telemetry radio)
Hi guys .. I have just spent the last 4 hours testing the different radios with two AUAV X2 boards.. it does seem there is a difference, when using 3.1.5 it appears to connect the most reliably, i.e first go On UART2 (S1).. 3.2.1.and 3.3 I have to attempt to connect a quite few times before it takes almost to the point of giving up .. I have noticed that using the other port UART3 seems to be better at connecting on the first go. but I am lead to believe UART3 has a lower amp rating than UART2 I also notice in the parameters screen there are different Parms shown in the S0 S1 S2 Ports section between 3.1.5.and .3.2.1. ..If I enable CTS and RTS .. I can not connect at all in any firmware version ? One radio has the CTS and RTS wires connected to the UART 2 port ..so 6 wires I assume you connect CTS and RTS crossed as you do with RX and TX ..anyway I tried both ways and no go ..
I am using only the Rx and Tx, not CTS/RTS so try to connect via S2 (4 wires). The radios talk, but Mavlink connect is a no-go.
Hi .. have you tried to switch rx and tx wires around ? also try the UART3 connector pins I find these were connecting well ..if you have trouble with the UART2 plug ..Which firmware do you have on the radios and also which FC firmware are you using?
What I have noticed is .. IF the little RED LED is blinking on the AIR side radio.. Then you will Know for sure it will connect when pushing CONNECT in MP .. if the red led is not blinking slowly ..then the FC has NOT seen the Radio .. re boot ..or check RX and TX wires
Rx > Tx and Tx > Rx.....that's how they are wired for the S2 pins. I have not yet tried UART2. What type of connector is it?
FW:
1.9 on the radios
3.3 rc1 on the FC
On the air radio, there are 6 solder pads. Do you know what corresponds to RTS and CTS?
EN
TX
RX
VCC
CO
GND
HI DG .. sorry no I don't know which two are CTS and RTS .. for now don't worry about connecting them .. it usually does not need these connected just use VCC GND and RX TX did you try switching them ? I take it you are using UART 3 .. Also be very sure the settings are the same on each radio .. and make sure CTS enable is UNTICKED
Quick googling will return CO -> CTS, EN-> RTS
Hi
Tests Quadrocopter all the time and I have a problem that previously did not exist. Increased vibration levels appeared cyclical peaks, perfectly balanced drive, hovering vibrations contain from +1 to -1, and never had these peaks are now shown on all axes. Despite such a bad plot, quad very nicely and predictably behaves in the air. I do not know whether to worry about the vibrations? is it normal that the x and y axis spread, during a quick flight up to the speed of 22m / s
2015-04-23 19-29-06.bin
Wow! This looks weird!
This is very periodic. The question is where the vibes are shown more accurately: in the case of the peaks on in between? If it are the peaks the vibes would be much too high. Strange. Need to test rc1 asap.
I don't think you could say that the peaks or the plateaus are more accurate. What is happening is the accels are sampling at very high rate, and reporting unfiltered data. Arducopter is only logging at a relatively low rate.
What we could be seeing, is something like a beat frequency from several vibration sources, and the low-rate sampling is only picking up the peaks relatively rarely. Full-rate logging would give us a better picture.
-
523
-
524
-
525
-
526
-
527
of 558 Next