This could occur if the spline origin and destination were the same location
In these cases we mark the vehicle as having reached the destination avoid all calculations
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).
For AC3.5 and higher version, serial uartA-USBconsole cannot work. Maybe the code before "setup" has been changed. Ensure that the uartA can be initialized
The Vector2l methods completely duplicate the code of the Vector2f
methods, but aren't used anywhere. They are therefore subject to bitrot
and aren't adding any value. (Also shrinks the build by 8 bytes for some
reason, given that it's unused code I expected to see no difference in
binary size).
Randy Mackay
Peter Barker
Andrew Tridgell
Michael du Breuil
Leonard Hall
Tom Pittenger
Dr.-Ing. Amilcar Do Carmo Lucas
Jacob Walser
Patrick José Pereira
HeBin
Chinese66
khancyr