Google Groups

Re: [drones-discuss] RC4 Failing Auto Missions


john...@gmail.com Oct 21, 2013 12:39 AM
Posted in group: drones-discuss
I would like to advocate simple sanity filters on all sensors, not just the GPS. By sanity I mean delta change triggers on values that clearly break physical limits. Such filter cost little to compute and will catch both code and HW errors as long as the error isn't building gradually. And in addition to decreasing chance of catastrophic failure, it can be used to highlight serious problems by logging the 'sanity' triggers.

- JAB

On Monday, October 21, 2013 3:54:26 AM UTC+2, Randy Mackay wrote:
Rob,
     Yes, as you say the baro data look very bad.
     Any chance you could go back to test 3.0.1 and see if it has the same problems so we can better determine if it's board or firmware specific?
     Also does it only occur while flying or can you reproduce it while it's sitting on the bench?
     Could it be light hitting the barometer?
-Randy



On Monday, October 21, 2013 10:36 AM, Robert Lefebvre <robert....@gmail.com> wrote:
Hi Randy, you might want to have a look at this.

I flew RC4 a whole bunch today including lots of acro which was really great.  But I also tried a few auto missions, and it failed every single time.  The failure also occurred exactly the same way in almost exactly the same spot every time.

This was with RC4+ compiled from trunk (about a week old-ish?) on an APM2.5 with:

#define FRAME_CONFIG QUAD_FRAME
#define OPTFLOW               DISABLED                      
#define MOUNT                 DISABLED            
#define CLI_ENABLED           ENABLED            
#define AUTOTUNE              ENABLED   
#define COPTER_LEDS           DISABLED
#define CONFIG_SONAR          DISABLED

(I had to do that so it would fit).  

I think I attempted 6 missions.  The first few were a standard test mission file I have saved.  Then I erased all the waypoints, uploaded that to clear the memory, then built a new simple mission and uploaded that.  It still failed on 2 attempts at almost the same place again.

Basically, it seems after passing the first real waypoint, the throttle is cut to minimum and it plummets but with stabilization running.  Investigation of the log file shows the issue appears to be a baro problem.  The baro returns a crazy result like 300m for quite a period of time.  This causes the program to cut the throttle to try and get it to descend to the WPAlt.  You can clearly see this in the logs.  The Baro comes back to reality sometime after switching to Stab.  

I'll attach a sample log, from what I've seen they are all the same.


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.