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
Notice your vibs level too, that affect your Baro, and your bad gps signal, if you lost Tx signal, your copter can't RTL and fly away
I have a spectrum d8 radio. Y6B large drone with 810 frame and 16" props. Very powerful machine. I can take off after I connect the batteries as long as I don't touch the pitch/roll stick. Once I do I can no longer take off without the motors on one side spinning up fast and trying to flip the machine over. Also once flown and landed I cannot attempt a takeoff unless I disconnect and reconnect batteries. That of coarse throws off the battery percentage reporting and is a pain in the ***.
What I did see is its not just a pitch drift problem but affects roll too. If I arm in stabilise and up the throttle ever so slightly the 2 motors on the left front arm (Y6) spools up fast. By moving the pitch/roll lever to the top left position I can counter this and temporarily stabilise the motors. It does not however stay that way and soon one of the arms will start spooling up again. By moving the stick around I can cause any of the 3 arms to spool up more than the others and it will stay that way with the stick centred even after disarm and re-arm. Yet if I disconnect and reconnect batteries and take off without touching anything but the throttle the drone flies perfectly in stabilise , loiter, auto or any other mode.
It seems this problem only affects it while grounded but when it happens not even auto takeoff is an option as it will shoot off in a direction and probably flip before it gets off the ground (I don't know this for sure but unwilling to find out for sure - when moving the throttle up to takeoff with gps the spin up of the motors are aggressive on one side). Please note this machine has probably done 100 flights with 3.1.5 firmware and I never had this issue.
At a guess I would say you are using channel remapping (since you are using a D8) and that is the problem you are seeing. There is a huge problem here. If you look at the logs you will see the roll go hard over and stay there when you raise the throttle. The problem is because of the trim setting on the throttle - the firmware uses trim from RC3 for throttle rather than the mapped RC1 (and I think similarly for roll), but as far as I can see the mapping is architecturally broken. You could try manually setting the trim to the right values (i.e. with mapping), but I'm not sure I would risk it. This definitely got worse between 3.2 and 3.2.1. I have been experimenting with a fix that switches RC_Channels throughout the entire codebase and it certainly fixes this issue but is pretty pervasive and I am still having some issues with it - so I'm doubtful that even if I get it working that it would be accepted.
Yes. Are you using a PPM encoder then? You should do (nearly) exactly that. I am using an RX that outputs a PPM Sum signal and I cannot control the channel order.
Note that DX? output TAER and Pixhawk expects AETR so you should switch 1->3, 3->2, 2->1 as presuambly you have done in your channel remapping.
Also make sure you recalibrate your RC after.
So then my config is already correct?
Ok well then I am totally confused. I am not using any strange mapping, the correct channels are going into the default inputs and yet I am getting a gyro drift of some sort anyway while sitting on the ground yet in the air it is all fine... This is not making any sense at all.
I have found that if you calibrate the radio with the default channel order and the do the remap everything works normally. The bug has to do with the RC MIN/MAX/MID not following the remap. So you could just move those values you have back to where the default mapping is.
See your RC1_MID is 980 something so it thinks you want to roll Right.
This is being fixed in 3.3 to come out soon.
How do I do a remap? Or a map for that matter? I have always just done a radio calibration...
-
7
-
8
-
9
-
10
-
11
of 59 Next