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

    • Presuming the first step in the auto route was set to "takeoff" you activate the route by arming, setting the mode to auto and then raise the throttle above 50%

      Best of luck
      • yes i've done the mission with droidplanner, then i send it to drone. Followed by arming and raised the throttle. i'm not sure if it was 50% or a little bit lower (but should be enough) and  switched to auto.

  • I’ve come across a problem with the way that the desired yaw angle (DesYaw) is handled in gusty wind conditions after issuing a Condition-Yaw command with WP_YAW_BEHAVIOR SET TO “0”. Anytime the flight controller cannot maintain the yaw heading to within 10 degrees of the DesYaw value for more than a second or two it changes the DesYaw value to exactly 10 degrees from the actual yaw heading. It seems to be doing it at the same rate that the ATT log entries are being written to the flash log (about 50 times/second).

    My use case is an aerial panorama where I position the hex manually then invoke a mission that points the camera North (0 degrees), takes 5 photos at different gimbal pitch elevations, points the camera 32 degrees clockwise, takes another 5 photos, and continues this process every 32 degrees until 10 columns are completed. It then does an RTL.

    In one recent panorama shoot I was at high altitude in the mountains with gusty winds when the yaw angles did not come out right. I’ve attached a log. At time 444780Ms the DesYaw angle starts to change from the Condition Yaw command value. It’s real apparent starting at 461916Ms, between 509316 and 515564Ms, and between 543924 and 545603Ms. There was no pilot yaw input and the RC values were well within the deadband. I’ve attached a spreadsheet where I calculated the difference between the Yaw and DesYaw angles to illustrate that the DesYaw angles is getting changed anytime the difference is 10 degrees for more than a second or two. These changes are highlited in color on the spreadsheet. This excludes the initial yaw heading change time (about 4 to 5 seconds) where the hex rotates to the new heading, overshoots a bit, then rapidly seeks out the correct yaw heading.

    I’ve looked through the code on Github to see where this might be happening but I was unable to find the correct module. It seems unlikely that this is happening by chance, it there some reason that the flight controller is giving up on maintaining the DesYaw heading when it gets past 10 degrees from the actual yaw? Is this configurable? I see a PARM called RATE_YAW_IMAX that has a default of 1000 Centidegrees (10 Degrees) ,  is this the configuration PARM that is causing the problem?

    • Developer

      Phil,

          You're right that the desired yaw is dragged around with the actual yaw if it goes off by more than 10degrees.  This was added to try and make the platform safer by reducing the chance of sudden yaw movements happening when the environment changes.  those "environmental changes" could be any thing from a take-off to the vehicle hitting tree.

           We could probably make an exception to always correct the yaw back to the initial target in Auto.  I've created a to-do item here.  I don't think we will be able to correct this for AC3.2 though probably...

      • @Randy

        Thank you. When the yaw gets dragged around while doing a panorama it creates gaps in the columns of pictures which can't be discovered until one tries to stitch them together back home.

        I agree that this should be an enhancement for after 3.2 is released. At this point the 3.2 codeline should be closed to everything except fixes for critical bugs and fixes for major bugs that don't have a workaround.  

    • The log file was too big, here's the spreadsheet. I'll find another place it upload the log file if needed.

      Log 58 ATT Extract.xls

      https://storage.ning.com/topology/rest/1.0/file/get/3702523364?profile=original
  • Hi,

    I'm running rc10 on my APM 2.5.

    I switched my RX (FrSky) to use CPPM mode yesterday. Now i'm trying to configure my flight mode. I was using 6 flight by mixing my 3-pos switch and gear switch (turnigy 9x remote).

    Now my 3-pos switch respond on Channel 6...and APM "wait" for Flight mode on Channel 5.

    One of my friend, that run version 3.2 rc2, told me that he recompiled its version after changed int16_t pulsewidth = g.rc_5.radio_in; for int16_t pulsewidth = g.rc_6.radio_in; in control_modes.pde file.

    In the solution of 3.2 rc 10 i'm not able to see the file control_modes.pde...and I searched through the other files I didn't find the line "int16_t pulsewidth = g.rc_5.radio_in;".

    Can someone can point me where this line is now located ? Or point me of what I need to change to be able to correctly use my CPPM rx with arducopter 3.2 rc 10 ?

    thanks in advance

    • I swear there used to be a parameter that let you change was ch. your flight mode input was on. I just spent 10 minutes looking for it and couldn't. I am wondering if I reload 3.1.5 if its still there... Was this option removed? 

      - Nevermind that param. is on APM Plane... I wonder if it can be added to copter.

      • Well, I found the parameter ...

        in switches.pde file.

        just change int16_t pulsewidth = g.rc_5.radio_in; for int16_t pulsewidth = g.rc_6.radio_in;

      • I wish plane had the ch 7 & 8 options like copter. Not sure why they aren't the same. 

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @knightsautoteam: Hi @diyrobocars, we are Orlando's first Autonomous racing club and would love your support. We are hosting our first K…
Friday
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #14 - #ParkingLotNerds join us January 15th for #AutonomousRacing #RoboRace ⁦@DAVGtec…
Jan 16
DIY Robocars via Twitter
RT @chr1sa: And after that came our races, 50 in all. This battle between these two Russians was the best we've ever seen -- incredible fig…
Jan 16
DIY Robocars via Twitter
RT @chr1sa: Before our @DIYRobocars virtual race this weekend, we had a presentation from the team that won the Indy Autonomous Challenge i…
Jan 16
DIY Drones via Twitter
Dec 12, 2021
DIY Robocars via Twitter
Dec 12, 2021
DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
Dec 4, 2021
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
Nov 28, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25, 2021
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23, 2021
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Nov 23, 2021
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23, 2021
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20, 2021
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20, 2021
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9, 2021
More…