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
Sooooo... any chance of a stable final release for APM users? One without pitch/roll issues on takeoff and altitude hold issues?
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.
vibro.png
Marko,
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.
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
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.
Thanks!
2015-04-10 09-37-47.log
Hi Mihail,
please see https://github.com/diydrones/ardupilot/issues/1952 (closed invalidly(read the comments and read #1951 before that) and this comment by the developer http://diydrones.com/forum/topics/arducopter-3-2-1-beta-testing?id=...
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.
hzl
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.
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.
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...)
hzl
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
-
1
-
2
-
3
-
4
-
5
of 59 Next