SITL: Failed to load defaults from ... when trying to start multi-aircraft SITL

[fBruckm]

Bug report

Issue details

When trying to start a simulation with:

sim_vehicle.py -v ArduPlane --map --console -n 2 --auto-sysid

the output in the main window is:

SIM_VEHICLE: Using defaults from (../../git/ardupilot/Tools/autotest/default_params/copter.parm)
SIM_VEHICLE: Run ArduCopter
SIM_VEHICLE: "/home/felix/git/ardupilot/Tools/autotest/run_in_terminal_window.sh" "ArduCopter" "/home/felix/git/ardupilot/build/sitl/bin/arducopter" "-S" "--model" "+" "--speedup" "1" "--slave" "0" "--defaults" "../../git/ardupilot/Tools/autotest/default_params/copter.parm" "-I0" "--sysid" "1"
SIM_VEHICLE: Run ArduCopter
SIM_VEHICLE: "/home/felix/git/ardupilot/Tools/autotest/run_in_terminal_window.sh" "ArduCopter" "/home/felix/git/ardupilot/build/sitl/bin/arducopter" "-S" "--model" "+" "--speedup" "1" "--slave" "0" "--defaults" "../../git/ardupilot/Tools/autotest/default_params/copter.parm" "-I1" "--sysid" "2"
RiTW: Starting ArduCopter : /home/felix/git/ardupilot/build/sitl/bin/arducopter -S --model + --speedup 1 --slave 0 --defaults ../../git/ardupilot/Tools/autotest/default_params/copter.parm -I0 --sysid 1
SIM_VEHICLE: Run MavProxy
SIM_VEHICLE: "mavproxy.py" "--out" "127.0.0.1:14550" "--out" "127.0.0.1:14551" "--master" "tcp:127.0.0.1:5760" "--sitl" "127.0.0.1:5501" "--out" "127.0.0.1:14560" "--out" "127.0.0.1:14561" "--master" "tcp:127.0.0.1:5770" "--sitl" "127.0.0.1:5511" "--map" "--console"
RiTW: Starting ArduCopter : /home/felix/git/ardupilot/build/sitl/bin/arducopter -S --model + --speedup 1 --slave 0 --defaults ../../git/ardupilot/Tools/autotest/default_params/copter.parm -I1 --sysid 2
Connect tcp:127.0.0.1:5760 source_system=255
Connect tcp:127.0.0.1:5770 source_system=255
Loaded module console
Loaded module map
Log Directory: 
Telemetry log: mav.tlog
Waiting for heartbeat from tcp:127.0.0.1:5760
 MAV> 

and all plane simulations fail with the following error:

Setting SIM_SPEEDUP=1.000000
Setting SYSID_THISMAV=1
Starting sketch 'ArduPlane'
Starting SITL input
Using Irlock at port : 9005
bind port 5760 for 0
Serial port 0 on TCP port 5760
Waiting for connection ....
Connection on serial port 5760
PANIC: Failed to load defaults from ../../git/ardupilot/Tools/autotest/default_params/plane.parm

Running: sh dumpstack.sh 30301 >dumpstack.sh_arduplane.30301.out 2>&1
Failed
Running: sh dumpcore.sh 30301 >dumpcore.sh_arduplane.30301.out 2>&1
Failed

(the second window has SYSID_THISMAV=2 and other ports, but the same error)

The path to the defaults file is correct, I can access it using the path listed above.

The command:

sim_vehicle.py -v ArduPlane --map --console --auto-sysid

out of the same or any other directory works as expected.

Does somebody have the same problem?

Version current master (020262b)

Platform [ x ] All (tested with plane and also copter) [ ] AntennaTracker [ x ] Copter [ x ] Plane [ ] Rover [ ] Submarine

[hendjoshsr71]

I can confirm I get the same error on master 020262bfe7755951ec655e9257084c6920b0f642 Starting from the ardupilot directory

It may be related to these changes which were attempted to be fixed then partially reverted, https://github.com/ArduPilot/ardupilot/pull/19879 Reversion here: 13f7e12d2a57e5c20e7eead146a3da2f252af6e8

Unfortunately, I cant via wiki (search term swarm) or google (search term ardupilot swarm) find the calls or documentation to create swarms. And am thus left with simvehicle.py --help

[fBruckm]

After investigating a bit further, it seems the problem is the usage of relative paths to the parm file in combination with -n >=2.

Changing line 687 of sim_vehicle.py from paths = [util.relcurdir(os.path.join(autotest_dir, x)) for x in paths] to paths = [os.path.join(autotest_dir, x) for x in paths] so that absolute paths are used solves the problem for me.

The problem is, that before calling run_in_terminal_window(cmd_name, cmd + c) (line 750) the program changes into the instance directory and then the relative path is wrong.

I hope with this information someone can write a better fix than this little hack. I would appreciate it.

[timtuxworth]

I think I'm seeing something like this building SITL from master. On each build the SIM* parameters seem to randomly load or not load. I'm simulating a single plane. Don't get an error, but I just get no parameters:

