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.
That was working. I guess you will have to go back to 3.1.5. I think the bug is still there as I seem to remember looking at the code that it uses RC3 for Throttle and not the mapped channel.
i thought i might share this with you....i had exactly the same problem. I am flying a TBS Disco, APM 2.6, AC 3.2.1 firmware. I was able to fix by doing the following: 1) Mounted the APM on top of the sillicon dampers 1)Carefully balance the blades 3) set log bitmask to default + IMU 4) Fly the copter and check values for AccX and AccY - should be between +3 and -3. AccZ should be between -5 and -15.
Since the last couple of days my hexacopter has been exhibiting weird altitude changes in loiter. It files fine in stabilize:
There seem to be some discrepancy between the barometric and GPS altitude (Log Attached). I would suspect the barometer but it has never done this before and the configuration hasn't changer. Any pointer on what to look for?
If you graph the actual GPS height it looks ok. When the GPS locked in it must have miss calculated the relative height.
Barometer looks good as it seems to be following the pressure.
Throttle out though doesn't seem to be following RCIN though.
The 'miscalculation of relative height' though has been a constant for the past few days. Here's another log of another test I just did, same problem, same rough landing. I did another test because I eliminated what I thought could have been a potential source of vibration, but no cigar.
I have no idea why the throttle is behaving that way, I'm happy to hear any good guess.
I have swapped in a spare pixhawk (brand new) and the sudden jump in relative altitude that I've seen at boot went away. I had tried completely wiping the old pixhawk parameters to default before going for the swap and that didn't fix it.
I think I'm going to try loading the old parameter file in the new pixhawk and see if the problem shows up again.
What kind of hardware problem could cause something like this? The IMU reads seem legit and I haven't swapped the GPS unit so it's got to be something in the pixhawk. Bad barometer? But the barometric altitude looks fine, what is used to compute the GPS relative altitude?
3.2.1 needs control channel interlocks between tablet/telemetry control and RC control
I had a medium bad crash today while in the middle of validating flying modes and functions in 3.2.1 .
I was verifying guided mode from a tablet without RC xmitter on did one flight perfectly of about 2-3 minutes.
GPS was missing the landing spot by about 8 ft when home commanded.
Did another flight without powering off again was pretty tame(and was monitoring telemetry and controlling flight via tablet)
GPS again variable and almost clipped grills on way down).
autolanded again and then powered on 9XR with OrangeRX OpenLRSng installed on IRIS+ and 9XR..
Heard a few beeps initially from 9XR and then used the tablet to arm in stabilize mode(and 9XR left in stab mode throttle zero)
Commanded a takeoff and then used tablet guided more to scoot around the field.. seeing battery at 11V.
I commanded home and was waiting for the landing sequence to start when I heard the 9XR beep.
I saw the mode on the tablet screen change to stab and heard the motors stop above me and then the crash sounds(10 meters drop)
unfortunately instead of mislanding in the grass the damn GPS was spot on to the takeoff spot on the concrete.
Cost so far is one tarot 2D gimbal
1 gopro hero3_black
1 telemetry radio
4 props and
my custom lightweight CF legs for the IRIS..:(
replaced the props and legs and IRIS flys fine in stab mode..
so mostly just cam and gimbal replacements needed..
1 Who is on first!!
whatever control channel was used to start the flight should be the ONLY one allowed to command a return to stabilize mode unless that control channel lost.
2. it should NEVER be possible to command a return to stabilize mode with throttle at zero in a copter that is in flight ! period!
.. it is a showstopper bug in a ready for newbie product or any product really.. no product/sw should have a crashme switch!.
while a plane can get way with this for a copter it is FATAL!
.. might as well put a crash me switch label on the mode switch!
#2 is true no matter WHAT the control channel RC or telemetry.
hzl(who is busy looking at APM code to make the above changes)
btw on the return to stabilize while in flight.. it can be allowed safely if the current throttle stick position >= current flying throttle setting .
Can you point we in the code where you think this is happening? I did quite a detailed look at 3.2.1 and could not see anything obvious, the rcmap logic seems sound (although there are some methods in RC_Channel that could mess this up, but these seem not used in APM:Copter). Even if it's something to do with the offsets, the hard over-never returning behaviour is not consistent with that.
oops make the above mode change to stabilize while arducopter in flight can be allowed safely if the current throttle stick position is equal to hover throttle or above.
I don't know where that is but I did change my RC input to match yours.
First I just reversed the channels and did a test. All went well and the copter work as before.
Then I did the radio calibration as you would due. After that I could not arm the copter Throttle failsafe.
I disabled the Throttle Failsafe and continued.
Guess what, Just a touch on the throttle and it wants to flip over to the right. Logs match what you are getting.
Maybe the good news here is don't do the radio calibration after switching back...
Interesting. I will dig deeper. It's a good excuse to get into the code a bit and scratch an itch - that was the primary reason I picked APM and not something else.
I didn't have any problems with failsafe triggering - I was able to arm fine, even after calibration. The weird thing is I "successfully" flew with an OrangeRX (still crashed due to compass issues), but these issues are with LemonRX. I do notice that the LemonRX radio failsafes are no signal by default - rather than low output like on the OrangeRX. I wonder if that's the difference. I will have to go back to the Orange to see if it still works. Weather is too nice today for experimentation though :)