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
I posted this on the other related thread, but haven't heard back:
http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A1903...
I've done tests with 3.2.1 and 3.3 and find that the rc channels continue to register values above 1000 when I turn the radio off while the copter is running at half throttle. Has anybody else seen this issue? I am using the Spektrum AR8000 receiver connected to a satellite receiver and controlled by a DX7 transmitter if that matters. Here's a screen shot of the RC3 history when I have the radio turned off right after I increased the throttle at line 30x10^3. I turned the radio back on at about 53x10^3 and lowered the throttle to minimum.
rc-values-with-rc-turned-off.png
I tried this test out with 3.2.1 on my APM with a Spektrum AR5200 receiver and DX7 Transmitter. It responded correctly by setting rc3 to 900 when the R/C transmitter was turned off.
Has anybody with a Pixhawk seen the behavior described above where rc3 does not get set to 900 when the R/C is turned off? What mechanism is used to detect the state of the R/C transmitter?
Isn't this down to failsafe behaviour on the RX? I have Spk satellite, orange rx and lemon rx and they all have different failsafe behaviour when you lose the TX. I fixed the problem you describe on my orange by setting the failsafe values with the throttle set below zero (you can do this by playing around with the bias on the TX, there is a thread somewhere about this but don't have it to hand). Lemon and Satellite kill the entire signal, which I prefer.
Andy,
Thanks so much, that was the problem. I've never had to muck with this setting and didn't even know it existed. I guess I need to read the entire Spektrum manual to see what else I'm missing!
http://diydrones.com/profiles/blogs/spektrum-dx8-and-ar8000-failsaf...
http://johnleach.co.uk/words/1627/avoid-quadcopter-crashes-with-thr...
http://www.spektrumrc.com/prodinfo/files/dx7_manual.pdf (page 89) I had to increase the pitch to 150% since my pitch and throttle channels are swapped.
BTW, you don't know how to swap the Pitch and Throttle channels on the Spektrum as well? I ended buying the PPM encoder and swapping the wires around to get the correct mapping to avoid the R/C channel mapping bugs, but its still an itch Id like to scratch more.
On my DX8, you can't. I understand on newer DX7's you can, but not older ones. The best way to do this ought to be using channel remapping in the APM firmware, but there is a bug with that as can be seen by the various ongoing discussions around it :)
Also I have another question;i can see in mission planer full para. list there is address for 3 compass...does this mean we can connect compass from second GPS as well?if not,when it will be possible?
I can't wait for that to be possible!! I think one major issue with flight problems is the bloody compass. It doesn't like being by electronics. What part of our machines don't have electronics! If we could have two EXTERNAL compasses that would go a long way to preventing issues. However if I recall correctly Randy said at this point the I2c port can only address one compass or something to that effect :[
Re-Test PM fail loop lines... I get that too. I think everybody does...
Hello...
Can someone please tell me what is
Test: PM = FAIL - 16 slow loop lines found, max 11.85% on line 6761 from auto analyzer
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (19.70%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = GOOD - (Mismatch: 0.33, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = FAIL - 16 slow loop lines found, max 11.85% on line 6761
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = GOOD -
We seem to be having camera trigger problems with 3.2.1 on an APM2.6 hex.
This hex has been been working fine and no problems triggering the camera from DO_DIGICAM or CAM_TRIG_DIST with previous versions of FW.
We installed 3.2.1 today and the latest Mission Planner to do camera tests and are finding strange results in that the the camera was triggering only when the copter stopped at the end of a run (multiple runs in a grid scan).
This happened with either CAM_TRIG_DIST set in parameters or DO_DIGICAM in the waypoints until I put a 1second delay at each waypoint. It then fired the camera each time. Varying the speed had no effect. We used from 3m/s to 6m/s.
I noticed that with CAM_TRIG_DIST it would trigger when I started to walk with the copter but failed on the subsequent triggers until I stopped walking. This gave me the idea to put in the delay, but the delay in flight makes the mission too long and slow.
Has anyone experienced this or has anyone any clues as to what to look for as a solution other than downgrading the FW.
Have attached a couple of the logs, the later one is with the delay.
2015-03-24 14-32-42.zip
2015-03-24 15-24-49.zip
Hi Mike,
In scripting an auto mission with waypoints, you have the case where the WP has a delay set at zero (which you did). that is then a so-called fast waypoint that is infact never really reached by the vehicule, because in that case of fast waypoints, the auto mission logic projects an intermediate position ahead; if this intermediate position reaches (virutally) the next waypoint, the auto mission will go to the next waypoint (and therefore your do command is not executed at the skipped waypoint).
this is why it works when you set a one second delay : this forces the auto mission to go by this waypoint (and thus executing the associated Do command).
This is not a bug but the way it works. It is not so logical and very annoying as I have tasted this myself, thinking I had a GPS/position issue on my craft. We should propose developers to modify this behaviour in a next release.
-
8
-
9
-
10
-
11
-
12
of 59 Next