Update for _HOST environment options

[rob-clarke]

Uses the *_HOST environment variables to configure the sitl and simhost containers to talk to each other. Additionally puts the MAVLink stream from MAVROS on TCP/5761 and exposes it.

With this change we should be able to go back to a single compose file. Network=host mode is only of interest for bare metal ROS on Linux.

Requires StarlingUAS/ProjectStarling#117 to be merged. Until then, the image version used by the compose file can be configured using

STARLING_RELEASE=ap-sim-address docker-compose -f docker-compose.windows.yml pull
STARLING_RELEASE=ap-sim-address docker-compose -f docker-compose.windows.yml up

[mhl787156]

LGTM, after a test on windows

[rob-clarke]

In PowerShell:

$env:STARLING_RELEASE = 'ap-sim-address'; docker-compose -f docker-compose.windows.yml up
Remove-Item Env:\STARLING_RELEASE

[mhl787156]

What does testing in windows include? Is it

• [x] WSL2
• [x] Powershell
• [ ] Command Line

[rob-clarke]

I'd say just PowerShell, maybe WSL

[mhl787156]

Currently still getting that old npm error:

simhost_1          | [gzweb_entrypoint.sh-2] Sat Oct 30 2021 16:39:02 GMT+0000 (Coordinated Universal Time) Received Message: {"op":"call_service","id":"call_service:~/roads:12","service":"~/roads","args":["roads"]} from http://localhost:8080 ::ffff:172.18.0.1
simhost_1          | [gzweb_entrypoint.sh-2] Segmentation fault
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! code ELIFECYCLE
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! errno 139
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! gzweb@1.3.0 start: `if [ $npm_config_port ]; then port=$npm_config_port; fi; cd gzbridge && ./server.js $port`
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! Exit status 139
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! 
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! Failed at the gzweb@1.3.0 start script.
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
simhost_1          | [gzweb_entrypoint.sh-2] 
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR! A complete log of this run can be found in:
simhost_1          | [gzweb_entrypoint.sh-2] npm ERR!     /root/.npm/_logs/2021-10-30T16_39_02_695Z-debug.log
simhost_1          | [ERROR] [gzweb_entrypoint.sh-2]: process has died [pid 184, exit code 139, cmd '/gzweb_entrypoint.sh'].

so its quite hard to test, where did you put the fix?

Also it takes a few runs to actually spawn the model...

[mhl787156]

Update, the error goes away if the vehicle is successfuly spawned, for me it took 6 runs of docker-compose on wsl.

Powershell currently fails due to FCU: DeviceError:tcp:connect: Connection refused

[mhl787156]

Oh sorry, no powershell does work, it complains a few times and eventually connects.

It does however take a number of attempts of running docker-compose before the spawn is successful.

[rob-clarke]

The fix was missing as the bakefile was missing some build args. That meant that sim-ardupilot-gazebo was building on top of :latest. Updated now

[mhl787156]

How do I connect mission planner? Both TCP 5760 and UDP 14550 with 127.0.0.1 is not working...

Ah found it! I can connect on TCP 5761, 127.0.01

[rob-clarke]

The failure to spawn is due to model download time. The first run fails as there are some world models that need downloading. That causes the spawn to timeout. The second run actually starts the spawn, but that also needs to download the model, it should eventually work, but takes its time. The third run usually does the trick.

MissionPlanner should be able to connect on TCP/5761

[mhl787156]

Ok verified on WSL2 and Powershell, it connects to MissionPlanner on TCP 5761 (I dont know how to take off in MP though... but it arms!) Cannot verify in CMD as my files are inside WSL file system and not on windows side.

Can you add a comment in the readme saying that you may need to run it multiple times? (Or we need to up the spawn timeout...) Otherwise LGTM

(Also I like the env variable setup for the docker compose file! we should replicate that in the other docker-compose files too)

[rob-clarke]

I don't think cmd.exe support is needed, PowerShell will do everything needed. We should block merging this until support is in master on the main repo.

[mhl787156]

Cool LGTM NOT merging now until merged master on main!

[mhl787156]

Projectstarling master release, now merging here.