Discussions

3DR Pixhawk not following auto waypoints

Posted by Bagrat Rashoyan on May 3, 2014 at 11:53am

Hi there,

All my 3 pixhawk autopiots have stopped

following waypoints. You can see the trajectory 

followed on the right. Can anyone please suggest a solution?

I have tried mounting the GPS compass moduel

high, but still does not help :(

3691118255?profile=original

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

Join diydrones

Email me when people reply –
Follow

Replies

  • Tim Haynie August 29, 2014 at 1:53am

    Mine had a similar event the other day only it never made it to the first point, ended up flying a circle with the last course-correction putting it into a hillside (took 3-days to find it!)

    Going to review the log files today (board is in a bag of rice drying out) to see why.  I suspect interference (I live near two military bases (not going conspiracy-theory!)) since there are lots of sources of RF present.

    I'll post what I find.

    tim

    • jdburne > Tim Haynie September 26, 2014 at 4:19pm

      Tim did you resolve this?  My quad absolutely refuses to proceed to any waypoint or RTL, although it arms fine and loiters well.  

      • Tim Haynie > jdburne September 29, 2014 at 8:58am

        Posed the question to a UAS engineer and here's what I got...  

        "

        I started looking at NTUN items in the log. This is where things are a bit off. I see an oscillation in the navigation system. This means the aircraft tried to get on course, but couldn’t quite figure out where it needed to be. I was comparing DPOSX and DPOSY compared to actual POSX and POSY. Here we see some issues. The aircraft attempted to make a course correction, but overshoots both and then overshoots the other way. In the end, it looks like it make it where it was suppose to go in the X-axis, but not in the Y-Axis (I graphed NTUN data for DPosX and DPosY and the actual PosX and PosY and you see at the end the POSX and DPOSX are matched. We also see POSY way different from DPOSY.)

         

        I do not have compass data from the aircraft. You need to enable compass data for the logs in the future to properly diagnose, but I have a feeling the compass calibration was off OR compass orientation was incorrect. A compass that is incorrectly setup for any reason would cause a similar issue to what you are seeing.

         

        I also do not see the RCIN and RCOU records in the log file. Again, you should enable logging of these values so we can see actual stick inputs and the actual outputs to the motors.

         

        It appears the aircraft never received the command to get out of auto mode. It was in stabilize at the beginning of the flight, switched to auto and took off, but I never see it switched back to stabilize. Again, having RCIN as a logged parameter would allow us to see some of this data and would help us figure out if the aircraft lost contact with the radio.

         

        I would say the issue is a combination of a funky compass setup/calibration/issue and possibly a Loiter tuning issue. (Look at the Rate Loiter terms and the Loiter PID term as possible tuning points) The values reported are typical, but the graph tells me something slightly different. Based on the idea that the terms are fairly normal, I go back to the compass causing the issue.

         

        2014-08-26 19-02-34.log

        https://storage.ning.com/topology/rest/1.0/file/get/3702669071?profile=original
  • Simon Faulkner May 4, 2014 at 7:52am

    Hi Bagrat,

    I am new here so I hope that there will be better answers along after mine...

    The beauty of an OpenSource solution like ArduPlane is that all the data logging is available for you to analyse and troubleshoot with.  Going on what you have posted might be quite tricky but the logs will probably hold the definitive answer.

    I have just had the same problem and I have linked to my log because most of the experienced people here seem to be able to step through the logs fairly quickly to spot issues and problems.

    It does look like your vehicle tried to follow the route after a fashion.

    I am expecting that you will be encouraged to check the HDOP (Horizontal Dilution Of Precision) in the logs when the PixHawk is off course.  The HDOP is a measure of the GPS accuracy and if the GPS was inaccurate at that moment it would explain the impression of the track.

    What was the wind?  Although I am new to PixHawk it seems fairly obvious that if a vehicle is being blown off course it can only fight against that force to the limit of it's performance.  Was the wind strong enough to prevent the craft making the points?

    I look forward to hearing about how this is fixed.

This reply was deleted.

Activity