param show *BATT*
MANUAL> BATT_FS_CRT_ACT  0.0
BATT_FS_LOW_ACT  0.0
param show *BAT*
MANUAL> BATT_FS_CRT_ACT  0.0
BATT_FS_LOW_ACT  0.0
param show *B*
MANUAL> BARO1_GND_PRESS  94504.3515625
BARO2_GND_PRESS  94503.875
BARO_ALT_OFFSET  0.0
BATT_FS_CRT_ACT  0.0
BATT_FS_LOW_ACT  0.0
param show
MANUAL> ARSPD_OFFSET     2013.474853515625
BARO1_GND_PRESS  94504.3515625
BARO2_GND_PRESS  94503.875
BARO_ALT_OFFSET  0.0
BATT_FS_CRT_ACT  0.0
BATT_FS_LOW_ACT  0.0
INS_ACC2_ID      2753036.0
INS_ACC_ID       2753028.0
SR0_EXTRA1       4.0
SR0_EXTRA2       4.0
SR0_EXTRA3       4.0
SR0_EXT_STAT     4.0
SR0_POSITION     4.0
SR0_RAW_SENS     4.0
SR0_RC_CHAN      4.0
STAT_RUNTIME     35847.0
param show *VOLT*
MANUAL> param show *SIM*
MANUAL> 

A build I did about 12 hours ago, did show the SIM parameters. I just went back in my history, so I don't have a search for SIM but I did search for `BATT*` which shows SIM_BATT parameters that don't show now. Note that above I searched for BATT and only got two results, whereas below (12 hours ago) I got a whole raft of BATT parameters.

MANUAL> param show *BATT*
MANUAL> BATT2_MONITOR    0.0
BATT3_MONITOR    0.0
BATT4_MONITOR    0.0
BATT5_MONITOR    0.0
BATT6_MONITOR    0.0
BATT7_MONITOR    0.0
BATT8_MONITOR    0.0
BATT9_MONITOR    0.0
BATT_AMP_OFFSET  0.0
BATT_AMP_PERVLT  17.0
BATT_ARM_MAH     0.0
BATT_ARM_VOLT    10.0
BATT_CAPACITY    3300.0
BATT_CRT_MAH     0.0
BATT_CRT_VOLT    5.0
BATT_CURR_PIN    12.0
BATT_FS_CRT_ACT  0.0
BATT_FS_LOW_ACT  0.0
BATT_FS_VOLTSRC  0.0
BATT_LOW_MAH     0.0
BATT_LOW_TIMER   10.0
BATT_LOW_VOLT    7.0
BATT_MONITOR     4.0
BATT_OPTIONS     0.0
BATT_SERIAL_NUM  -1.0
BATT_VLT_OFFSET  0.0
BATT_VOLT_MULT   2.0
BATT_VOLT_PIN    13.0
BATT_WATT_MAX    0.0
SIM_BATT_CAP_AH  0.0
SIM_BATT_VOLTAGE 10.0

[Williangalvani]

we should probably revert 9743ac9c3db5de9e4d478830821e67053b4c6a15 too. I wrote that pr under some incorrect assumptions.

[fBruckm]

we should probably revert 9743ac9 too. I wrote that pr under some incorrect assumptions.

I can confirm that just reverting the changes made there on top of the current master code solves the problem for me.

[peterbarker]

@Williangalvani is simply reverting that commit going to cause you problems with your workflow? It's biting more people, so we should probably do something here :-)

[gmazzucchi]

this problem no longer exists, you can close the issue

[jankrystianserafim]

This problem still exists unfortunately, I am having these problems as we speak!

[Ryanf55]

I tested on master hash 83559c41ec55dfd817fbffcb60bf7897d9da95f1 just now, and it seems to work. Two vehicles spawn and don't crash.

Regarding how to launch the swam, I also found some other options for sim_vehicle, but it's not clear how they all relate.

Here's some other parameters I was playing with. The swarm param seems to not change anything, and --instances seems to provide a manual way if you don't use --auto-sysid.

sim_vehicle.py --swarm Tools/autotest/swarminit.txt -v Plane --console --map --instances 0 1 2

Pierre made a nice video on swarming, but it doesn't use sim_vehicle.py. https://www.youtube.com/watch?v=SMISOREe1y4&ab_channel=MrKhancyr

[Ryanf55]

Ok, here's the magic for using SITL, with the help of Peter and James. Both of these use auto-sysid because it's easy.

Option 1: Launch and supply an offset line

./Tools/autotest/sim_vehicle.py -v Copter --map --console --auto-offset-line 90,10 -n 5 -L CMAC --auto-sysid

Option 2: Launch and supply a swarm configuration file, which gives you more control over things like orientation

./Tools/autotest/sim_vehicle.py -v Copter --map --console -n 5 -L CMAC --auto-sysid --swarm Tools/autotest/swarminit.txt

Warning If you do not supply a line offset or a swarm configuration file, they will all launch in the same spot.

How many? Well, Peter proved you can do 50, which is pretty neat.