ArduCopter-3.2 beta testing

Replies

- Bartek > Paul Hammond December 2, 2014 at 1:50am
  
  I think u have to flash copter software if on APM is plane version or flash plane if u have copter on APM , that should erase eeprom to default values.
Rob Ratcliff November 28, 2014 at 5:38pm

I have a Hexacopter with a Pixhawk and have the released version of Ardupilot 3.2 firmware loaded. I performed the accelerometer, compass and R/C calibrations out in the field. My goal was to test a simple mission of a few waypoints spaced at just a few yards apart with the copter tethered with a 100 foot line to avoid a runaway.

The first flight went great. The copter performed perfectly. I moved the Hexacopter back to the center of my course, cycled the power and tried another mission. This time though, the copter went into this wild oscillation right after launching and ended up crashing. After the crash, I noticed that the Pixhawk had came loose from the double stick mounting pads that came with the Pixhawk. I'm not sure if it came loose due to the crash or was in the process of coming loose, which may have contributed to the behavior.

Here is a video:

http://youtu.be/Hl93Gt90KFM

I didn't notice anything obviously wrong in the logs except for the wildly oscillating pitch, roll and yaw. I've attached the logs from the crash in case anybody can see an apparent problem.

(I'll try it again with the Pixhawk more secured, once I fix the broken mounting points in the frame. )

Thanks for any feedback!

Rob

2014-11-28 12-04-49-wobble-crash.bin

2014-11-28 12-04-49-wobble-crash.log
- Moderator
  
  Nathaniel Caner > Rob Ratcliff November 29, 2014 at 12:09pm
  
  Hi Rob,
  
  I've been thinking about what you've described, and by the way, I think we're all glad you had a moment of ESP when you decided to tether you're Hexacopter; what is your WPNAV_RADIUS set to? I ask this because you describe the mission as "a few waypoints spaced at just a few yards apart". Thinking about this, if the waypoints were set apart less than twice (at least) the distance described by WPNAV_RADIUS, you would create a series of waypoints whose radius create circles with intersecting sections. This creates a unique circumstance where you could possibly create a zone where all waypoints could be "reached" at the same time. In theory this could result in some pretty wild oscillations.
  
  Consider the following examples:
  
  In Figure 1 we have a box described by 4 waypoints that form a square; the waypoint radius in this example creates 3 distinct overlapping zones. The black circles indicate the circular zone created by the WPNAV_RADIUS around each WP indicated by the small red circles. In the Blue zone all four waypoints would be considered by the FC to have been reached. In the green zones 3 of four waypoints would be considered to have been reached, and in the yellow zones 2 waypoints would be considered to have been reached. Only in the white zones would the waypoints by individually described, and this would only be true if we overshot the waypoint.
  
  In Figure 2 the waypoint location has remained the same, but we have reduced the WPNAV_RADIUS shown in black. There are no overlapping zones so the FC would not oscillate.
  
  Lastly in Figure 3 we have moved the WP locations further apart and kept the same WPNAV_RADIUS as in Figure 1. Again we have no overlap, so the FC would not oscillate.
  
  Your WPNAV_RADIUS = 200, or 2 meters; so if your waypoints are spaced closer than 4 meters apart you are going to have at least some overlap as in Figure 1. The mroe your waypoints overlap, the greater the likelihood you might see some strange behaviors.
  
  Can you post a copy of you mission file, or a tlog from your flight?
  
  This is all just a theory, and I welcome the opportunity to either confirm or deny it.
  
  Regards,
  
  Nathaniel ~KD2DEY
  - Rob Ratcliff > Nathaniel Caner November 29, 2014 at 1:09pm
    
    Thanks for the reply.
    
    I'm using an WPNAV_RADIUS of 2 m (200 cm). But, I noticed that I managed to place the first two waypoints on top of each other, which in the MP shows NAN for the gradient. I haven't looked at the code to see if a NAN for gradient would confuse the flight controller.
    
    I've attached a picture of my waypoints and the mission description.
    
    wobbly-mission.png
    
    wobbly-mission.txt
    - Michael Burmeister > Rob Ratcliff November 30, 2014 at 5:08am
      
      The flight was doomed from the start. As soon as the copter armed the copter was told to bank hard left and forward. Since it was on the ground at the time, it started flying in a circle which just confused the rest of the electronics to the point where it was over correcting and thought it was flying downward into the ground.
      
      It also looks like you are not using a Transmitter as RCIN was all zeros.
      - Rob Ratcliff > Michael Burmeister November 30, 2014 at 8:42am
        
        Thanks Michael for looking at the log.
        
        No transmitter was used in this test, only MAVLINK commands over the telemetry.
        
        What parameters in the log did look at to come to this conclusion? ATT/DesPitch and ATT/DesRoll?
        
        That is odd that roll and pitch was commanded. The only commands being sent over MAVLINK are RC OVERRIDE on Throttle just enough to get it into AUTO mode. Then the flight mode was set to AUTO. I noticed there is non-zero values for DesYaw as well. Not sure why that is.
        
        I wonder why the flight controller would command pitch, yaw and roll for TAKEOFF?
        
        One thing that I ended up having to do with my transmitter setup was remap the channels. If you notice, RCMAP_THROTTLE is 2 (usually 3) and RCMAP_PITCH is 3 (usually 2). Not sure if that is causing any confusion. It's worked fine on previous flights though.
        
        I noticed that RCIN/C2 was at 1000, which should be 0% throttle in PWM. The normal value looks like its 0 for the RCIN commands. Shouldn't those all be at 1000?
        
        Doug Walmsley > Rob Ratcliff December 1, 2014 at 7:07am
        
        Maybe I'm out in left field, but was all props checked to ensure they were tight to the motors? After reviewing this, I recalled a year ago on my Hexa when I threw a prop and my Hex went into a crazy oscillation pretty much the way yours did. Also check to see if any motors are loose on their mounts. Just another thought to share.
        
        Rob Ratcliff > Doug Walmsley December 1, 2014 at 8:28pm
        
        Thanks for taking the time to reply. My motors and props are all tight.
        
        I should have the F-550 frame repaired this week by epoxying aluminum sheet metal across the breaks and will try a few simple tests to see what's going on. The biggest difference between the two flights was that the first one had the R/C on and the second didn't. I haven't had to have the R/C on in the past so I'm skeptical that there is a bug related to that, but its worth checking out.
        
        Michael Burmeister > Rob Ratcliff November 30, 2014 at 10:19am
        
        Yes, that did confuse me. Still the RCIN should be at a minimum of 1000 and a max of 2000. Yours are at 0. That would mean Fly hard Left and Down.
        
        This is what the graph shows just before Auto was started. Auto would then correct this because radio input is not used.
        
        Mike
        
        Wooble.png
        
        Rob Ratcliff > Michael Burmeister November 30, 2014 at 11:54am
        
        I also noticed that the barometric altitude tracked opposite the integrated altitude, probably due to the wobble. I've seen this happen in the past when the vibrations are large. I wonder if the Kalman filter would do any better in situations like this?
        
        I would've hoped the flight control system could've recovered eventually. (Of course, if the Pixhawk was loose there wouldn't be much hope.)
        
        I've attached the plot.
        
        alt-pitch-roll-wobble.png

of 373

Discussions

ArduCopter-3.2 beta testing

Replies

Activity