ArduCopter 3.2.1-rc2 (release candidate #2) has completed beta testing and has been released as the official version available through the mission planner and other ground stations.
Changes from AC3.2 are listed below and in the ReleaseNotes:
1) Enhancements:
a) reduced twitch when passing Spline waypoints
b) Faster disarm after landing in Auto, Land, RTL
c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
a) Add desired descent rate check to reduce chance of false-positive on landing check
b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
c) PosHold wind compensation fix
d) prevent infinite loop with do-jump commands pointing at each other
e) pixhawk memory corruption fix when connecting via USB
f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
g) protect against multiple arming messages from GCS causing gyro calibratoin failure
Thanks to Raph for the video. This is actually a video from AC3.2 until we have one specific to AC3.2.1.
Replies
I have just uploaded this beta firmware :) cant wait to test it on my newly revamped quad.
Looking that release notes seems it might be safer that 3.2! ha Cant wait to giver-er a go. Now if the winds would just back off dang it!
Yes, x.x.1 and later revisions are normally bug-fixes, not feature additions, so are usually "safer" than what came before.
I noticed the pitch drift on first arm , both on pixhawk , and apm , and from ver 3.2 , 3.2.1 , to 3.3.dev
have any of you noticed it? is it predictable behaviour ?
should I expect a small drift after arm ( I mean , when the board sits at the table next to me)?
have you had it?
Hi,
I have the latest 3.2.x stable on an APM 2.6 clone, having the same issue. The problem is the drifting does not stop at the second arming, but i have to re-calibrate the accel. Another weird thing is, when the calibration is done, the altitude jumps to about 30m, then slowly comes back, showing bad GPS health in the meantime. After ~50sec the altitude comes back to 0-1m. It starts working at the 1-5th try. Im a bit sad about it. Did not yet revert it back to 3.1.
What should I look after?
Marcel, I think we should have a look at your IMU numbers. Can you set it to log while disarmed, then from a "cold start" (ie: not run for 1 hour), boot it up, and just let it record data for 10 minutes. Then let us have a look.
Nice video, impressive beachs, thank's for share :)
Please forgive my posting a feature request here --- I am unsure where the appropriate forum is to be found.
Request for ability to set PILOT_VELZ_MAX for ASCENT and DESCENT independently.
Scenario:As part of volunteer search and rescure service I fly a large hexacopter armed with a Flir Tau thermal camera. Flight path is always similar -- Ascend 600m following the contours of a mountain towards a cliff face, then follow a ledge on the cliff face for ~ 500m before flying home.
Owing the the mountain blocking out half of the sky I prefer to fly home using Alt Hold mode to control rate of descent. I have set PILOT_VELZ_MAX to 2.0m.s^-1
At rates of descent greater than 2.0m.s^-1 the vehicle becomes unstable.
For simplicity sake I would like to be able to climb at Max throttle and Descend at Min throttle with the FC governing these to 3.5m.s^-1 for ascent and 2.0m.s^-1 for descent.
I believe a steady descent may save time and battery.
Many thanks
Enhancements requests normally go in the github issues list but this request is already there actually. It's not very difficult, it's just there are so many items on the list.
Hi Dylan,
I guess we can consider this, but the need is not very great considering this can easily be managed with the pilot's throttle stick.
As for the descent stability, have you tried descending at full rate, while moving the copter laterally? This usually avoids the problem of Vortex Ring State which is what causes the instability in descent.
-
55
-
56
-
57
-
58
-
59
of 59 Next