There are still intermitant false-positive logging failure happening in
ArduCopter. This disables the logging arming check for the time being.
This was set back to 1 a few months ago thinking the issue was fixed.
But it turns out it is not.
This will rebuild and use the XML file we generate from our
source code which conveys information about our parameters.
When using this option, "param help PARAMETERNAME" should reflect
changes made to the parameter metadata for PARAMETERNAME.
Tools: don't need to pass option on first mavproxy
Tools: reformat common.py and add commun function
Tools: use new common functions
Tools: move functions from rover to commun and reorder
Tools: add and use set_rc function with timeout
Tools: fix style for pep8
Tools: LogAnalyzer: don't continue if we fail to set vehicle type from MSG
Tools: LogAnalyzer: cope with renamed CTUN.BarAlt attribute
Tools: LogAnalyzer: cope with renamed CTUN.BarAlt attribute
Tools: LogAnalyzer: cope with missing THR_MIN parameter
Added \r\n to the expect() string as recomended at:
http://pexpect.readthedocs.io/en/stable/overview.html#find-the-end-of-line-cr-lf-conventions
this should work on both windows and linux systems
pexpect says it will always do a minimal (non greedy) matching and docs explicitly say that a .+ expression will always return only one character. These lines in autotest are looking for \S+, which, believing the documentation, would only return one character of the log file path.
Now we know that's not true, neither for Linux or for Windows (given the logs from @karthikdesai), so I can only assume that it does a greedy match but only for the characters it has received at the time expect is called.
Apparently, in the machines we are using autotest, it isn't a problem since MAVProxy is likely fast to give its output to pexpect before the expect method is called. On @karthikdesai's machine that wasn't happening since his machine was more or less loaded.
Concluding, this looks like a correct fix in the sense that it extends the regex pattern to wait for the end of line (and probably other places could benefit from it too).
Based on work done by khancir
(https://github.com/ArduPilot/ardupilot/pull/6360)
Tools: arduplane.py change print to progress function
Tools: quadplane.py change print to progress function
Tools: ardusub.py change print to progress function