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

                  • it was RTL failsafe test - I literally turned off radio to simulate signal loss.

                    Drone reacted properly and started returning to original position.

                    In order to test it you got to be very careful, obviously. change altitude for RTL to 0 so it would not try to get anywhere high, leave it 50cm from the ground 4-5 meters away from the landing spot and have a good stick to interrupt it if it decides to get elsewhere. But if you tested regular RTL and it worked - there is 99% probability that failsafe RTL will work same exact way with no surprises, especially if you tested it all on the bench.

                    It is very odd if it happens with you by itself. Taranis and X8R will lose contact in less than a 2ft distance between transmitter and receiver, but if you did not get that close then you should not have this issue.

                    How did you power up X8R? Use an external 5V BEC for all consumers, do not power it up from the Pixhawk bus.

                    Also, if you re-soldered Taranis antenna to more powerful 5db or more then I would guess this zone would increase.

                    it is easy to test on the bench - power up system and get closer to the drone with transmitter - at some moment taranis will lose telemetry.

                    I highly advice you to create a Teensy powered solution to have all telemetry provided into lua script so you can see on the taranis all same data minimosd would show. it is very helpful.

                    http://diydrones.com/forum/topics/amp-to-frsky-x8r-sport-converter

                    Voltage failsafe level would depend upon how far you plan to fly, obviously if you have drone a mile away then you need to have more reserve. for me 13.9V works best as I only fly very near, no reason to limit flight time, as 13.9v gives me almost a minute to fly back and I am not concerned about a longevity of a $25 battery I use. this 13.9v under load - 14A - goes into 14.6 somewhat after disarming, it is fine.

                    What is not fine - I still cannot make it work, this RTL. And I do not like much that discussion went into direction of voltage values instead of been on topic of why failsafe RTL does not initiate upon reaching specified  threshold.

                  • Paul, Andy,

                    I'm using 4S batteries.

                    I was told never to go under 3.7v, but no one mentioned with or without load.

                    I was even told that few minutes after the end of the flight the batteries should be on 3.8-3.9v per cell.

                    You guys gave me few extra minutes flight time.

                    Thanks!

            • You can set one value for the mAH failsave for all your batteries, as long as you make sure you don't reserve to much from you smallest battery, otherwise it will impact flight time more then you may like.

              In these cases however I do switch the main value BATT_CAPACITY as well, so it does represent the correct battery.

              And I guess that's needed if you do use the mAh failsave option...
      • I have al logs but cannot tell now which one is which and when it happened.

        it happens sporadically, not every time but often enough when you fly it and it gets close enough to you, like 4-5 meters and then controls flip randomly. if you walk away from it - it stays flipped. switch modes - stays flipped if you go back to mode with 'simple' active on it.

        I will try to reproduce it again if I will have time to fly it tomorrow and will post it here. I think it was same in the 3.2 version as well. it happened last time when I had 15 sats locked in with hdop 1.02. I think it is a less than a 50cm accuracy of gps coordinates. difficult to understand why it happens at 5m distance from a controller as RTL lands drone back into startup spot within 30cm precision at this hdop.

        PS.  I noted - you said 'update of the angles'. It is not an 'update' that happens. All angles suddenly get inverted 180 degrees as drone gets near and they stay inverted as it gets away, no matter how far away, until you disarm it. 

        I had it on the APM with 3.2, I have same thing on 3.3rc5 on PX4.

  • Hi,

    could anybody confirm if battery failsafe works or expected to work in 3.3rc5?

    as I do not see it happening, at all. I see system to react as expected for a radio failsafe, but I do not see anything happening when voltage drops lower than a specified amount in the battery failsafe section.

    'reserved mah' parameter was set to 0, I only specified voltage - was it expected to work this way?

    • It works fine on my f550 running 3.3-rc5. Ran a pack down to 10.5v last week to try it and it landed within a metre of  where it was armed. 

      • I tested it twice yesterday - voltage is set to 13.9V for failsafe - I went down to 13.7 both times, I can see it in the telemetry, there was no indication of the failsafe activation

        Turning off radio shows failsafe banner fine and also flips 'failsafe' parameter in to 'true' in the status list.

        I am quite surprised. What should I check next? Not if this would be critical as I have dual telemetry on taranis and minimOSD feed with current voltage but it is a nice to have feature to automate RTL on this condition.

        • Check if your power module calibrated correctly

          https://youtu.be/tEA0Or-1n18

        • make sure you setup your voltage/current meter in the PM. very often Chinese PMs have different scale than 3DR ones, I remember to get the correct current measurements with one such meter I had to increase the amp/volt to 21.5. On the other hand, I actually had to drop volt/volt a bit, otherwise it would show lower voltage than all of my voltage meters and a multi-meter, maybe in your case you should bump it up a bit?  Anyways, I suggest first checking  if you've setup your f/s correctly, than see if the volts measured with a multimeter  are the same as reported by them mission planner connected via USB. 

          • Moderator

            I had to increase the amp/volt to 20.488 for my 3DR PM to get accurate current measurements, so it's not limited to Chinese versions.

            Regards,

            Nathaniel ~KD2DEY

This reply was deleted.

Activity

Neville Rodrigues liked Neville Rodrigues's profile
Jun 30
Santiago Perez liked Santiago Perez's profile
Jun 21
More…