Analyze Flight Log Errors

If the Parrot^® minidrone stops unexpectedly before completion of the flight time, you can download the flight log and analyze the errors. The errors that occurred during the flight of the minidrone are captured in the flight log (droneFlight.txt).

Note

Some of the errors are also displayed in the Parrot Flight Control Interface (in the text box below the START button, after the drone has stopped).

The most common errors displayed in the flight log and troubleshooting steps are explained in the below table.

Errors Captured in the Flight Log and Troubleshooting Steps

Type of Error	Error Message in Flight Log	Reasons for the Error and Steps for Troubleshooting
High acceleration	`rsedu_control(): Flight crash detected (accelerometer): shutting down motors now`	This error occurs when high acceleration of the drone is detected during the flight. To troubleshoot the issue, perform any of the following: Understand the instance at which the error occurred by looking at the flight log, and modify the controller logic to avoid the error. Provide a higher value for acceleration in the field Maximum acceleration of drone before safety abort in the Configuration Parameters window in Simulink (see Model Configuration Parameters for Parrot Minidrone).
Memory allocation error before take-off	`rsedu_control(): ERROR: Error from simulink model @ counter=401` `Memory allocation errorrsedu_control():Saving logged data after 401 cycles...`	This error occurs only if MAT file logging is enabled. MAT file logging tries to allocate memory on the Parrot minidrone. The amount of memory depends on the number of signals that are being logged and the simulation time. If the required memory is not available, a memory allocation error occurs. If MAT file logging is not required, disable the option MAT-file logging. If you require MAT file logging, perform any of the following: Reduce the simulation time of Simulink^® model so that the required memory (as computed by the drone before take-off) is reduced. Reduce the number of signals in the Simulink model so that less memory is required. Clear the memory of the drone (see Troubleshooting by Clearing Parrot Minidrone Memory).
Low battery voltage	`rsedu_control(): Flight aborted due to low voltage (29 %%): shutting down motors now, charge battery!`	This error occurs if a low battery voltage is identified before the take-off or during the flight. The minimum required percentages of battery voltage are 50% for the take-off and 30% during the flight. To troubleshoot the issue, ensure that the battery connected to the drone is fully charged before executing the start command from the Flight Control Interface. After the fully charged battery is reconnected, perform the tasks for connecting the Parrot minidrone to host computer over Bluetooth^® (see Setup and Configuration).
Optical flow and state estimate mismatch	`rsedu_control(): Flight crash about to happen, mismatch optical flow (-0.001362, -0.000360) and state estimate (27.352, -32.213): shutting down motors now`	This error occurs if there is a mismatch between the optical flow estimation and the state estimation of the Simulink model while the drone is flying. This error occurs for the `parrotMinidroneHover` model only (part of the `Hover Parrot Minidrone` project template). To troubleshoot the issue, redeploy the Simulink model and start the drone.
Optical flow is not present (for the `ParrotMinidroneHover` project and `ParrotMinidroneCompetition` project)	`rsedu_control(): Flight aborted due to error condition 69 !`	This error occurs if the optical flow values are not available for more than 50 cycles. This is configured in the `Crash Prediction Logic` subsystem (part of the `ParrotMinidroneHover` project and `ParrotMinidroneCompetition` project). To troubleshoot the issue, perform any of the following: Ensure that there is necessary illumination in the area where you are flying the drone, so that the image or video frame is properly captured for the optical flow. If you do not want to use the optical flow data in your controller logic, disable the optical flow in the `Crash Prediction Logic` subsystem (for details, see Optical Flow with Parrot Minidrones), and then deploy the Simulink model again to the drone.
Optical flow is not present (for `asbQuadcopter` project and any Simulink models created in R2018b or earlier releases)	`rsedu_control(): Problem with optical flow, there has been no flow for 50 cycles in cycle 723: shutting down motors now`	This error occurs if the optical flow values are not available for more than 50 cycles. To troubleshoot the issue, ensure that there is necessary illumination in the area where you are flying the drone, so that the image or video frame is properly captured for the optical flow.
User-defined errors	`rsedu_control(): Flight aborted due to error condition 5 !`	This error occurs if you have modeled some error condition in the Simulink template model. When the modeled error occurs, the corresponding error is passed to the `Flag` outport, which is then logged in the flight log. For example, in this error message, error condition 5 indicates that the error logic modeled by the user, corresponding to value 5, has occurred. To troubleshoot the issue, go to the Simulink model, look at the corresponding error condition, and perform the required actions to resolve the error.
Altitude estimation errors	`rsedu_control(): Flight aborted due to error condition 88 !`	This error occurs when the ultrasound sensor gives improper values while you are flying the drone using the `ParrotMinidroneHover` project. This could be because the drone is flying close to a wall or there are objects nearby that reflect the ultrasound waves, which results in the ultrasound sensor producing bad values. To troubleshoot the issue, perform any of the following: Ensure that you do not fly the drone close to the wall or any object that can reflect the ultrasound waves. Disable the check for ultrasound in the `Crash Prediction Logic` subsystem (part of the `Flight Control System` in the `parrotMinidroneHover` Simulink model). To do this, go to `Crash Prediction Logic` > `Ultrasound improper` subsystem, and set the value of the `Constant` block to `0`.

Analyze Flight Log Errors

See Also