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.

Views: 57458

Reply to This

Replies to This Discussion

We have experienced an unexpected crash that is really hard to find reasons for.

Our system is being designed to be able to fly without ever switching RC on, so most of the time it is controlled by rc_overrides and uploaded mission. There is also some logic in firmware to handle overrides in case connection with GCS is lost. We also have a possibility to switch back to RC using designated channel that decides "now RC is back in charge".

Flight was going well, when at some point operator turned RC on, which triggered some mode changes: Stabilize -> Guided -> Auto -> Guided -> Auto. It's kinda messy, but that's not the main problem. Somehow, being either in Guided or Auto mode (which consisted of Takeoff and Loiter Unlim) autopilot decided to drop ThrOut to 105 which resulted in very rapid brick-like descend.

The only thing that I can find in firmware that could produce similar result is line:

  attitude_control.set_throttle_out(get_throttle_pre_takeoff(g.rc_3.control_in), false);

but it is triggered on `ap.land_complete`, which should be visible in log (it is not).

Otherwise I'm completely lost. Can anybody give pointers about where I should be looking?

Our firmware version is V3.2.1 stable with some modifications concerning RC overrides.



Randy is there a chance that 3.2.* firmware will get rid of this "oversensivity"?

I've rebuilt my copter, vibroisolated controller, got somehow steady flight, then added weight to controller (to add more inertia to controller and make it less sensitive to small vibrations). It lowered vibrations but made fluctuations worse.

The worst is that it's very inconvenient to use new MP with old firmware like 3.1.* because some functionality just don't work right. 



It's possible that we could release an AC3.2.2 which has an increased accelerometer range.  It would be good first though to confirm that vibration is the cause so I'd like a Pixhawk user with that problem to try out AC3.3-rc1.

BTW I recommend using the 3M vibration dampening foam found in the 3DR store.

Thanks a bunch, Randy.

Is there a way to implement less resource demanding filter? Like Non linear Bayesian. Of course if it will be less "heavy" than EKF.

My vibration dampening mechanics is shown above

Hi Mihail,

   please see (closed invalidly(read the comments and read #1951 before that) and this comment by the developer

As they dont see any problem .. dont count on ANY support from the APM folks for this issue..

the code has MANY race conditions and unplanned for transitions caused by RCRF errors ,

(just look through the closed issues and comments to find same that are not being addressed)

I would have trouble using APM with my municipal agency customer base given the attitude their development team has shown to this issue...and to others..

We are continuing on with OpenPilot and discontinuing  the use of APM OR 3DR products...given the above.




Maybe you should use professional equipment? 

Don't get me wrong, but one should really be aware, that APM, Pixhawk and even PX4 with groundshaking computing power controllers are targeted basically to hobby or advanced hobby markets. If you need to have reliable result, you should look at pro controllers, but that's not 200-500$ set, it will cost solid 1500$++. 

On top of that, for commercial use you have all the open source to edit and to contribute if you want your mod to live in further releases. I really doubt you can modify as little as one byte of DJI A2 firmware even if you need it badly.

Final decision is up to you of course.

Well, in our case Throttle was at 1500 the whole time, so I doubt it was the same issue. We also really like the way Ardupilot is working out for us, both with planes and with copters.

This was actually a first crash we can't explain by a hardware issue, that's why I'm hoping that someone from dev team would give us some pointers.

actually in 2000-2004 we( consulting group) were on so called "professional" controllers.. pretty MUCH the same story in those years with Onavi and in 2007-2010 we were doing bespoke paparazzi Tiny release for consulting customers(military fixed wing prototypes)..

the so called professional controllers are frought with just as many if not more defects in their bug tracking bases, I was going with APM due to a customer request we look into it.. btw the IRIS is only 750.00 and was purchased for SQA.. because of safety related defects and a flyaway at a demonstration flight at a federal ag facility in 2014 its been a bench queen relegated to software testing till the IRIS+ upgrade and subsequent restarting SW/HW SQA on that base.

"professional" equipment starts at about the 5K$ level  and go into the stratosphere and that is just for the FC, and we have a few specimens of those around here also with their closed source bug ridden firmware.

      there are other FC projects like OP/paparazzi which are  run with SDLC which DO meet my "professional" needs as well as my hobby ones and I will using those in the future for FC related projects.

small hint.. a lot  of the entries at trials like ft huarche were run with paparazzi based code instead of those "professional" controllers you speak of( which actually had a poorer showing than the paparazzi code base...)


 ps dont get me wrong.. there are brilliant concepts in the APM code base.. its the SQA effort that is falling short.. and being pushed onto customers

Well, it's pretty much true.

Maybe 3dr should have paid support for demanding customers? 

May I also just add for what it's worth that I too am disappointed and feel that the developers could at least leave the APM users with a stable and problem free final firmware version at least as stable as 3.1.5 but with the improvements of 3.2.. I feel that you are leaving your loyal supporters as APM users hanging. While we all understand that some things must make way for future development please can you finish off the apm updates with a good solid final release and not leave us in a buggy midair mess that is this final release of 3.2.1?

I'm not shure if an issue in my radio programming or something to can change in the code.

What happens: when you try to pilot the cuad when it's set to LAND and you don't advertise it, the copter becomes crazy and crash or near.

When happens: if you have a bad compass heading, the copter switch to land but if you don't advertise  the change you try to continue flying, the copter becomes unmaniobrable and crash as some people reporting crashes I can notice that they have the same problem that I had, perhaps something in the code that indicates that if the pilot try to continue flying but not change to a non compass mode the copter continues land? or do something else better than become crazy?

Another scenario is when a silly woman forgot to desactivate the LAND switch and try to take off, the copter take off but them he do what he wants, when she looks the logs, the copter was switching to RTL and stab and trying to land; I check the PWM values and they don't change when I switch to LAND, they stay in the same value as the last mode. It's something that I can I do to say the copter to do something more inteligent than be crazy? The log is from the second scenario, I have the bad compass too but I don't find yet.



Randy, I do confirm that there is issue with alt hold when I switch from AC3.1.5 to AC3.2.1. The craft flies great in all modes with AC3.1.5. After loading AC3.2.1 the craft stays for a while in loiter mode but climbs with slight gust of wind. this happened with APM and as well Pixhawk. I reverted back to AC3.1.5 and the problem vanished. I understand that this has been taken care of in AC3.3 which I will try tomorrow.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service