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

        • shouldn't it tolerate a motor failure without catastrophic loss of attitude control? That is the whole point of running a Hex or greater set-up isn't it? Redundancy...

          • If you want redundancy, you might have to go to the octos.. I have seen FW that will keep quads and hexes airborne with rapid pirouettes and slow descent in event of a single motor failure..

            • Developer

              It looks like a mechanical failure and it starts to go bad about 5.5seconds before it completely loses control.  I can't be 100% sure because so much has changed with AC3.2 vs AC3.1 that nearly anything is possible but it looks like a mechanical issue.

              3702867798?profile=originalA Y6 also will stay airborne with a motor loss.  It should be possible for a hexacopter to maintain altitude if it's smart enough to give up yaw control.  It should be possible but it needs someone to look into it in detail.  It maybe as simple as getting the balance of roll-pitch I terms vs yaw-Iterms correct but more likely it's a change in the attitude controller to make sure we prioritise roll-pitch over yaw.

    • Looks a lot like my crashes on RTL earlier - any idea how to unpack the bin log to a dataflash type of log so I can have a look?

      http://diydrones.com/forum/topics/loiter-and-rtl-crashing-bug

      It may not be the same, but it doesn't hurt checking - mine also occurred in auto mode.

      Mihai

  • Hi Randy,

    Where could I officially request features for 3.2 or any other firmware version? There are two that I think would be easy to put in (that being said, I'm not a programmer) which I would like to suggest for 3.2 or another FW revision and they are:

    1) Fixed Orientation Auto Flights: At this point in time, the WP_YAW_EFFECT does not allow for you to specify a specific heading for the copter to maintain during the course of the entire waypoint mission that the copter will automatically assume. We have to set WP_YAW_EFFECT to do nothing and then manually adjust the yaw on the ground or on the way to the first waypoint in flight. It would be nice to have the ability to specify copter orientation for the auto flight and have it automatically go to it when the WP program is activated.

    2) AUTO MISSION: When a waypoint program is designed that is larger than what the platform can handle, it would be great to have the ability for either a) Mission Planner to automatically "slice" the mission into individual flights based on flight time and/or distance, b) APM/Pixhawk to store the whole mission and as it finishes flight lines/waypoints, delete them from memory so that after battery swap, the platform continues to fly from where it left off without the need to re-design/program/upload missions. After all, a "Mission" can be composed of many flights but up until now, the flights/flight lines have to be separated from their neighbors if the mission is too long.

    Please let me know if there is a better place to post these ideas where they may be implemented!

    Great work so far on all the firmware updates! I love my APMs and Pixhawks! :)

    • Developer

      Olivier,

          Feel free to add enhancement requests to the issues list.

          For #1 you should be able to set the WP_YAW_BEHAVIOR to 0 and then use a condition-yaw command to point the vehicle in the direction you want.

          For #2, we don't have exactly what you're looking for but with the introduction of the AP_Mission library copter has far better control of the active waypoint.  I've created a mission planner enhancement request to take advantage of that ability.  This could include setting the active waypoint before you enter auto mode.  So if you'd already done half the mission on a previous flight you could just remember where you left off and then start from the next one.  Personally I'm a little reluctant to try and carry over the memory of the mission status between reboots because I'm worried it will lead to support requests like, "why did my mission start half way through on my 2nd flight?".

      • Hi Randy,

        Thank you for that information! That's great to hear. I normally would adjust the orientation of the copter as it flies to WP1 so your solution for #1 above is going to save me a lot of trouble! :)

        I understand that for number 2 you may be concerned about the support requests. Is it possible to have this feature as an "option" (ie, selectable in Full Parameters or somewhere)? With an appropriate description, that should eliminate the support concerns.

        Is your AP_Mission Library "ACTIVE WAYPOINT" feature already available? I'm assuming it would work such that prior to take-off, the operator would specify which is the 1st waypoint of the flight in the mission (I assume that this is going to be called the "active waypoint") and the copter will then fly to that waypoint and continue the mission? If possible, it would be great to also add a "active final waypoint" so that the operator can control how long the flights within the mission are in place of having to bite fingernails until the voltage shows that it's time to come home and have to abandon the flight, not knowing what the last WP reached was.

        thoughts?

        • Developer

          Oliver,

               For the 2nd part, the mission planner includes the ability to set the active waypoint.  It's on the FlightData screen in the Action tab on the bottom left.  I'd totally forgotten about this when I replied above.  It works like you say, the pilot can set the command that the mission should start from before they engage Auto.  It can actually be set at any point in the mission.  This is available in AC3.2 (but not AC3.1.5).

               I've heard some people using do-jump commands to control which section of a mission should be run.  So if only the 1st half of the mission should be run, add a do-jump in the middle and make it jump to the final RTL at the end of the mission.  That do-jump command would need to be added before take-off though.

          • Randy,

            Regarding the first part of your response, will this feature work prior to engaging auto with AC3.1.5 or not at all? I'm a bit hesitant to switch to AC3.2 until it has been released as I'm very happy with the current firmware.

            With regard to "Do Jump" , if the mission is 3 flights long, adding a DO JUMP at the beginning to set the first waypoint, then at the end DO JUMP to the "RTL" at the end of the mission should work or am I mistaken?

            Once again, thanks for the response and for all the help and development!

  • Hi just installed v3.2 rc2 all went well but when i connect to the terminal so a can do a erase and clear 

    calibrating barometer appears and then a whole bunch of code keeps on going. How do i stop this so a can gain access the the commands to clear and erase like i always do after a new firmware install.

    Thanks for the help

This reply was deleted.

Activity

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
Monday
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…
Saturday
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…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
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
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
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
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
More…