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
That makes sense. I was hoping a dev would get back to me. The condition for using 3.3 is written as
#if HAL_CPU_CLASS < HAL_CPU_CLASS_75
# error ArduCopter ver3.3 and higher is not supported on APM1, APM2 boards
#endif
which I was hoping meant that flymaple was ok. I'm making my own board and I have the same chip as flymaple.
Jared,
Thanks for finding the specific compile issues. This is more of a dev question so it'd be better to bring it up on the drones-discuss email list. I think we just don't know if the EKF will function on the FlyMaple (and similar). If it can run the EKF at 400hz then we can easily modify those #if lines that you've found so that it compiles for the FlyMaple again. If the CPU isn't up to the task then I'm afraid we will be forced to drop support for the board and I'll modify the #error message so it pops up the failure for anything with CPU_CLASS < 150.
The timing on the board can be seen by looking at the dataflash log's PM message. There's a number of long loops and maximum loop time.
Jared,
I have no experience with flymaple, but if your board is HAL_CPU_CLASS_75 then the error message is correct since APM:Copter 3.3 does not support APM2 boards any longer due to EKF and you should look for the 3.2.1 branch which should work.
Best regards,
Thorsten
The APM boards are HAL_CPU_CLASS_16, not 75. Config.h explicitly allows cpu class 75 for v3.3, but the code wasn't written with that in mind.
I'm just curious if they meant to allow it, and then didn't take care of it properly, or if it wasn't supposed to be allowed in the first place.
Thanks!
I didn't get an error message; I got a compiler error. config.h says that class 75 is ok to run 3.3, but the code wasn't written to support it. I'm just curious which was the error.
Hey guys. I have one "bug" for you, and one question.
1) Drift mode seems to have lost it's altitude hold. In 3.2, drift mode was modified to include Alt Hold which is awesome. Its a great model for aerial video due to the smooth "coordinated turns". But it seems to have rolled back to the old version of Drift mode where Alt Hold is not in place.
2) This may be elsewhere in the thread, but I can't find it in 190 pages. Are there parameters I can change to speed up the auto tune process? I realize this may sacrifice some precision. But it's ineffective right now when the battery gets too low to continue. Can I speed it up, or do one axis at a time or something?
Thanks Edwin and Henri!!!
Thanks. I'll use those features and probably do it one axis at a time.
@Pedals2Paddles: Yes one axis or combination of axis if your battery can handle long flights..
In mission planner from the complete tree open the autotune tab and set the axis you want as follow:
Autotune Bitmask: 0:Roll,1:Pitch,2:Yaw
VALUE MEANING
7 All
1 Roll Only
2 Pitch Only
4 Yaw Only
3 Roll and Pitch
5 Roll and Yaw
6 Pitch and Yaw
You can do one axis at a time or a combination of them:
http://copter.ardupilot.com/wiki/configuration/arducopter-parameter...
-
324
-
325
-
326
-
327
-
328
of 558 Next