I know there's all kind of stuff out there now to improve readability of the data flash logs but I still struggle to get what I'm looking for. I just had my Ironman 650 drop to the ground right around the time I switched to AltHold or Loiter mode. Flying in Stabilize seems to be fine.

There were two instances in this flight where I saw a sudden drop right around the time I changed modes (the second is obvious in the log). The first time was recoverable by flipping back to Stabilize, the second was not. I'm just trying to figure out if it's maybe a GPS issue or something totally else and any help would be appreciated.

2016-04-30%2011-14-18.log

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • The logs show you switch to Altitude Hold and then lower the throttle all the way down at which point you switched to Stabilize which caused the copter to drop from the sky.

    Since you where not logging RCIN and RCOUT I would assume that the radio went dead which caused the copter to fall and Stabilize being selected.

    • The description is consistent with how I perceived the failure in real time.  I'm trying to get my view in Mission Planner to illustrate no RCIN/RCOUT at the time it was in Alt-Hold and determine if it happened at the exact time it entered the mode.  Since it happened twice in the flight, it should be evident that it happened twice.  The first time I recovered by flipping back to Stabilize and I'm guessing RCIN/RCOUT started logging.  It came close to hitting the ground the first time but I had enough altitude and flipped to Stabilize in time to recover. 

      If that's the case, why would Alt-Hold cause the APM to not receive RCIN/RCOUT twice in the same flight.  I've flown this quad successfully for over two years.   I've replaced my APM this past summer and I've more recently replaced my compass/GPS combo.  Does Alt-Hold interact with the GPS in any way that can cause this?

      • You are running an old version of APM.  3.2.1. is the latest and you are also using RCMAP to put the throttle on channel 1.  This can lead to all kinds of problems.  I don't believe its fully supported on this version but I think you can get it to work with some manual fixes.  Don't know how it works with 3.1.5.

        GPS was not good but did not cause any issues that I can see here.

        • Good point on APM version.  I think when I swapped out APMs I never upgraded to the last version that fits APM 2.X (3.2.1).  As for the channel, yea, I never liked that one either but I use dragonlink on PPM.  By default they have throttle on channel 1.  They have a newer micro version that lets you re-configure channel assignments but the version I have does not.  Before I changed my RCMAP, I found a few discussion threads about changing RCMAP (not many out there) - the big concern was making sure failsafe still worked.    It could very well be there is an issue with this as you point out with this version (or maybe with any version).  My alternative is to not use single PPM and go back to multiple servo wires (I think I'm using 7 channels total).  I had to order some parts due to the crash damage and I decided to upgrade to a pixhawk at this time as well so I could get the latest and greatest firmware too.  I need to think about what to do about the single PPM and RCMAP changes.   Hopefully in a the latest version it's fully supported - I just wish there was a good way to test it on the ground.

          • The basic problem with channel mapping is that the RC1_MID does not follow that channel.  So if channel one is your throttle it will be calibrated as roll and have the mid value set to the middle instead of the minimum value.  And if your roll is channel three then it will be set to minimum and cause the copter to flip on takeoff.

            If after tunning this is the case just swap these values for the correct mapping and it should work.

This reply was deleted.

Activity