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 too wondered about that ...we flew earlier without issue but noticed this Hdop reading being too stable .. but if you put your hand over the gps it does move the Hdop higher... the flight earlier was not a mission just a hover to do a 360 .. Would the GPS give Ekf Hoz error and velocity that i have just seen in the Tlog play back ?
Cheers Richard
Hi,
I would like to know if the last APM2.x Firmware 3.2.1 is also affected by the Follow-Me / aborted takeoff bug?
Thanks
Hello, my name is Antonio, sorry for my English but I'm Spanish, I want to thank the community for your help, I have long troubled in my flight controller, but thanks to version 3.4 beta'm flying without any problem, never and blow my F450 seen as stable and not have flyaway before EKF had many flyaway's mistake, compass, etc, my poor f450 was always in the starry floor, now flies with clarity, smooth, stable.
Thank you.
Antonio.
Hi Guys
I have been trying trouble shoot some issues ... firstly is there an updated tone listing somewhere, as the one on the wiki is incorrect .. for instance if i remove my SD card i do not get the same tone as i do with 3.3 .. earlier FW is fine.
I also have no Boot.log file on the SD card to see if I can spot some boot issues ? I have tried to reinstall the FW but this makes no change..
I get three beeps after the board has booted and then the esc's arm ( disabled safety switch) with re enabling safety switch the esc's beep until the safety switch is pressed.
Update .. after re-enabling the safety switch the tone from Pixhawk still gives me the three beeps..not sure why i get these beeps. None of my other machines do this, one is on 3.2.1. the other on 3.3 .. i will upgrade the 3.3. to 3.3.2. and see what happens on the other machine .. as that one does not beep three tones or even beep the esc's even when the safety button is not pressed..and it operates just ...i the wiki is well out of date ..i this does not help my trouble shooting.
https://youtu.be/u2s00Addht4
regards R
Been playing with Acro trainer mode today - set on 3-pos switch. Strange thing is I managed to do a back flip on both trainer modes, so wasn't being limited to 45deg in the second mode (pwm > 1800). Strange!
Paul,
Yes, I've found the same thing a few weeks ago and brought it up with Leonard and I think he's hoping to fix it in Copter-3.4 or maybe a patch release of AC3.4. Probably ahead of that we should fix the documentation and parameter descriptions so that they're not misleading.
Been wondering if it I have a problem, or there's a bug in the ESC calibration mode.
Been running a pixfalcon for a while since 3.3.0 and recently came to do a rebuild / update to tidy some wiring and software updates to arducopter, OSD and crossfire. Went all ok, upgraded the BEC to a 20A CC PRO (set to 5.1v), and decided to do all the calibrations again, just for maintenance. Everything went ok...except for ESC calibration.
My normal process is the "all at once, two power cycles at full throttle" method, and indeed, all 4 Flame 80's signalled the end points had been set. Now normally, I blip the throttle a few times, just to make sure the ESC"s are indeed firing up at the same time. Worked before after all.
But not this time. Powered up, and all motors started at the same time...then after a split second, refused to respond to throttle commands. Worse still - after about 10 seconds, all motors wind up to what looks like full power. Only way to break in is the safety switch or the batter unplug.
Thinking this was a fault or an issue with the ESC's (the pixfalcon only has signal on the motor out ports, and since the Flame 80's need 5V & GND I needed to plug these into the 5V BEC), I plugged in a spare Pixhawk, since there would be 5V on the servo rail. Same issue - enter ESC calibration mode, do the end points successfully, spools the motors, and...locked out again. The motors seem to be working normally in normal mode though?
Just to be doubly sure, I connected the 4 ESC"s direct to the Crossfire cutting out the pixhawk completely, and did the end point calibrations...and it worked perfectly.
Did the ESC calibration mode get changed in 3.3.2? Why am I lose motor control in ESC calibration mode I'm kinda scared to put it back in the air, in case there's a sudden full throttle lock out incident.
I noticed that too with sn20a ESCs running blheli, but since I was runing PX4 mini I yhought its a glitch on the board side. Your comment makes me wantnto revisit calibration wiki again and see if it says something new.
Heh, so sn20a's have their own problems :) I have just switched from sn16a's running BLHeli 14.3 to RG20's running BLHeli 14.1 because of all the reports of FET's moving/burning under load. I haven't seen any of this, but I would prefer not to take the chance since I want to try 4s eventually. I have to say though the RG20's are BIG - I have them mounted in a QAV250 and it was a very tight squeeze.
With the sn16a's I would get one ESC singing out of tune and again the issue with calibration not always working. I also had one ESC record bad min/max - something I only picked up when I hooked up the ESC to reflash. I got rather paranoid at that point and started checking the ESC settings through BLHeliSuite after doing a calibration. The RG20's which are SI rather than Atmel based seem more predictable, but I haven't flown them yet so time will tell.
-
40
-
41
-
42
-
43
-
44
of 558 Next