fix px4 connection for wsl 2.

[lovettchris]

Fixes: #
many issues search for PX4

About

AirSim cannot talk to PX4 on WSL 2 because WSL 2 does not use localhost. This adds support for
AirSim to talk to PX4 running on remote IP, where PX4 is configured to find AirSim using the
new PX4_SIM_HOST_ADDR environment variable (need latest PX4 master bits).

Also contains a fix that makes GPS fusion and Home Position happen a lot faster.

How Has This Been Tested?

windows + wsl 2 px4 firmware connect AirSim with these settings:

            "ControlPortLocal": 14540,
            "ControlPortRemote": 14580,
            "ControlIp": "remote",
            "LocalHostIp": "172.24.240.1",
            "Parameters": {
                "NAV_RCL_ACT": 0,
                "NAV_DLL_ACT": 0,
                "LPE_LAT": 47.641468,
                "LPE_LON": -122.140165,
                "COM_OBL_ACT": 1
            },

cd PythonClient\multirotor
python stability_test.py

ran for 1 hour not finding any problems.
also tested that the same works with cygwin version of px4 running on localhost with these settings:

            "ControlPortLocal": 14540,
            "ControlPortRemote": 14580,
            "ControlIp": "127.0.0.1",
            "LocalHostIp": "127.0.0.1",

and also tested Pixhawk HITL with serial port and all 3 tests worked fine.

Here is a cooked AirSimNHTest binary containing these bits.

Screenshots (if appropriate):

[rajat2004]

Also, I'm currently trying to figure out some strange GPS readings I'm seeing with ArduPilot, see #3364 (comment) and below, is something like this occurring with PX4 as well? Continuous ascend is enough to always trigger this, around 50m

[lovettchris]

@rajat2004, regarding GPS signal, I am not seeing what you mention in #3364. I will add comments on that PR rather than here as that seems to be an unrelated topic

[rajat2004]

Ah, #3364 did not fit cleanly with this, sorry for that.
Edit, so merge got committed just as I commented

Also, there's a statement (L1137 in the new code of this PR) -

AirSim/AirLib/include/vehicles/multirotor/firmwares/mavlink/MavLinkMultirotorApi.hpp

Lines 947 to 948 in a2acbf4

	else if (mav_vehicle_ != nullptr) {
	mav_vehicle_->getConnection()->startLoggingSendMessage(std::make_shared<MavLinkLogViewerLog>(logviewer_out_proxy_));

This is starting logging on a different log file, but the same connection logger gets overwritten in the onArmed() method. This will likely happen before the vehicle gets armed, so maybe the earlier stuff gets logged? But there's actually no log file being opened here also (openForWriting)

The corresponding stop logging (L881 now) -

AirSim/AirLib/include/vehicles/multirotor/firmwares/mavlink/MavLinkMultirotorApi.hpp

Lines 695 to 700 in a2acbf4

	if (mav_vehicle_ != nullptr) {
	auto c = mav_vehicle_->getConnection();
	if (c != nullptr) {
	c->stopLoggingSendMessage();
	}
	mav_vehicle_->close();

[lovettchris]

@rajat2004, I wonder if github can do code reviews with comments on the actual line of code where you think there's a problem. Might be easier for context that way. But Yes, this is doing realtime LogViewer logging and that is mutually exclusive with file logging.

mav_vehicle_->getConnection()->startLoggingSendMessage(std::make_shared<MavLinkLogViewerLog>(logviewer_out_proxy_)); 

I pushed a fix to this to make it more consistent and added docs to make it clear that these are mutually exclusive.

[rajat2004]

Makes sense if the 2 loggers are mutually exclusive. I would have commented on the specific line itself but Github doesn't allow comments on code which hasn't changed if it's more than some 10 lines or so away from any changes.

[lovettchris]

got it, yeah, I still like the devops code review system a lot better than github...

[zimmy87]

Mostly some comments on style and typos to conform to the coding guidelines

[zimmy87]

extra comment caught after previous review

[zimmy87]

Some additional comments from doing testing on this PR

[zimmy87]

Tested repro of #3415, python scripts that were changed, and the Unity build. #3415 didn't occur over 3 hour-long test runs in WSL2 (it still appears to repro in Cygwin, but I think that is better addressed in a separate PR), and I didn't observe any regressions elsewhere, so I am moving ahead with merging this.