Copter-3.3 beta testing

Replies

- - - Geert Pirens > Nathaniel Caner May 21, 2015 at 12:11am
      
      Yes, I secured my gimbal and started autotune and completed after +/- 7 minutes.
- Johnex > Nathaniel Caner May 20, 2015 at 2:28pm
  
  Answer to that in the second post here:
  
  http://diydrones.com/forum/topics/ac-3-1-autotune-support-discussio...
  - Moderator
    
    Nathaniel Caner > Johnex May 20, 2015 at 3:40pm
    
    Johnex,
    
    Thank you for the reply and link. That makes sense but is a big disappointment. Taking the gimbal and camera off is a major exercise, not to mention that the CG will be off again and I will need to relocate other equipment to get the CG correct.
    
    I suppose I have two options; I can either remove the gimbal and secure an equivalent mass in it's place, or I can try to determine a way to disable the isolation mount and secure the gimbal.
    
    At least I can rule out Autotune with the gimbal powered!
    
    Regards,
    
    Nathaniel ~KD2DEY
    - Developer
      
      leonardthall > Nathaniel Caner May 20, 2015 at 5:05pm
      
      If you don't intend to fly with the gimbal off then you can give autotune a go with it on. The new autotune should give perfectly flyable tune with a gimballed even if it isn't as good as it could be (done the time consuming way).
      
      So try with gimbal on and powered and see how you go.
      - Moderator
        
        Nathaniel Caner > leonardthall May 20, 2015 at 5:19pm
        
        Leonard,
        
        Thanks for the response. I'll give it a try if the weather cooperates. If I get the chance I'll try it both ways.
        
        Regards,
        
        Nathaniel ~KD2DEY
turdsurfer May 20, 2015 at 2:00pm

I installed 3.3-rc4 and found that this bug that existed in 3.2 became worse (at least for me):

In 3.2 I could set any AUX output's RC*_FUNCTION to 7 or 8 (for mount tilt/roll) and only on RC13 would no signal be passed through. The other AUX ports (including RC14) pass the tilt or roll value through fine. Unfortunately for me, the only unoccupied AUX ports are RC13 (AUX5) and RC14 (AUX6), so that left me in a tough situation. I tried 2 different Pixhawks b.t.w. to exclude the possibility of having a damaged RC13 port.

With 3.3-rc4, the situation became worse, with the exact same parameters file imported: No matter on which AUX output I set the RC*_FUNCTION to 7 or 8, no signal is output.

I have BRD_PWM_CNT set to 6, but I've also tried other values to no avail.

In case it matters: I'm using a 12 channel SBUS RC connection.

So for the love of the god that does not exist, for both 3.2 and 3.3 as I've been messing around with this problem since 3.2 was released:
How are gimbal users supposed to get the mount tilt and roll values out on AUX ports for RC13 and RC14 if all other RC outputs are occupied (my other AUX channels are set to pass through RC channels for switches, lights etc).
Doug Walmsley May 20, 2015 at 9:58am

Yesterday I flashed RC4 and installed a LiDAR Lite unit on my drone and performed some tests for all to review. Please take a look at the information below as I have both good things to say about the PWM drivers and LiDAR performance but also some anomalies and one suggestion. I will upload this evening my flight files and hopefully a video or two and a pic of my airframe with LiDAR unit on it.

Thanks Devs for the hard work! It really shows in the product we all are enjoying from month to month.

Regards,

Doug Walmsley

---------------------------------------------------------------------------------------------

Y6B Specification

    • 3DR Y6B frame

    • 690 kv motors

    • 25A ESCs

    • Pixhawk

    • Neo-M8N GPS (Primary)

    • Lea-6H GPS (Secondary) with active compass on 30cm mast

    • 600mw FPV transmitter and fix-mounted camera

    • LiDAR Lite (PWM) configured

    • 1247 (Top) Props

    • 1347 (Bottom) Props

    • LiDAR unit mounted aft section of frame (forward of tail boom) wired into pin 54 & 55 for PWM interface.

Firmware Version / Configuration

    • Arducopter 3.3 rc4

    • PWM Driver Parameters

    • RNGFND_TYPE = 5

    • RNGFND_STOP_PIN = 55

    • BRD_PWM_COUNT = 4

    • RNGFND_SCALING = 1

    • RNGFND_OFFSET = 2.5 (added as a result of calibration testing) *

    • RNGFND_MAX_CM = 4000

    • RNGFND_MIN_CM = 20

Workbench Test Results

     • Test One (Floor to Desk Height) – Y6B sitting on desk extending sensor out over floor

         • Height – 42.5 inches or 1.079 meters.

         • Sensor Readout (Manually vs Sensor Measured) – 1.079 vs 1.06 meters

    • Test Two (Desk to Far Wall) – Y6B tilted 90 degrees from horizon and pointing to wall

       • Distance – 21 feet or 6.4008 meters.

       • Sensor Readout (Manually vs Sensor Measured) – 6.4008 vs 6.235 meters

    • Adjustment (RNGFND_OFFSET)

       • To compromise between the two tests, a value of 2.5 was set in RNGFND_OFFSET which provided a closer
         range measurement of:

          • Desk to Floor – 1.07

          • Desk to Far Wall – 6.395

