add option to use startup config script location and name for the working directory

[lamping7]

@dagar This addresses #9046. It adds an optional switch -w to change the working directory for posix. Currently rootfs gets put in the CWD, which includes params and dataman. Using -w tells the script to use the startup configuration path and name as the working directory instead. It is necessary to have different working directories for multi vehicle simulations. As a side benefit, this also allows for per-model working directories for single vehicle as well, which is nice for maintaining params for different vehicles. This is only been tested for my particular use-case, using ROS for multi-vehicle simulations.

Because multiple vehicles each require different startup scripts to configure the appropriate ports and mav ID, using the script path and name, guarantees this to be unique and is a simple way to solve the problem.

Before -- shared working directory in ~/.ros:

in px4/Firmware/posix-configs/SITL/init/ekf2/:

With added arg -- single vehicle, roslaunch px4 posix_sitl.launch in px4/Firmware/posix-configs/SITL/init/ekf2/:

With added arg -- multi-vehicle, roslaunch px4 multi_uav_mavros_sitl.launch in px4/Firmware/posix-configs/SITL/init/ekf2/:

[lamping7]

Note: This doesn't have to be optional, it was made that way for now until the effects are understood for other use-cases.

EDIT: I've only changed the single_vehicle_spawn.launch used by multi_uav_mavros_sitl.launch to include the option.

[lamping7]

I should show that this works.

[lamping7]

Something I observed with this PR, maybe someone with more experience with the start-up process can comment --

Making a symlink here (unchanged in this PR) to posix_configs creates a circular file system loop (seen when using find or tab completion) -- because I'm essentially changing the CWD to a subfolder within it when launching any of the PX4 provided models.

I'm not entirely sure why these links are needed. Do they settle some other hard-coded file paths?

[dagar]

This looks like a good start, but I think we'll need to go through the codebase and take care of these hardcoded paths. https://github.com/PX4/Firmware/blob/master/src/modules/dataman/dataman.cpp#L250

I also question that entire block of symlinks code. The test_data could move into the relevant move (rc lib), and the ROMFS (which probably should include the configs) should probably be more like an install step. Handling symlinks to the build directory at runtime in main seems pretty hacky.

[Ahrovan]

@LorenzMeier @dagar this added to the Release v1.8.0 milestone, Is there a plan to complete and apply it?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lamping7]

This needs re-approached in a different PR. It was more of a test and request for input.