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: 57439

Reply to This

Replies to This Discussion

Hi Randy and Craig,

Just to update you with the LOG_BITMASK set to 32768 or MASK_LOG_CAMERA.

The log result from a mission with above setting (32768) was successfully record the CAM log but missing the very important data to Geo reference image captured by the mission, which is GPS data that cannot be found by the MP > Geo Ref Images tool. 

Only UBX1 and UBX2 data found and assume this is uBlox GPS data.

Assuming GPS data should look like this to enable Geo Ref Images tool to work:

Can I use this UBX1 data to geo reference an image?

if yes, then how?

Many thanks.

Waladi

NOTE: Double Post to be viewed on the latest comment page.

Hi Randy and Craig,

Just to update you with the LOG_BITMASK set to 32768 or MASK_LOG_CAMERA.

The log result from a mission with above setting (32768) was successfully record the CAM log but missing the very important data to Geo reference image captured by the mission, which is GPS data that cannot be found by the MP > Geo Ref Images tool. 

Only UBX1 and UBX2 data found and assume this is uBlox GPS data.

Assuming GPS data should look like this to enable Geo Ref Images tool to work:

Can I use this UBX1 data to geo reference an image?

if yes, then how?

Many thanks.

Waladi

Hi Randy I am using a CSGshop M8N as my primary and the Rctimer NEO M8N as my secondary GPS with the external compass connected....I have been flying auto missions lately with these units and the copter holds position and navigates flawlessly ...the GPS sats are no longer a problem as I always get close to 19-21 sats ...but I am suffering from the same INAVerr problem....I just read Waladi's reply above and wanted to share my experience..I keep getting bad GPS health messages on my HUD even though the the HDOP is 1.1 and the No. of sats is 20...also sometimes the occasional bad AHRS and bad velocity messages....I am flying 3.2.1 stable and have no had any problems with the copter when it is flying but I just wanted to know that even after you and the dev community raised the threshold for error reporting on the sensors to reduce false positives...are these messages serious ?? I am attaching my log file here for you to analyze

I am also attaching a tlog from an automission I did the same day so that you can see the copter flies well even with these messages popping up on the HUD..I am flying with EKF enabled

Attachments:

Hi everyone, I need support to understand a problem that my new model with pixhawk and AC 3.2.1.
The model to counter function properly without propellers.

When I try to fly if I make slow movements is all okey, but if I accelerate abruptly quad flips like a desync ESC.

If someone has the patience to watch my log

Thank You

https://drive.google.com/file/d/0B6QJRmFQmku9RW5TM1d5UllqbTQ/view?u...

If you are going to use the M8N then you will need to make additional provision to shield the GPS from the rest of the electronics on the vehicle.  The M8N uses a very wide front end in order to receive both GPS and GLONASS signals.  That makes it much more susceptible to noise than either the Ublox 6 or 7 series.

The noise results in degraded performance in the velocity measurements and in turn degrades the inertial navigation performance regardless of HDOP or number of satellites. i.e. you are tracking 20 satellites but there is sufficient noise on each of them that the velocity measurements are worse than tracking fewer satellites with less noise.

Ublox has recommended to me to not use the M8N on a vehicle unless it can be shielded and located far away from all noise sources. They did not want give me a specific number, but the order of magnitude was >1m.

Your results are consistent with their predicted behavior and indicate that interference with the GPS is an issue with your vehicle.

The UBX1,2,3 messages all provide information about the condition of the GPS receiver and the noise of the GPS signal.  Please refer to the ublox message specification regarding how to interpret them.

The use of a ground plane has been very effective in reducing equipment noise on other GPS configurations.

does this noise show up in the ekf vel NE noise readings? I am using a virtual robotix Ublox NEO  8 gps and I am not seeing any ill effects. It is about 30cm from the electronics on a tail boom rather than mast (dedicated to the gps/compass...not a motor boom). my top and bottom plates are copper clad grp and the boom is carbon, which could have some shielding benefit. 

wondering if its worth people comparing their vel NE noise figures assuming they are using ekf.

I suggest you use the Jamming indicator, the noiseperms and the gain numbers that are listed in the UBX 1, 2, and 3 messages.  That is why we put them in the log :)

ah ok, I have 1 and 2 in my logs. interesting jamind is quite different for different flights at different places and times. guess that  makes sense for how noisy an environment is. will keep an eye on it so see if its higher when i have poorer loiter performance over the next few fights. like I said I am not struggling....just wondering if its worth people who do and donlt have the inav issue comparing.

edit...sorry my jamind isnt that different....i has one log set the other way around to which y axis was used.

My jamind is about 6 and noiseperms about 100

You have to run master to have the uBX3 message in the log.  It has the AGC value.  We found out that evaluating the noise can be deceptive without it.  For example the noiseperms value can decrease as you move a noise source closer to the GPS antenna because the AGC on the receiver actually decreases at the same time.

I don't understand, what is ma?

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service