* Note: A calibration test and adjustment should be conducted to ensure correct altitude readings AGL.

Flight Tests

    • Noise/LiDAR Interference – At this time no noticeable loss in GPS quality with LiDAR actively running using

       PWM interface.

    • Flight Modes Tested

      • Alt Hold

      • Pos Hold

      • Loiter

      • Auto Land

   • Anomalies

       • “Bad LiDAR Health” intermittently appearing throughout low altitude flight (<40m).

       • “Bad Gyro Health” intermittently appearing after lifting copter to 50cm to activate LiDAR unit and during flight.

    • Suggestion

      • Reduce rate of decent by one half when descending inside 5 feet AGL using LiDAR for gentler landings on uneven surfaces.

Diary to Self,

LiDAR Lite worked great and never locked up on three flights and 30 minutes of bench testing. I also did not see but haven't studied my logs in-depth to witness any anomalies such as noise spikes or GPS interference.

I had to bump my offset to 2.5 to align the sensor's height to read the distance from floor to sensor and from sensor to wall across room.

Conducted two bench tests with my Y6B. First test was to sit it on my workbench and physically measure from floor to sensor. The measurement came to 42.5 inches or 1.079 meters. When I ran the sensor test, it teetered between 1.05 and 1.06. Normally this is negligible, but when I ran the same test from work bench to wall across room at 21ft or 6.4008 meters I discovered that the sensor was measuring lower values of 6.235. This is where I mentioned earlier of using offset at 2.5. This bumped the sensors measures to come within 1.07 and 6.395 meters of actual measurements. Not sure if this will hold true for all LiDAR units, but some level of calibration will be needed by pilot to ensure accurate results.

All three flights were tested with auto-land, Alt Hold, Pos Hold, and Loiter. I also I used the parameters outlined in the wiki site. I noticed the LiDAR alt stopped when it hit the 35-40 meter altitude as discussed and reinitialized when decent was below 40 meters.

Lifting the drone to above 50cm once power is applied is required in order to initialize the LiDAR and allow the arming process. If you do not do this you will get tones when attempting to arm via radio and the motors will not spin up. This is by design and I believe there is an option to disable that function although I cannot recall why they put this process into place.

All tests indicated LiDAR unit worked in these modes although I'd like to see a smoother decent/final landing as all three flights exhibited the same somewhat aggressive landing from within 10ft of ground. Request to ask Randy to look into an altitude AGL of 5 feet where the copter slows rate of decent to half of is present landing speed allowing for gentler landings on both even and uneven surfaces. Two of the three times, the copter landed in backyard (which is uneven) at decent rate which caused it to tip over. I feel more work is needed to ensure a gentle landing to help mitigate crashes or tip overs caused by quick landings. The tip over in the grass caused no damage but motors still ran for a few seconds before the system determined it was a crash and auto-disarmed. If this was on concrete, more extensive damage could have occurred.

Also one other issue I'm researching. I noticed that when I lifted the Y6B up for the LiDAR initialization and place it back on the ground, arm it and lift off that I start receiving "Bad Gyro Health" but it would go away after a undetermined few moments and come back on and off throughout flight. Not sure this is related to rc4 or the LiDAR or both, but I get intermittent "Bad LiDAR Health" and intermittent "Bad Gyro Health" lately since implementation of RC4 and the LiDAR install.
- Robert Szabo > Doug Walmsley May 23, 2015 at 9:19am
  
  rc5 - Lidar vs Baro alt. At 2.5min and 19min it appears Lidar stopped reading. Did you have any similar experience?
  - Doug Walmsley > Robert Szabo May 25, 2015 at 12:34pm
    
    Throughout several tests on two different copters, none exhibited the issue you mentioned. I took my Y6B up albeit shorter flight time than yours, but I never lost the sonar signal though out the flight. Mine operated without fault. See image.
    
    Suggest you double check all connections while it's on the bench and using "Tuning" to see if you can see the drops in voltage and sonar signal. Good Luck.
Scott Reid May 19, 2015 at 7:49pm

Crash on rc4 - possible gyro issue?

I'm posting this log here in case it's useful, as there's been some gyro issues mentioned in Rc4, and the logs here show an anomaly in IMU.GyrZ before anything else appeared to go wrong. This is a 750-sized Y6 on 3.3-rc4. Take off in Loiter after a few succcessful takeoffs and touchdowns in stab. After a few seconds, it started violently rolling and pitching. Fortunately just a few meters off the ground and just prop/adapter damage (and a new little bald spot in my lawn).

15-05-19_18-13-58.bin

of 558

Discussions

Copter-3.3 beta testing

Replies

Activity