I had a bad crash yesterday when my quad lost GPS and the autopilot switched to optical flow despite it being disabled (and actually not having or ever having one). The GPS failure is obviously the triggering event and I’m suspecting of a bad cable because it shows No-GPS status. It’s the second time it happens in this quad but last time it was just a ‘forced landing’. What I’m really surprised this time is why it switched to optical flow. After that the copter just went mad (I guess for trying to use optical flow without any sensors), showed EKF variance and FAILSAFE_EKF-1 and a Land command, which it never did because it just lost control and crashed.
I’m attaching a screenshot of one plotted graph and a link for the dataflash logs. Some insight will be highly appreciated!
Switching to optiflow is intended. Of course, it won’t help since you don’t have the sensors, but as I understand, it should be no worse than not switching, since both GPS and flow are null.
Copter 3.4.0-rc6 15-Oct-2016
Changes from 3.4.0-rc5
[…]
6) Safety:
a) EKF falls back to optical flow if GPS fails
Your log shows that the craziness you observed was not intended by the flight controller. That is, it wasn’t a non-existent optifow that was causing the unstable behavior. By the time LAND was initiated, all position and velocity estimation had stopped, so the FC commands a ‘straight down’ land routine where it just descends while keeping pitch and roll at 0. But, as you can see, the pitch and roll go crazy for some reason. This may indicate some hardware failure other than GPS.
In fact, your motor PWMs strongly suggest that motor 4 had failed, as the flight controller is asking for maximum effort from it, while throttling down the two counter-rotating ones. If your copter is still somewhat intact, check your connections and solder joints on motor 4. ESC/motor overheat is another possibility.
Rick, thanks a lot for your very quick reply and analysis. I was doubtful if motor behavior was cause or effect specially because I don’t really know the details of the control algorithm when using optical flow. I won’t think cabling may be an issue (this frame is very robust) but perhaps a fractured propeller from a previous incident.
I’ll repair it and have a detailed inspection of the GPS cable, connectors and board and fly again. Just to be sure about this, what would be the effect of trying to use optical flow without the sensor installed? What would be the expected behavior? Do you know the idea behind this feature of trying to use a sensor even if it is not installed or enabled? I thought I read somewhere when this kind of GPS failures occur, the control tries to rely on IMU only.
The effect of trying to use optical flow without the sensor is the same as using GPS mode without a GPS. In both cases, the flight controller uses the IMU only - if you are flying manually (e.g. in Loiter), it will switch to a non-GPS flight mode like AltHold with an audible warning from the buzzer. In auto modes like Auto, Land, and RTL, it will attempt a straight-down landing by maintaining pitch and roll at 0, as in this case.
You have GPS set to be your primary position sensor. Arducopter supports blending of different sensors, so some copters will have both. The optical flow fallback behavior just means that it is attempting to use a secondary sensor since the primary one has failed. It’s not so much switching modes as it is searching for an alternative - if the GPS ever comes back, it will immediately switch back to GPS instead since it is still configured as your primary source. Basically, you can read the “is now using optical flow” message as “now attempting to use secondary position source.”
