I posted this a few days ago. 

 

http://diydrones.com/forum/topics/altitude-loss-in-auto

 

I am getting a little desperate here. 

 

This application is for US/Mexico Border security.  We have a sensor system in place and the hexacopter is launched on alert,  with 2.8.1 we were flying great.  We upgraded to 2.9.1b and we can't fly auto and it is killing our progress because we are stuck on this darn problem.

 

I have a background in UAV development specializing in PID tuning so while I am new to the Arducopter APM I am not new to the field.  This problem is making me crazy and I need some new eyes to look at it.

 

This is a real offer.

Views: 1144

Reply to This

Replies to This Discussion

Do you have logs and/or tlogs to post? Without that there is little we can analyze.

Just a thought,

You said it flies well in stabilize and alt hold so I have to presume you are trying to fly at least to test this at approximately the same speed you would be flying in auto.

If flying in alt hold is holding the altitude when you try to fly manually at approximately inter-waypoint speed, I don't think that the speed of air movement can be the problem. (If it does descend, then local air movement is the problem).

Assuming it isn't, is it possible that some how your actual waypoint altitude is not set correctly or at least, as you expect.

There is also a waypoint option bitmask that among other things allows altitude to be set relative or absolute, I think it defaults to realtive which is OK but if it is set to absolute that could be a problem.

Where is this bitmask?  I am unable to locate it.

This is what happens when a Hexacopter attacks your arm.  This happened this morning!

Here are some flight logs.  speed of aircraft was 7 on this flight but has never been a problem before, 

 

In this test I manually launched and turned it over to the APM.  The craft flew west descending rapidly.  I then took it back and tried to figure out what direction it was facing as th KML file shows.

Attachments:

From what I can tell from this log is that the APM saw it was low but did not ascend.

 

Below are the logs

Here was the test.

  1. launch manual - Stabilize
  2. Switch to Atlitude hold (Functioned perfect (with sonar))
  3. Stabilize
  4. Altitude hold - same results
  5. Stabilize
  6. AUTO- immediate decend
  7. Stabilize
  8. Altitude hold - Rapid ascend
  9. Stabilize - landed copter.

 

This is very repeatable.  If I go into AUTO mode, altitude hold tries to put the copter into orbit.

 

Any clues here?

Attachments:

My advice, set higher default altitude, set higher way point altitude and test :)

Hi Michael,

I am not sure that you have access through Mission Planner, but you can see it referenced here as waypoint option bitmask, and of course there is a big difference between relative and absolute altitude.

https://code.google.com/p/arducopter/wiki/AC2_Waypoints

Seems unlikely to be the problem though.

Probably a good idea to try flying at same speed as waypoint traverse in alt hold and see if it descends.

If it does then the problem is as has already been said a necessity that the APM bebetter isolated from turbulence so the baro doesn't get confused. 

If you switch to Auto does the quad turn in to a certain heading?

If yes read this

The mysterious AltHold problem .... solved

Nope, that's not the problem. I can repeat the above probl inside or outside. It screws up in auto and after being in auto.
Ouch. Sorry about that.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service