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:
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.
ArduCopter 3.2.1-rc2 is ready for testing and you can download it from the MP’s beta firmware’s link. The list of changes from -rc1 is:
1) Bug Fixes:
a) prevent infinite loop with linked jump commands
b) Pixhawk memory corruption fix when connecting via USB
c) vehicle stops at fence altitude limit in Loier, AltHold, PosHold
d) protect against multiple arming messages from GCS causing silent gyro calibration failure
The last item #1d was causing the “pitch drift” reported by Itay (and also Marco) and we’ve determined the cause is the MP is sending two arming messages to the copter which were interfering with each other. We now reject the 2nd one which unfortunately leads to a confusing message, “Error: command rejected by MAV” but the vehicle will indeed arm. It’s safe to ignore this message and I suspect Michael O will release a new version of the MP which resolves this in a reasonably short period of time.
If all goes well we hope to release this as the official AC3.2.1 release next week.
this is for APM and Pixhawk or just pixhawk? On item 1C, does the vehicle stop and return or it just still fly and wont go any higher than the limit?
I believe it's for apm as well as it's a revision of 3.2
3.3 is going to be Pixhawk only.
I'm hoping that it means the uav will hit the altitude or perimeter fence and just sit there until the operator pulls it back. Possibly with a user definable option (individually for height and perimeter) to choose between rtl/land/sit there on reaching the fence to make it the ultimate geofence :D
Randy / Devs
I have noticed that when in pos-hld if I left go of the stick while it's moving forward [ say 5mps or above ] it glides to a stop but then returns several feet. Is there a way to have it glide to a stop and stop there and not return? It's like it tries to return to where it was when you left go of the stick not stop at where it's forward motion ended. I find this hard to fly in a small area with obstacles. Is this related to the braking setting? Is this at all what was addressed with the wind compensation fix? I haven't had a chance to fly rc2 yet. Thx
thanks yeah i hope the same, i like the idea of a ceiling but i hope its just wont stop once it hits the ceiling but continue to fly in its direction. good way to maintain a proper altitude, imho
I'm leaning the other direction on this. I have my fence set strictly for safety purposes. For me, if it hits the fence, it needs to RTL or Land because something went potentially wrong. The idea of having it helplessly stop at the fence and stay there till the battery died doesn't sound nice at all. Perhaps a dual purpose fence option depending upon what one is using if for?
1c is just a fix to make the fence work the same as in AC3.1.5 in that the vehicle stops at the altitude limit if the vehicle is in AltHold, Loiter, PosHold or Sport modes (modes where the pilot controls the altitude with the throttle stick).
For AC3.3 or AC3.4 we will likely have the vehicle also stop at the fence perimeter in these manually controlled flight modes. When we do this we could probably add a parameter to allow choosing the behaviour when it hits the fence (i.e. stop or RTL). We probably always want the vehicle to RTL if it's in AUTO mode 'cuz we wouldn't want the vehicle getting stuck out on the fence.
P.S. when I say "stops at the altitude limit" I mean that it stops climbing. It will still keep moving horizontally in the direction you push it so I think it will do what Thor is looking for.
Sorry for asking this question late. What is PosHold wind compensation fix? Was there any issue with that flight mode earlier?
I'm glad to see I am not the only one with Position/PositionHold problems.
I also have seen ERR: Flight MODE 8 errors and this is what I have found out.
I couldn't get position hold working using mission Planner, instead used APM Planner.
I am not able to choose pos-hold on three instances of mission planner but find that instead, I have position in the list not Pos-hold.
It is invalid though, the copter with 3.2 or 3.2r1 will not switch into the old position hold mode. I have tried mission planner 1.3.16, 1.3.17 and 1.3.19, and none will allow me to select pos-hold, instead, the old "position" is in the drop down list. I have posted some information in a thread mentioned in my last post.
I did find out that if I use APM Planner instead, I have no trouble setting the position hold flight mode and it works.
Check out the thread mentioned above to see more information..
I guess you've figured it all out but just to be clear, the issue here is caused by using a very old version of he mission planner. On the flight controller side we don't force the user to use a particular version of the ground station (because there are many ground stations).
I guess we could add a pre-arm check to AC3.3 that ensures the user doesn't have any unsupported flight modes setup on the FLTMODEX parameters. That would catch the problem before takeoff at least...
Quite honestly, I feel your valuable time would be better spent refining the flight software than programming checks to verify GCS/vehicle compatibility the operator should be fully aware of and accountable for. But that's just me.....