Performance Monitoring for v3.3 logs

[bionicbone]

Errors occur for this type of analysis under v3.3

[bionicbone]

Test file: RoboCat 270, any log

[bionicbone]

I added this fix in as it was very quick

However, the Pixhawk Hardware has very different results in the PM line.

I have raised a WiKi issue to see if we can have more clarification. https://github.com/diydrones/ardupilot-wiki-issue-tracker/issues/286

[bionicbone]

@TheQuestor , does this sound OK to you?

NLoop should be Clock frequency * 10, i.e. my APM logs 100Hz so NLoop = 1000, my Pix Logs are 400Hz so NLoop = 4000. As far as I am aware the APM was also allowed to run at 400Hz in later firmwares but could be reduced to 100Hz when issues occurred (can't remember what issues :)).

Key is that NLon (number of long loops) is not more than 15% of NLoop (total loops), I think Devs used to quote 5% for APM when that was supported!

Recode to have one main analysis for all versions / hardware:

• Wait for feedback from Hamish before continuing in case the update from the Devs differs from our first analysis, monitor pages / threads, http://copter.ardupilot.com/wiki/common-downloading-and-analyzing-data-logs-in-mission-planner/ and diydrones/ardupilot-wiki-issue-tracker#286
• Keep the PM_DelayCounter > 3 before reporting long loops, this helps filter take off and Landing events which were normal on APM hardware and caused great concern when being reported to the general public in my initial analysis, but can it be reduced to 1 or 2 skiped vlaues given the following?
• Replace the hard coded NLon detection of > 70 and create warning levels of >3%, >5%, >10%, then APM Dev ERROR of >15% against the NLoop value. Devs say >15% is the Error figure. Personally I'm not sure as my logs for an X8 APM Hardware running v3.1.4 completing a complex mission were lower than this (3% to 5%), I'd expect to have seen some warnings at least (even discounting take off and landing events). However, there were never any visual in flight issues after heavy testing (frame based around the X666, 1000KV Motors and 9045 props). Need to dig out TheQuestor landing on friend roof log, although perhaps I2C errors played a part?
• Create new warning if PM_MaxT is > 15% of the PM_NLoop value where PM_DelayCounter can be accepted, I have some values that are massive on APM logs.

Run all test logs before releasing, and some old archived APM logs, if results are good switch back on analyse the Performance Monitoring by default.

If we can not set PM Checks back on as Default the GCS and I2C Error monitoring must me moved to separate code as currently these are not monitored by default due to the data being held in the PM dataline.

[bionicbone]

Some Test code in Branch Performance_Management

[TheQuestor]

I gotta say most of what you wrote is WAY over my head lol. Some it made sense but a lot of it sounded like a magic language.

I kind of wish the devs would slow down some and stop changing so much so fast.

It looks like you have a handle on things though and this tool just keeps getting better and better and I wonder why Michael hasn’t asked you to integrate this into mission planner yet!

Hopefully in the next week or so I can get my quad and hex out for some logging tests to see just how well the app is working J

From: Kevin Guest [mailto:notifications@github.com] Sent: Wednesday, February 10, 2016 2:29 AM To: diydrones/APM_Log_File_Analyzer APM_Log_File_Analyzer@noreply.github.com Cc: TheQuestor thequestor@gmail.com Subject: Re: [APM_Log_File_Analyzer] Performance Monitoring for v3.3 logs (#222)

@TheQuestor https://github.com/TheQuestor , does this sound OK to you?

NLoop should be Clock frequency * 10, i.e. my APM logs 100Hz so NLoop = 1000, my Pix Logs are 400Hz so NLoop = 4000. As far as I am aware the APM was also allowed to run at 400Hz in later firmwares but could be reduced to 100Hz when issues occurred (can't remember what issues :)).

Key is that NLon (number of long loops) is not more than 15% of NLoop (total loops), I think Devs used to quote 5% for APM when that was supported!

Recode to have one main analysis for all versions / hardware:

•   Wait for feedback from Hamish before continuing in case the update from the Devs differs from our first analysis, monitor pages / threads, http://copter.ardupilot.com/wiki/common-downloading-and-analyzing-data-logs-in-mission-planner/ and diydrones/ardupilot-wiki-issue-tracker#286 <https://github.com/diydrones/ardupilot-wiki-issue-tracker/issues/286> 

•   Keep the PM_DelayCounter > 3 before reporting long loops, this helps filter take off and Landing events which were normal on APM hardware and caused great concern when being reported to the general public in my initial analysis, but can it be reduced to 1 or 2 skiped vlaues given the following?

•   Replace the hard coded NLon detection of > 70 and create warning levels of >3%, >5%, >10%, then APM Dev ERROR of >15% against the NLoop value. Devs say >15% is the Error figure. Personally I'm not sure as my logs for an X8 APM Hardware running v3.1.4 completing a complex mission were lower than this (3% to 5%), I'd expect to have seen some warnings at least (even discounting take off and landing events). However, there were never any visual in flight issues after heavy testing (frame based around the X666, 1000KV Motors and 9045 props). Need to dig out TheQuestor landing on friend roof log, although perhaps I2C errors played a part?

•   Create new warning if PM_MaxT is > 15% of the PM_NLoop value where PM_DelayCounter can be accepted, I have some values that are massive on APM logs.

Run all test logs before releasing, and some old archived APM logs, if results are good switch back on analyse the Performance Monitoring by default.

If we can not set PM Checks back on as Default the GCS and I2C Error monitoring must me moved to separate code as currently these are not monitored by default due to the data being held in the PM dataline.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/APM_Log_File_Analyzer/issues/222#issuecomment-182230803 .

[bionicbone]

I have created a Wiki Page to describe how this works, no point in making a long comment here.

https://github.com/diydrones/APM_Log_File_Analyzer/wiki/5.Performance-Analysis

PM Testing.xlsx

The GCS and I2C errors are still part of the PM checks but are performed as default now even though the "Perf Mon Additional Information" check box is unchecked as default.