Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.

Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.

Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).

Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station.  Video description is here.  The bug is fixed in Copter-3.3.1 so we recommend upgrading.

Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting.  HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features

Copter-3.3.1 is available through the mission planner.  The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.

Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.

Changes from 3.3:

1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff

2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)

Changes from 3.3-rc11:

1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent

Changes from 3.3-rc10:

1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF

Changes from 3.3-rc9
1) EKF improvements:
    a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
    a) fix INS3_USE parameter eeprom location
    b) fix SToRM32 serial protocol driver to work with recent versions
    c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
    d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
    a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
    b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
    c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
    d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
    e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)

Thanks for your testing!

Views: 374420

Reply to This

Replies to This Discussion

Pix4d says the kappa angle is 90 degrees off and that's causing the orientating problem with their software geotagging.  CAM, 595372339, 339994200, 1854, 49.8042384, -119.4715983, 578.83, 69.99, 2.10, -9.35, 266.46.  In my quality reports I get and RMS error on kappa at 89 degrees.  Sure it won't be too difficult to fix : )

Жека то что он говорит это то что китайский pixhack имеет поблеммы с вибрацией... Проверь что силикон внутри не болтается.  Есть два пиксхака. Один в алюминиевом корпусе делает CUAV, другой в пластиковом .., последний полное Г.  Первый вроде ничего, если силикон правильно установлен. +  и там силикон не панацея, т.к. низкочастотные вибрации проходят через него спокойно. 

By my undestanding: if your GPS HDOP value drops below the HDOP_GOOD value, you are fine flying any GPS assisted flight modes, and Geofence is acting on a breach as well.

Bringing this value lower, like 0.90 makes it harder to reach for those GPS units which are not capable of locking 12-14 satellites, like the NEO-M8N which I do use.

With the new code RC8 the valid question is should you move the default of 230 to something lower, like ultrafuge is suggesting, to maintain the same security level as before with the 230 ?

I originally brought it down to 140, as well but then it took quite some time to reach the usual OK to fly which I interpret by getting a green light on the PixHawk, so I did bring it back to 230, but that might actually be too high in this new scenario.

@Andrea Zamuner Cervi,

By any chance did you perform a compass calibration?  I know it's not in the notes above, but there has been significant software changes since 3.2.1 and it may clear up upon a recal.

you misunderstood.

you may set your HDOP_GOOD to 140 or 150.

After you did that - Geofence still will not let you to arm your vehicle claiming 'need 3D fix' until factual HDOP value falls to way, way lower number.

Try it. Set geofence up and try to arm it up while monitoring what a current value of HDOP is. it will show '3' for gps mode, will show lower hdop than your hdop_good but will not arm.

so my guess was - there is something more to it than just hdop that geofence is looking at.  

Yes, of course I have done it.
But thank you for suggestion ;)
A suggestion like this is always welecome since most errors are made by simpy forgetting something.

I have found that with AC3.3 rc8 it does arm.

The main problem is that when I'm on the ground if I touch/move too much my esacopter it display "compass variance".
If I plug in the LiPo and carefully go away from the copter without touch anything I can arm it without any error.

Basically: now it is very very sensible if you rotate/move the copter after the power up, before arming (Or at least, I think. Soon I do some other test to confirm this).

I have already posted a similar somewere in this thread. We only have to find it =P

I don't see that...., As soon as the GPS HDOP goes below the value I can arm, and fly..., verified by looking at Missionplanner, while it's slowly getting more Sats (indoors)..

It also looks like it is acting on the geofence breach for sure as I did try that on RC7..(outside ;-) )

It obviously helps that when you take off, it usually starts acquiring more Sats end that might help GeoFence as well.

So you are saying that when you are flying as soon as it hits the 230 value, your fence might not work ?

That would be very bad, as it gives you a false sense of protection against fly-aways.

I have my fence up all the time, and fully trust the protection... ;-(

ok, I see it on both my vehicles so it may not be just a glitch.

What I say - I set HDOP_GOOD to a certain value, like, let it be 201.

if GeoFence is not set active everything is OK - you are able to arm in loiter mode as soon as HDOP value reaches 200 or lower.

If I activate GeoFence, then it reaches 199 and upon arming request it still responds 'need 3D fix' and continues to respond like that for awhile. Like, until actual HDOP value I look at drops to below 100 and GPS locks into 12-13 sats.

It does not do same for you? on rc8 or rc7? try it in front of your house where gps signal may not be as ideal as in the open field.

at 200 value I have usually 8-9 sats locked into. If it is just me on rc8 who got this I am quite surprised, I will try to look at it again, but so far it is quite consistent.

Only good thing is - my big M8N unit after initial delay at first arming hooks very fast into 12-15 sats for the rest of the day, so, it is not a big issue.

I indeed do fly at a field, so don't have multi path problems which may be the reason that it's not getting a full 3D lock.

And I most of the time take off in Stabilize and then switch to AltH or Loiter while in the air, but I never take off without the green signal, can't even arm in that case...

But I will give it a shot, just to see what it will do, when I do have a green indicator, switch to loiter and try to arm..

If it will prevent me the arming in the field, it means that the green, or minimum HDOP is not enough...

Now I think about it, it may have seen this in the Auto mode...
Recently I tried to arm, in Auto mode, and lift the throttle, and then, while a had a green indicator, it just beeped at me...

So had to switch to Stabilize, took off and at 1 meter switched to Auto, which took care of the rest of the waypoint traject, but that could have a small change from within the code as well...

So I didn't think it was strange..., I may have been in the same area, that the HDOP wasn't low enough for a proper 3D lock.., which is kind of essential for flying Auto modes...

if you activate geofence it will not matter in what mode to try to arm - it will not arm until geofence is happy with GPS signal quality.

rom one perspective it is annoying, from other perspective, for FPV long flights I prefer to arm when I know whatever logic is in there - it is happy with how GPS signal looks like, so it is a catch22.

I think may be it would be nice to get a confirmation from EKF developers if 3D lock is now an essential requirement for any GPS and non-GPS flight mode, for EKF to function properly as I am not sure I understand all implications there.

I upgrade to RC8,have  few questions,

why "Throttle Accel" & "Throttle Rate" these two items can't make change??

last night I down my Mini Hexacopter with "Autotune",take about 11 mins,when I land battery voltage only left 3.4V...

why take so long to do this autotune? here is my autotune result

Thanks for testing.

The MP still needs to be updated a bit more to match the parameter name changes for AC3.3.  I'll remind Michael so hopefully he'll get to it soon.

The AutoTune takes more time because it does Yaw now as well.  The AutoTune wiki page has new instructions to allow tuning a reduced set.  For the next release (AC3.4) we will likely add a better autotune interface to the ground stations to make this easier.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service