Developer

ArduCopter-3.2 beta testing

Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels.  Pre-arm checks have been added to ensure this has been done.

Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.

AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link.  The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.

     Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.

     It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features.  Marco and I will be maintaining (and adding to) this testing list.  Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).

     Thanks especially to the beta testers who put their copters at risk testing each release.  Enjoy!

Changes from 3.2-rc13
1) Safety Features:
     a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
    a) DCM-check to require one continuous second of bad heading before triggering LAND
    b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
    c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
    d) use primary GPS for LED status (instead of always using first GPS)

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

Join diydrones

Email me when people reply –

Replies

    • Sorry forgot to attach the logs.

      3.BIN

      • Developer

        Murdanny,

        Can I ask what was the issue?  In this log it appears the vehicle was in AltHold most of the time.

        I see there were a number of EKF_CHECK warnings (warnings because the vehicle was in AltHold instead of a mode that required the horizontal position control).  I'm unsure of the cause but I see very large discrepancies between DCM and EKF which is not a good sign.  Also the ARMING_CHECK seems to have been disabled, which checks were causing it to refuse to arm?

        One thing that I notice in the logs is the Rate Roll/Pitch P values are very high at 0.356.  This may be leading to strange little twitches in the desired roll and pitch.

        3702672054?profile=originalBy the way, the LOG_BITMASK parameter seems to be set to an unusual number.  It's missing some important messages like CTUN, RCIN, RCOU which are quite helpful when debugging.

        • Hi Randy,

          I am unsure myself why there are large discrepancies between DCM and EKF. Maybe perhaps I was taking off from a rocking boat. Was that the case?

          For the EKF_CHECK warnings, I flew before with only using Alt Hold but never encounter these warnings before. I have attached a log which i flew in Alt Hold throughout the flight out at sea without these messages, if it is any help. I took away the whole pre-arm check because gyro calibration was unsuccessful, like i mentioned to you before.

          I am flying a Tarot T15 Octocopter. On land while I was tuning the octa, there were no visible oscillations. Or was the graph saying otherwise?

          I will take a look at the LOG_BITMASK parameter and get back to you about this.

          Thanks so much.

          23.BIN

          • Developer

            Murdanny,

            Paul Riseborough had a look at the logs and he says that it was a combination of large gyro biases (probably caused by calibrating on a moving vehicle) which led to the EKF not believing that the compass was accurate.  It then stopped using the compass completely and this led to a really bad heading estimate which caused the EKF check warnings.

            We're wondering if perhaps the copter was being armed while on an steel deck of the boat?  The EKF is a little different from DCM in that it records the inclination at startup and at arming.  This means it can have problems if it's armed very near to large metal objects.

            • Randy,

              Please thank Paul for me for taking a look at the logs.

              Yes, I believe the boat was rocking too much and moving when we plugged in and arming it. The copter was indeed on a steel deck.

              I think it is a case of the boat moving and rocking. Log 23 was on a bigger piece of steel. I have been flying in industrial areas/construction sites but have never encountered this.

          • Developer

            Murdanny,

            So in the "23.bin" log the DCM and EKF stick together very well.

            If the gyro calibration failure messages was appearing before the 3.bin flight then I strongly suspect that the boat was moving too much for it to calculate the gyro bias.  This would make perfect sense.  Instead of turning off all arming-checks, I'd recommend selecting "Skip INS".  Better yet, leave them all on and just try and calibrate when the boat is more stable.  Hopefully we will support boat takeoffs in AC3.3.

            I'll also ask PaulR (EKF expert) to peek at your log.

  • i just update to RC12 from arducopter 3.1.5, but then on my mission planner, I cannot find the POSITION Hold mode, I reverted to 3.1.5 but still that flight mode is missing...I update again to arducopter 3.2rc 12 and still I cannot find the position hold/hybrid mode... can this be fixed? I fear that the sudden shift on the flight mode numbering could affect the succeeding flight modes.. and I often use hybrid or poshold.. hope you can help me with this. thanks!

    • Yes it seems that the issue is with the mission planner. I tried another laptop with misison planner and the PosHold mode is back.. thanks again!

    • Upgrade to the beta of Mission Planner and you'll find it. Had the same problem myself. 

      APM Planner 2 also supports it as a flight mode.

    • Developer

      Erwin,

      It's less likely to be an arducopter firmware issue and more likely to be a mission planner issue.  In particular your particular installation of mission planner does not have the latest parameters.  Could you try Help >> Check For updates.

This reply was deleted.

Activity

DIY Robocars via Twitter
Friday
DIY Robocars via Twitter
Friday
DIY Drones via Twitter
Thursday
DIY Robocars via Twitter
RT @Heavy02011: @diyrobocars : A Home-brew computer club* for Connected Autonomous Driving on Jan 23rd, 2021 https://www.meetup.com/Connected-Autonomous-Driving/events/275728684/ #Meetu…
Thursday
DIY Robocars via Twitter
Thursday
David Hori liked Isabella Domi's profile
Wednesday
DIY Robocars via Twitter
RT @Heavy02011: ⁦@diyrobocars⁩ Autonomous Driving Assembly at #rC3. join us at https://rc3.world/rc3/assembly/diyrobocars-f1tenth/ ⁦@f1tenth⁩ ⁦@DAVGtech⁩ ⁦@DWalmroth⁩…
Jan 11
DIY Robocars via Twitter
RT @chr1sa: New car designs coming for our next @DIYRobocars @donkey_car virtual race on the 23rd. Choose any one you want at race time Le…
Jan 11
DIY Robocars via Twitter
RT @RoboticMasters: Thanks to @EllerbachMaxime and the Sydney Uni Capstone Students the @donkey_car @diyrobocars simulator is getting a ma…
Jan 11
DIY Robocars via Twitter
Jan 6
DIY Robocars via Twitter
Dec 28, 2020
DIY Robocars via Twitter
An interesting line-following simulator to use with with your robocars: https://github.com/ron-grant/LFS
Dec 23, 2020
DIY Robocars via Twitter
Dec 23, 2020
DIY Robocars via Twitter
An improved version of the @IntelAIResearch OpenBot: https://diyrobocars.com/2020/12/14/an-improved-version-of-the-intel-openbot/
Dec 14, 2020
DIY Drones via Twitter
An improved version of the Intel OpenBot https://ift.tt/2KkHT8Q
Dec 14, 2020
DIY Robocars via Twitter
Dec 10, 2020
More…