Support training, log analysis


Is there a plan to create a knowledge base, or log analysis tools?

Here is my issue. I have some logs and there are error:cpu1 and error:cpu0 in a couple of the files, and then in subsequent logs, the cpu error is not present, and ekf errors are present while the rig is flying erratically.

So, while you all are developing, and have all the intrinsic knowledge which is needed for developing, there is also a great need to get the knowledge transferred to others who can do the troubleshooting versus you all.

That all being said, please point out or advise if I am missing something. I am also happy to immerse my brain into this effort, if someone has the availability to do some support training.


I am +1 on this.

The developers are doing a great job, but I know that attention to code is scattered when having to do a lot of support issues.

Now I would be no good contributing to code, but I have worked my way through quite a few problems and enjoy helping others out where I see common issues.

It would be great if there was a knowledge base or training that would enable myself and others to diminish the number of support issues the developers need to tend to.
I know the Wiki and manual pages are there and do refer users to these where applicable, but I am losing touch with log analysis with the introduction of EKF and a whole host of other processes.

Maybe if there was a way to stay in touch with all and any changed documentation?

We do have a lot of tools for log analysis and most are available in MAVProxy/mavlink. The best tool is MAVExplorer - wiki page here
Log analysis is harder then you think for flight problems. Less then 10 people in the world can diagnose EKF issues - its really hard. Normally if there are EKF errors its because a component is calibrated incorrectly or setup incorrectly. This is what the arming checks aim to find which is why its so important to pay attention to them.
However in my experience MOST of the issues users have are parameter configuration issues possibly also related to their hardware setup. The easiest way to diagnose these are getting a log file (tlog or bin) and running logfilename
to extract the parameters from the log file. You can then compare this parameter file with a “default” parameter file. You can get the latest default parameter file for any vehicle type from
Note this is the very latest parameter file from the master code so it will have some differences but its somewhere to start. You can then run default-log-file user-log-file
and it will show you the differences between the parameters to help you diagnose.
Now remember that in stable releases of ArduPilot its rare to get a bug in comparison to the number of support issues raised. Again almost all the issues are configuration so any help that can be provided to users helping out there would be great.

@Tim - I have no idea what error:cpu0 etc is. I couldn’t find anywhere in the ardupilot code that that error is generated. If it is an issue please raise a separate support post and attach a log file.

Thanks, Grant.

So what your saying is this is only from Terminal and only under Linux, and that is the only option for in depth log analysis.

It seems a bit counter productive in that I would have to dust off my old Linux books and grape with a CLI to assist.

@mboland LOL, it is what it is. :wink:

Which busting out those books may be better than attempting to get the pieces to work in windoz. I feel your pain.

Python works in Windows… And there are:

As always, the issue with all of them is keeping up with the changes to master. But they are a good first approach to look at a log.