Developer

Copter-3.3 beta testing

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!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

          • What's the diameter of that round one ?

            • About 10 centimetres (3.937007874015748031496062992126 inches) :-)

        • Developer

          Yestarday, HDOP 0.7 (VR M8N)...3702795917?profile=original

          • I also have the CSG large M8N.  Bought it t because of the very slow startup of the Lea-6..

            Mine drifts several feet in every direction when hovering at five to ten feet in PosHold.  I run it with the Lea-6 on a PH.

            I had a crash described on the previous page that may be related to concerns expressed in the last several posts.  Just before landing it took off sideways at a shallow angle and hit hard on the end of one arm.  That motor smoked momentarily sitting on the ground and is fried.

            I now wonder if the crash was the result of switching between the two GPS unit with a rapid position adjustment rather than a motor failure?  I am unable to sort this out looking at the logs?

            I had not experienced anything similar with 3.2.

            Log attached.

            2015-08-13 19-06-30.bin

            • Hi Greg,

               

              Really sorry about the crash....

              I 'm not very good with logs... only the "basics", but I can’t see anything related with GPS, again ....I’m not a specialist.

               

              By the way... I really recommend for everybody... a good anti-vibration system,  I’m using the regular one with small blue shock absorbers , and gel pads to fix the board …. After this implementation “I feel” a hundred times better…..

               

              I’m using this “double cushion” in my olds APMs, Pixhawks and Navio+ boards…..with very good results.

              • Thanks for the reply Robert.  I do could not see any GPS issues either but I am not always sure that I am not overlooking something.

  • I had a GPS glitch today on rc8, but the EKF GPS glitch filter didn't catch it.  I was hovering in the back yard with an M8N with 15 sats, and a fix type of 4, and descended to just below roof height while in Poshold, when the gps dipped to 12 sats, and the copter made a fast correction towards the house before I switched quickly to stab. Fix type changed to 3 soon after this and stayed that way till landing. 

    I've read the description on http://copter.ardupilot.com/wiki/gps-and-gcs-failsafes/gps-failsafe/ but still can't quite visualise how it would accept the glitched GPS position as valid, while not really having any lateral movement to project a trajectory. The new position it was trying to get to must have been a few metres away.

    Is there a strategy for tuning the EKF glitch parameters to make it more resilient to glitches like this? I'd like to make sure these things don't make any unexpected movements when coming into land.

    Here's a log.

    • I'm also using an m8n, and have similar results..  Even with very low hdop, 10-20 satellites, the copter drifts around about 10 meters.  I can take a screenshot of mission planner if anyone is interested.  Copter sitting stationary on the ground, and mission planner thinks I'm constantly moving ~.5 meters per second, all over my yard.
      I have not used this GPS with anything before 3.3, so don't know if it's the cause. 
      I had a different copter that I sold a few moths ago, with the lea-6 gps and older arducopter firmware, and it moved around a couple of meters, only about .1 meter per second (again, sitting stationary and just looking at mission planner).  So, the m8n, while getting many more satellites and lower HDOP, drifts around a lot more. 
      There seems to be nothing telling it, if its location suddenly jumps over 5 or 10 meters that it must be an error..   The copter tries to go to the new GPS coordinates. 

      I found threads from a few months ago saying the m8n isn't actually supported yet, so we're all on our own trying it.  Arducopter progresses quickly, though, so I'm not sure if it's supposed to be working now....  

      Should we have good stable results w/ the m8n, or is it still experimental?

      • I had used M8N for some time.
        I had used it on 4 different copter. With APM and AC3.2.1 and with PixHawk and AC 3.3 (rc5,6,7,8).

        I never had any problem of drifting.
        But I had read that someone have experiences like yours.

        I think that a lot can be done by the quality of the GPS.
        I have tested personally four different M8N, and I can say that not every build of the GPS is the same.

        Where did you buy your M8N?
        I had seen that on the market also exist very poor quality M8N. I think that VirtualRobotics M8N and HobbyKing M8N are good. Or at least, in my tests they both performed very good.

        But, I admit that I do not have any solution.
        I also do not exclude that maybe there is some software error.
        So, I really do not know the solutions to your problem, but I felt like to shate my toughts about this.

        I also think the following. Maybe it can help:
        Maybe if you post the log of your copter with AC3.3 with M8N while is drifting it could be more simple to undestand the cause of your drifting.
        So, if you have the log, you can post it maybe.

        • My one is from drotek, so it's not the cheapest and nastiest, and it's been manually configured for 5hz, airborne 4g. I can just see this as causing serious issues when coming in to land, as often there are trees blocking the view on one side of the copter, and I can't afford it to take a dive into them or something else if the lock degrades slightly as it comes past them. Surely there's a way to tighten the EKF glitch filter to deal with these cases better?

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @breadcentric: The handy bit about racing with self-driving cars is that one can type while the car is racing. Report from #AWSDeepRacer…
yesterday
DIY Robocars via Twitter
RT @chr1sa: Our Bay Area @DIYRobocars meetup is now at 2,700 members. Next in-person events (in Oakland) are training day on July 17 and…
yesterday
DIY Robocars via Twitter
Videos from the ICRA autonomous racing workshop are now available: https://linklab-uva.github.io/icra-autonomous-racing/
Jun 10
DIY Robocars via Twitter
RT @SmallpixelCar: Prepared race track for Warm Spring Raceways @wsraceways and looking forward to test my new car at RAMS RC @ramsaicar fa…
Jun 6
DIY Robocars via Twitter
RT @f1tenth: Trying out some nasty blocking maneuvers 🏎️🤖 #f1tenth #autonomousracing https://t.co/nMTstsaogM
Jun 5
DIY Robocars via Twitter
May 27
DIY Robocars via Twitter
RT @araffin2: I will talk this Saturday from 18:00 to 19:00 Paris time for the @diyrobocars community about learning to race in hours using…
May 27
DIY Robocars via Twitter
RT @a1k0n: Luckily the infeasible hairpin problem was easily reproducible in simulation and I could test the fix before bringing the car ba…
May 26
DIY Robocars via Twitter
RT @a1k0n: Another problem was that I was over-constraining the car's allowed accelerations, so it didn't think it could turn as tight as i…
May 26
DIY Robocars via Twitter
RT @a1k0n: Breaking the map up into two halves worked, but I had to be more careful about separating the inner track from outer. There's se…
May 26
DIY Robocars via Twitter
RT @a1k0n: Here's a datalog for my fastest lap of the day. Lap timer is tiny window lower-left. https://t.co/myrlWWrKUY
May 26
DIY Robocars via Twitter
May 26
DIY Robocars via Twitter
RT @a1k0n: Here was my car's POV. Man this track is confusing in first-person! After the incident my camera was all scuffed up and I was af…
May 23
DIY Robocars via Twitter
RT @circuitlaunch: Loved seeing so many familiar (masked) faces at Circuit Launch today for our first in person @diyrobocars in over a year…
May 22
DIY Robocars via Twitter
RT @circuitlaunch: Last but not least, mystery guest @BostonDynamics Spot took to the track @diyrobocars He enjoyed the #brazilianbbq too 😂…
May 22
DIY Robocars via Twitter
RT @SmallpixelCar: Today’s race @circuitlaunch for @diyrobocars with @a1k0n Was busy in the morning and did not get a chance to tune camera…
May 22
More…