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).
Plane supports being armed, in takeoff logic and not spinning the motor
until the moment the safety button has been pressed. Unfortunately
because the safety button is required to be pressed for soft arming this
results in the plane updating home position while the user moves the
vehicle or is holding it to throw the vehicle which will can result in
several meters of altitude error from where the user expected home to
be.
Because the normal approach to plane is to have activated the safety
button before arming the aircraft this is not expected to be a behaviour
change for most users, but an improvement for people who use the button
to initiate a takeoff.
this is most often implemented as dual-motor differential thrust, and
we don't want to do surface speed scaling for that.
In the future we'll move this scaling so it can be done on rudders for
3D planes
Navio2 exports its leds via /sys/class/leds interface. We reuse it in
order not to conflict with GPIO_Sysfs. Otherwise we'd get a Device Busy
error in GPIO_Sysfs::_export_pin().
HeBin
Randy Mackay
Dr.-Ing. Amilcar Do Carmo Lucas
Chinese66
khancyr
Michael du Breuil
Andrew Tridgell
Guy Tzoler
Patrick José Pereira
Samuel Tabor
Georgii Staroselskii
Peter Barker